From oliel at redhat.com Sun Jul 1 08:50:47 2012 From: oliel at redhat.com (Ori Liel) Date: Sun, 01 Jul 2012 04:50:47 -0400 (EDT) Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: Message-ID: We need to enable passing 'used' luns for new storage-domain creation (used = the lun is part of a VG). We need a way in rest-api to explicitly approve the use of such luns. Does anyone have a suggestion for a good name for such a flag, a name that conveys: "use the given luns even if they are part of a VG?" Thanks, Ori. From iheim at redhat.com Sun Jul 1 10:39:14 2012 From: iheim at redhat.com (Itamar Heim) Date: Sun, 01 Jul 2012 13:39:14 +0300 Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: References: Message-ID: <4FF028D2.3090904@redhat.com> On 07/01/2012 11:50 AM, Ori Liel wrote: > We need to enable passing 'used' luns for new storage-domain creation (used = the lun is part of a VG). > We need a way in rest-api to explicitly approve the use of such luns. > > Does anyone have a suggestion for a good name for such a flag, a name that conveys: "use the given luns > even if they are part of a VG?" why not just force? From mpastern at redhat.com Sun Jul 1 12:09:20 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 01 Jul 2012 15:09:20 +0300 Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: References: Message-ID: <4FF03DF0.30606@redhat.com> On 07/01/2012 11:50 AM, Ori Liel wrote: > We need to enable passing 'used' luns for new storage-domain creation (used = the lun is part of a VG). > We need a way in rest-api to explicitly approve the use of such luns. > > Does anyone have a suggestion for a good name for such a flag, a name that conveys: "use the given luns > even if they are part of a VG?" reuse_luns > > Thanks, > > Ori. -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Sun Jul 1 12:11:51 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 01 Jul 2012 15:11:51 +0300 Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: <4FF028D2.3090904@redhat.com> References: <4FF028D2.3090904@redhat.com> Message-ID: <4FF03E87.1090407@redhat.com> On 07/01/2012 01:39 PM, Itamar Heim wrote: > On 07/01/2012 11:50 AM, Ori Liel wrote: >> We need to enable passing 'used' luns for new storage-domain creation (used = the lun is part of a VG). >> We need a way in rest-api to explicitly approve the use of such luns. >> >> Does anyone have a suggestion for a good name for such a flag, a name that conveys: "use the given luns >> even if they are part of a VG?" > > why not just force? force is not enough informative (also it usually used on /destroy based operations) > _______________________________________________ > 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 shuming at linux.vnet.ibm.com Sun Jul 1 14:50:47 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Sun, 01 Jul 2012 22:50:47 +0800 Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: References: Message-ID: <4FF063C7.8070300@linux.vnet.ibm.com> SHARED_LUN? On 2012-7-1 16:50, Ori Liel wrote: > We need to enable passing 'used' luns for new storage-domain creation (used = the lun is part of a VG). > We need a way in rest-api to explicitly approve the use of such luns. > > Does anyone have a suggestion for a good name for such a flag, a name that conveys: "use the given luns > even if they are part of a VG?" > > Thanks, > > Ori. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- Shu Ming IBM China Systems and Technology Laboratory From acathrow at redhat.com Sun Jul 1 15:10:21 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Sun, 01 Jul 2012 11:10:21 -0400 (EDT) Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: <4FF063C7.8070300@linux.vnet.ibm.com> Message-ID: ----- Original Message ----- > From: "Shu Ming" > To: "Ori Liel" > Cc: "engine-devel" > Sent: Sunday, July 1, 2012 10:50:47 AM > Subject: Re: [Engine-devel] restapi: Storage-Domain creation - Used Luns > > SHARED_LUN? We won't be sharing them, we'll be overwriting them. Maybe something like overwrite or force ? > On 2012-7-1 16:50, Ori Liel wrote: > > We need to enable passing 'used' luns for new storage-domain > > creation (used = the lun is part of a VG). > > We need a way in rest-api to explicitly approve the use of such > > luns. > > > > Does anyone have a suggestion for a good name for such a flag, a > > name that conveys: "use the given luns > > even if they are part of a VG?" > > > > Thanks, > > > > Ori. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > -- > Shu Ming > IBM China Systems and Technology Laboratory > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From shuming at linux.vnet.ibm.com Mon Jul 2 03:03:03 2012 From: shuming at linux.vnet.ibm.com (Shu Ming) Date: Mon, 02 Jul 2012 11:03:03 +0800 Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: References: Message-ID: <4FF10F67.3070404@linux.vnet.ibm.com> On 2012-7-1 23:10, Andrew Cathrow wrote: > > ----- Original Message ----- >> From: "Shu Ming" >> To: "Ori Liel" >> Cc: "engine-devel" >> Sent: Sunday, July 1, 2012 10:50:47 AM >> Subject: Re: [Engine-devel] restapi: Storage-Domain creation - Used Luns >> >> SHARED_LUN? > We won't be sharing them, we'll be overwriting them. > > Maybe something like overwrite or force ? So does the lun still belongs to the VG? How about the VG operation to acess the lun while the new storage-domain is accessing the lun? > > >> On 2012-7-1 16:50, Ori Liel wrote: >>> We need to enable passing 'used' luns for new storage-domain >>> creation (used = the lun is part of a VG). >>> We need a way in rest-api to explicitly approve the use of such >>> luns. >>> >>> Does anyone have a suggestion for a good name for such a flag, a >>> name that conveys: "use the given luns >>> even if they are part of a VG?" >>> >>> Thanks, >>> >>> Ori. >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> -- >> Shu Ming >> IBM China Systems and Technology Laboratory >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> -- Shu Ming IBM China Systems and Technology Laboratory From abaron at redhat.com Mon Jul 2 10:44:14 2012 From: abaron at redhat.com (Ayal Baron) Date: Mon, 02 Jul 2012 06:44:14 -0400 (EDT) Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: Message-ID: <0b255827-1160-4503-9b99-76d9ad162529@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Shu Ming" > > To: "Ori Liel" > > Cc: "engine-devel" > > Sent: Sunday, July 1, 2012 10:50:47 AM > > Subject: Re: [Engine-devel] restapi: Storage-Domain creation - Used > > Luns > > > > SHARED_LUN? > > We won't be sharing them, we'll be overwriting them. > > Maybe something like overwrite or force ? I'm fine with either one (force / overwrite) or forceDelete as well or forceOverride. > > > > On 2012-7-1 16:50, Ori Liel wrote: > > > We need to enable passing 'used' luns for new storage-domain > > > creation (used = the lun is part of a VG). > > > We need a way in rest-api to explicitly approve the use of such > > > luns. > > > > > > Does anyone have a suggestion for a good name for such a flag, a > > > name that conveys: "use the given luns > > > even if they are part of a VG?" > > > > > > Thanks, > > > > > > Ori. > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel at ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > -- > > Shu Ming > > IBM China Systems and Technology Laboratory > > > > > > _______________________________________________ > > 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 acathrow at redhat.com Mon Jul 2 10:59:15 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Mon, 02 Jul 2012 06:59:15 -0400 (EDT) Subject: [Engine-devel] restapi: Storage-Domain creation - Used Luns In-Reply-To: <0b255827-1160-4503-9b99-76d9ad162529@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <17ede77c-2295-494d-8918-9f24a4a49587@zmail20.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Ayal Baron" > To: "Andrew Cathrow" > Cc: "engine-devel" , "Shu Ming" > Sent: Monday, July 2, 2012 6:44:14 AM > Subject: Re: [Engine-devel] restapi: Storage-Domain creation - Used Luns > > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > From: "Shu Ming" > > > To: "Ori Liel" > > > Cc: "engine-devel" > > > Sent: Sunday, July 1, 2012 10:50:47 AM > > > Subject: Re: [Engine-devel] restapi: Storage-Domain creation - > > > Used > > > Luns > > > > > > SHARED_LUN? > > > > We won't be sharing them, we'll be overwriting them. > > > > Maybe something like overwrite or force ? > > I'm fine with either one (force / overwrite) or forceDelete as well > or forceOverride. > yep, the key thing here is that we need to scare the user so it's very clear that this could be destructive. > > > > > > > > > On 2012-7-1 16:50, Ori Liel wrote: > > > > We need to enable passing 'used' luns for new storage-domain > > > > creation (used = the lun is part of a VG). > > > > We need a way in rest-api to explicitly approve the use of such > > > > luns. > > > > > > > > Does anyone have a suggestion for a good name for such a flag, > > > > a > > > > name that conveys: "use the given luns > > > > even if they are part of a VG?" > > > > > > > > Thanks, > > > > > > > > Ori. > > > > _______________________________________________ > > > > Engine-devel mailing list > > > > Engine-devel at ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > > > > > > > > > > -- > > > Shu Ming > > > IBM China Systems and Technology Laboratory > > > > > > > > > _______________________________________________ > > > 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 ykaul at redhat.com Mon Jul 2 12:07:50 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Mon, 02 Jul 2012 15:07:50 +0300 Subject: [Engine-devel] JVM version required Message-ID: <4FF18F16.1060603@redhat.com> 1. Do we want to enforce a minimal JDK version required? For example, 1.7? 2. If we do, I assume we'll do it in the packaging requirement, but should we check for it at runtime (read: service startup) ? TIA, Y. From jhernand at redhat.com Mon Jul 2 12:19:47 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 02 Jul 2012 14:19:47 +0200 Subject: [Engine-devel] JVM version required In-Reply-To: <4FF18F16.1060603@redhat.com> References: <4FF18F16.1060603@redhat.com> Message-ID: <4FF191E3.5040703@redhat.com> On 07/02/2012 02:07 PM, Yaniv Kaul wrote: > 1. Do we want to enforce a minimal JDK version required? For example, 1.7? > 2. If we do, I assume we'll do it in the packaging requirement, but > should we check for it at runtime (read: service startup) ? +1 for checking at runtime -- 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 mkolesni at redhat.com Mon Jul 2 14:35:52 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Mon, 02 Jul 2012 10:35:52 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <6e7f3326-d379-40c4-baea-8914c7d963af@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <9edb9ba5-e158-40a2-b454-96807c486cce@zmail14.collab.prod.int.phx2.redhat.com> Hi All, I would like to hear opinions about a behaviour that I think is problematic in REST API handling of logical networks. -- Intro -- Today in the REST API we are exposing two collections for "logical network" related entities. First is a top level collection which is out of any context at the address http://engine/api/networks. Second is a sub-collection in the context of a cluster: http://engine/api/cluster/xxx/networks The network itself is defined per DC level, so for each DC you would have at least one logical network for management, which has some properties such as STP, MTU, etc.. The top level collection is used to create/delete such network entities. The sub-collection in the context of a Cluster is used to attach/detach a network from the DC of that cluster. The network in the context of a cluster has some additional information, let's say for example 'status' of the network: If a network is defined on all hosts in the cluster then it's status is 'Operational'. If a network is not defined on some of the hosts in the cluster then it's status is 'Not Operational'[1]. -- Problem -- The problem is that details which are only relevant in context of a cluster, are still displayed in the root context as well (e.g: 'status'). This can, in certain cases, cause unexpected behaviour. For example, let's consider this topology: Data Center A | |\____ Network 'red' |\____ Cluster A1 | \______ Network 'red' attached \____ Cluster A2 \______ Network 'red' attached If the 'status' is the same on all the clusters that the network is attached to (A1, A2) then there will be one element in the top level collection, with the network details and the 'status' field representing the state (which is same for all networks in the cluster contexts of the cluster). If, however, the status is not the same (ie. on A1 the network is 'Operational' and on A2 it is 'Non Operational') then the top-level collection will show two elements for the network, where all network details are the same and only the 'status' field is different. This is problematic IMHO for several reasons: 1. Showing one network in certain states, and multiple copies of this network in other states is not optimal, to say the least. 2. In the top-level collection there is no indicator of the cluster for which the network is displayed, so there is no way to differentiate between the two 'red' network elements (they will have same id, name, etc.). 3. There is a certain asymmetry between the remove action[2] and the result in that you would expect: you either remove a network but in the result you would see several elements removed. -- Proposed Solutions -- Personally I can think of several solutions to this problem: 1. Declare the top-level collection as a collection of all networks that are either attached to cluster or not, and if they are indeed attached then show the details for each cluster, including a link to the cluster. 2. Declare the top-level collection as a collection of all networks that are defined in data-centers, but they will not contain any cluster specific data, and thus each entry is unique. Solution #2 is breaking the API backwards-compatibility, since it includes removing certain fields that have appeared today (namely 'status' and 'display') but IMO would give a better experience since the top-level collection is actually used for managing networks, and not their attachment to clusters which should be done in the context of each cluster. I would like to hear what suggestions you have to solve this problem or if you prefer either of the above solutions. -- Footnotes -- [1] In 3.1 this is slightly different, but for the sake of simplicity I didn't specify the new behaviour. [2] Currently you can't update the network if it's attached to any cluster, but perhaps in the future this would be possible. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From atal at redhat.com Tue Jul 3 06:51:25 2012 From: atal at redhat.com (Avi Tal) Date: Tue, 03 Jul 2012 02:51:25 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <9edb9ba5-e158-40a2-b454-96807c486cce@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: Comments inline ----- Original Message ----- > From: "Mike Kolesnik" > To: "engine-devel" > Sent: Monday, July 2, 2012 5:35:52 PM > Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks > > > > > > Hi All, > > I would like to hear opinions about a behaviour that I think is > problematic in > REST API handling of logical networks. > > -- Intro -- > Today in the REST API we are exposing two collections for "logical > network" related entities. > > First is a top level collection which is out of any context at the > address > http://engine/api/networks. > Second is a sub-collection in the context of a cluster: > http://engine/api/cluster/xxx/networks > > The network itself is defined per DC level, so for each DC you would > have > at least one logical network for management, which has some > properties such > as STP, MTU, etc.. > The top level collection is used to create/delete such network > entities. > > The sub-collection in the context of a Cluster is used to > attach/detach a > network from the DC of that cluster. Edit as well. you can update cluster network and change the "Display" property. > The network in the context of a cluster has some additional > information, let's > say for example 'status' of the network: > If a network is defined on all hosts in the cluster then it's status > is > 'Operational'. > If a network is not defined on some of the hosts in the cluster then > it's > status is 'Not Operational'[1]. > > > -- Problem -- > The problem is that details which are only relevant in context of a > cluster, are still displayed in the root context as well (e.g: > 'status'). > This can, in certain cases, cause unexpected behaviour. > +1 no need to display cluster properties in datacenter context. (https://bugzilla.redhat.com/show_bug.cgi?id=815268) > For example, let's consider this topology: > Data Center A > | > |\____ Network 'red' > |\____ Cluster A1 > | \______ Network 'red' attached > \____ Cluster A2 > \______ Network 'red' attached > > If the 'status' is the same on all the clusters that the network is > attached to > (A1, A2) then there will be one element in the top level collection, > with the > network details and the 'status' field representing the state (which > is same > for all networks in the cluster contexts of the cluster). > If, however, the status is not the same (ie. on A1 the network is > 'Operational' and on A2 it is 'Non Operational') then the top-level > collection will show two elements for the network, where all network > details are the same and only the 'status' field is different. > > This is problematic IMHO for several reasons: > 1. Showing one network in certain states, and multiple copies of this > network in other states is not optimal, to say the least. > 2. In the top-level collection there is no indicator of the cluster > for which > the network is displayed, so there is no way to differentiate between > the > two 'red' network elements (they will have same id, name, etc.). > 3. There is a certain asymmetry between the remove action[2] and the > result in that you would expect: you either remove a network but in > the > result you would see several elements removed. > > > -- Proposed Solutions -- > Personally I can think of several solutions to this problem: > 1. Declare the top-level collection as a collection of all networks > that are > either attached to cluster or not, and if they are indeed attached > then > show the details for each cluster, including a link to the cluster. > 2. Declare the top-level collection as a collection of all networks > that are > defined in data-centers, but they will not contain any cluster > specific > data, and thus each entry is unique. > Why do we keep holding this Top level collection instead of having each network related under his datacenter (/api/datacenter/id/networks)??? https://bugzilla.redhat.com/show_bug.cgi?id=741111 One solution which is must is to move the top level network (/api/networks) under each Datacenter! 1. having top level networks path isn't symmetric to our entire REST API implementation! all other network collections (cluster, hosts, VMs, Templates) placed under their related component. 2. as a REST API user, having sub collection networks under each datacenter is better to handle than parsing a top level collection and comparing DC id in order to get all DC related networks. 3. as for breaking api/ backward compatibility, we can still hold the top level network collection ad deprecated and start exposing the sub collections under each datacenter. > Solution #2 is breaking the API backwards-compatibility, since it > includes > removing certain fields that have appeared today (namely 'status' and > 'display') but IMO would give a better experience since the top-level > collection is actually used for managing networks, and not their > attachment > to clusters which should be done in the context of each cluster. > > I would like to hear what suggestions you have to solve this problem > or if > you prefer either of the above solutions. > > > -- Footnotes -- > [1] In 3.1 this is slightly different, but for the sake of simplicity > I didn't > specify the new behaviour. > [2] Currently you can't update the network if it's attached to any > cluster, > but perhaps in the future this would be possible. > > > Regards, > Mike > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Tue Jul 3 07:00:38 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 03 Jul 2012 10:00:38 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: References: Message-ID: <4FF29896.3030700@redhat.com> On 07/03/2012 09:51 AM, Avi Tal wrote: ... > > Why do we keep holding this Top level collection instead of having each network related under his datacenter (/api/datacenter/id/networks)??? why do we keep VMs as top level? they only exist in data center... why do we keep Clusters as top level? they only exist in data center... why do we keep Templates as top level? they only exist in data center... all entities are available today as top level as well, so networks are there for consistency > > https://bugzilla.redhat.com/show_bug.cgi?id=741111 > > One solution which is must is to move the top level network (/api/networks) under each Datacenter! > > 1. having top level networks path isn't symmetric to our entire REST API implementation! > all other network collections (cluster, hosts, VMs, Templates) placed under their related component. > 2. as a REST API user, having sub collection networks under each datacenter is better to handle than parsing a top level collection > and comparing DC id in order to get all DC related networks. > 3. as for breaking api/ backward compatibility, we can still hold the top level network collection ad deprecated and start exposing the sub collections > under each datacenter. From ykaul at redhat.com Tue Jul 3 07:06:56 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Tue, 03 Jul 2012 10:06:56 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF29896.3030700@redhat.com> References: <4FF29896.3030700@redhat.com> Message-ID: <4FF29A10.90606@redhat.com> On 07/03/2012 10:00 AM, Itamar Heim wrote: > On 07/03/2012 09:51 AM, Avi Tal wrote: > ... >> >> Why do we keep holding this Top level collection instead of having >> each network related under his datacenter >> (/api/datacenter/id/networks)??? > > why do we keep VMs as top level? they only exist in data center... > why do we keep Clusters as top level? they only exist in data center... > why do we keep Templates as top level? they only exist in data center... What's the answer to all the above, btw? Y. > > all entities are available today as top level as well, so networks are > there for consistency > >> >> https://bugzilla.redhat.com/show_bug.cgi?id=741111 >> >> One solution which is must is to move the top level network >> (/api/networks) under each Datacenter! >> >> 1. having top level networks path isn't symmetric to our entire REST >> API implementation! >> all other network collections (cluster, hosts, VMs, Templates) >> placed under their related component. >> 2. as a REST API user, having sub collection networks under each >> datacenter is better to handle than parsing a top level collection >> and comparing DC id in order to get all DC related networks. >> 3. as for breaking api/ backward compatibility, we can still hold the >> top level network collection ad deprecated and start exposing the sub >> collections >> under each datacenter. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From lpeer at redhat.com Tue Jul 3 07:30:10 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 03 Jul 2012 10:30:10 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <9edb9ba5-e158-40a2-b454-96807c486cce@zmail14.collab.prod.int.phx2.redhat.com> References: <9edb9ba5-e158-40a2-b454-96807c486cce@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FF29F82.6080602@redhat.com> On 02/07/12 17:35, Mike Kolesnik wrote: > Hi All, > > I would like to hear opinions about a behaviour that I think is > problematic in > REST API handling of logical networks. > > -- Intro -- > Today in the REST API we are exposing two collections for "logical > network" related entities. > > First is a top level collection which is out of any context at the address > http://engine/api/networks. > Second is a sub-collection in the context of a cluster: > http://engine/api/cluster/xxx/networks > > The network itself is defined per DC level, so for each DC you would have > at least one logical network for management, which has some properties such > as STP, MTU, etc.. > The top level collection is used to create/delete such network entities. > > The sub-collection in the context of a Cluster is used to attach/detach a > network from the DC of that cluster. > The network in the context of a cluster has some additional information, > let's > say for example 'status' of the network: > If a network is defined on all hosts in the cluster then it's status is > 'Operational'. > If a network is not defined on some of the hosts in the cluster then > it's > status is 'Not Operational'[1]. > > > -- Problem -- > The problem is that details which are only relevant in context of a > cluster, are still displayed in the root context as well (e.g: 'status'). > This can, in certain cases, cause unexpected behaviour. > > For example, let's consider this topology: > Data Center A > | > |\____ Network 'red' > |\____ Cluster A1 > | \______ Network 'red' attached > \____ Cluster A2 > \______ Network 'red' attached > > If the 'status' is the same on all the clusters that the network is > attached to > (A1, A2) then there will be one element in the top level collection, > with the > network details and the 'status' field representing the state (which is same > for all networks in the cluster contexts of the cluster). > If, however, the status is not the same (ie. on A1 the network is > 'Operational' and on A2 it is 'Non Operational') then the top-level > collection will show two elements for the network, where all network > details are the same and only the 'status' field is different. > That sounds like a bug to me. I think that top collection should include only DC level properties and not cluster level properties, status should not be there (same as display required etc.) > This is problematic IMHO for several reasons: > 1. Showing one network in certain states, and multiple copies of this > network in other states is not optimal, to say the least. > 2. In the top-level collection there is no indicator of the cluster > for which > the network is displayed, so there is no way to differentiate > between the > two 'red' network elements (they will have same id, name, etc.). > 3. There is a certain asymmetry between the remove action[2] and the > result in that you would expect: you either remove a network but > in the > result you would see several elements removed. > > > -- Proposed Solutions -- > Personally I can think of several solutions to this problem: > 1. Declare the top-level collection as a collection of all networks > that are > either attached to cluster or not, and if they are indeed attached > then > show the details for each cluster, including a link to the cluster. > 2. Declare the top-level collection as a collection of all networks > that are > defined in data-centers, but they will not contain any cluster > specific > data, and thus each entry is unique. > > Solution #2 is breaking the API backwards-compatibility, since it includes > removing certain fields that have appeared today (namely 'status' and > 'display') but IMO would give a better experience since the top-level > collection is actually used for managing networks, and not their attachment > to clusters which should be done in the context of each cluster. > I really don't think top collections should include cluster networks it is not user-friendly to say the least. I vote for the second option, I don't think that having a bug in previous versions should drive this decision. > I would like to hear what suggestions you have to solve this problem or if > you prefer either of the above solutions. > > > -- Footnotes -- > [1] In 3.1 this is slightly different, but for the sake of simplicity I > didn't > specify the new behaviour. > [2] Currently you can't update the network if it's attached to any cluster, > but perhaps in the future this would be possible. > > Regards, > Mike > > From rgolan at redhat.com Tue Jul 3 07:43:11 2012 From: rgolan at redhat.com (Roy Golan) Date: Tue, 03 Jul 2012 10:43:11 +0300 Subject: [Engine-devel] Backend bean validation wiki Message-ID: <4FF2A28F.8050005@redhat.com> Hi All, Here's a how-to for Backend bean validation http://www.ovirt.org/wiki/Backend_Bean_Validation Comments are welcome. Thanks, Roy From mpastern at redhat.com Tue Jul 3 07:54:21 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 03 Jul 2012 10:54:21 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <9edb9ba5-e158-40a2-b454-96807c486cce@zmail14.collab.prod.int.phx2.redhat.com> References: <9edb9ba5-e158-40a2-b454-96807c486cce@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FF2A52D.4030103@redhat.com> On 07/02/2012 05:35 PM, Mike Kolesnik wrote: > Hi All, > > I would like to hear opinions about a behaviour that I think is problematic in > REST API handling of logical networks. > > -- Intro -- > Today in the REST API we are exposing two collections for "logical > network" related entities. > > First is a top level collection which is out of any context at the address > http://engine/api/networks. > Second is a sub-collection in the context of a cluster: > http://engine/api/cluster/xxx/networks > > The network itself is defined per DC level, so for each DC you would have > at least one logical network for management, which has some properties such > as STP, MTU, etc.. > The top level collection is used to create/delete such network entities. > > The sub-collection in the context of a Cluster is used to attach/detach a > network from the DC of that cluster. > The network in the context of a cluster has some additional information, let's > say for example 'status' of the network: > If a network is defined on all hosts in the cluster then it's status is > 'Operational'. > If a network is not defined on some of the hosts in the cluster then it's > status is 'Not Operational'[1]. > > > -- Problem -- > The problem is that details which are only relevant in context of a > cluster, are still displayed in the root context as well (e.g: 'status'). this is 2.2 bug, behaviour has to be the same as in /api/storagedomains and /api/datacenters/xxx/storagedomains - 'status' should be addressed indeed. (only use-case for status in /api/networks is when network yet not attached to any cluster) > This can, in certain cases, cause unexpected behaviour. > > For example, let's consider this topology: > Data Center A > | > |\____ Network 'red' > |\____ Cluster A1 > | \______ Network 'red' attached > \____ Cluster A2 > \______ Network 'red' attached > > If the 'status' is the same on all the clusters that the network is attached to > (A1, A2) then there will be one element in the top level collection, with the > network details and the 'status' field representing the state (which is same > for all networks in the cluster contexts of the cluster). > If, however, the status is not the same (ie. on A1 the network is > 'Operational' and on A2 it is 'Non Operational') then the top-level > collection will show two elements for the network, where all network > details are the same and only the 'status' field is different. > > This is problematic IMHO for several reasons: > 1. Showing one network in certain states, and multiple copies of this > network in other states is not optimal, to say the least. > 2. In the top-level collection there is no indicator of the cluster for which > the network is displayed, so there is no way to differentiate between the > two 'red' network elements (they will have same id, name, etc.). > 3. There is a certain asymmetry between the remove action[2] and the > result in that you would expect: you either remove a network but in the > result you would see several elements removed. this is not correct, remove from /api/networks is not considered as *detach* from clusters as well, but only as remove from /api/networks which is deletes network from the DC, so it can't be 1:N, if network still attached to cluster/s, backend should block this operation by CDA, this is not api prerogative anyway. > > > -- Proposed Solutions -- > Personally I can think of several solutions to this problem: > 1. Declare the top-level collection as a collection of all networks that are > either attached to cluster or not, and if they are indeed attached then > show the details for each cluster, including a link to the cluster. > 2. Declare the top-level collection as a collection of all networks that are > defined in data-centers, but they will not contain any cluster specific > data, and thus each entry is unique. > > Solution #2 is breaking the API backwards-compatibility, > since it includes > removing certain fields that have appeared today (namely 'status' and > 'display') but IMO would give a better experience since the top-level > collection is actually used for managing networks, and not their attachment > to clusters which should be done in the context of each cluster. i vote for #2, that's the right way to go forward (but only if leaving properties in /api/networks creates logical collisions as in 'status' case) as for now it's only: 'status', 'display', right? > > I would like to hear what suggestions you have to solve this problem or if > you prefer either of the above solutions. > > > -- Footnotes -- > [1] In 3.1 this is slightly different, but for the sake of simplicity I didn't > specify the new behaviour. > [2] Currently you can't update the network if it's attached to any cluster, > but perhaps in the future this would be possible. > > Regards, > Mike > > -- Michael Pasternak RedHat, ENG-Virtualization R&D From mpastern at redhat.com Tue Jul 3 08:20:00 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Tue, 03 Jul 2012 11:20:00 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF29A10.90606@redhat.com> References: <4FF29896.3030700@redhat.com> <4FF29A10.90606@redhat.com> Message-ID: <4FF2AB30.2040303@redhat.com> On 07/03/2012 10:06 AM, Yaniv Kaul wrote: > On 07/03/2012 10:00 AM, Itamar Heim wrote: >> On 07/03/2012 09:51 AM, Avi Tal wrote: >> ... >>> >>> Why do we keep holding this Top level collection instead of having each network related under his datacenter (/api/datacenter/id/networks)??? >> >> why do we keep VMs as top level? they only exist in data center... >> why do we keep Clusters as top level? they only exist in data center... >> why do we keep Templates as top level? they only exist in data center... > > What's the answer to all the above, btw? > Y. 1. they are central entities in the system and should be easily accessed - simplicity. 2. ease on system initiation, i.e creating same sub-resource for different resources is much more easy when you don't have to switch resource collection every time. 3. hypermedia is the engine of the application state (one of the core REST principals). > >> >> all entities are available today as top level as well, so networks are there for consistency >> >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=741111 >>> >>> One solution which is must is to move the top level network (/api/networks) under each Datacenter! not *move*, but to be added as well, we have RFE on this. >>> >>> 1. having top level networks path isn't symmetric to our entire REST API implementation! >>> all other network collections (cluster, hosts, VMs, Templates) placed under their related component. >>> 2. as a REST API user, having sub collection networks under each datacenter is better to handle than parsing a top level collection >>> and comparing DC id in order to get all DC related networks. >>> 3. as for breaking api/ backward compatibility, we can still hold the top level network collection ad deprecated and start exposing the sub collections >>> under each datacenter. >> _______________________________________________ >> 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 -- Michael Pasternak RedHat, ENG-Virtualization R&D From atal at redhat.com Tue Jul 3 10:21:23 2012 From: atal at redhat.com (Avi Tal) Date: Tue, 03 Jul 2012 06:21:23 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF29896.3030700@redhat.com> Message-ID: ----- Original Message ----- > From: "Itamar Heim" > To: "Avi Tal" > Cc: "Mike Kolesnik" , "engine-devel" > Sent: Tuesday, July 3, 2012 10:00:38 AM > Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks > > On 07/03/2012 09:51 AM, Avi Tal wrote: > ... > > > > Why do we keep holding this Top level collection instead of having > > each network related under his datacenter > > (/api/datacenter/id/networks)??? > > why do we keep VMs as top level? they only exist in data center... > why do we keep Clusters as top level? they only exist in data > center... > why do we keep Templates as top level? they only exist in data > center... > > all entities are available today as top level as well, so networks > are > there for consistency So why don't we expose Network as TAB in rhevm UI? (we chose to manage it under DC) > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=741111 > > > > One solution which is must is to move the top level network > > (/api/networks) under each Datacenter! > > > > 1. having top level networks path isn't symmetric to our entire > > REST API implementation! > > all other network collections (cluster, hosts, VMs, Templates) > > placed under their related component. > > 2. as a REST API user, having sub collection networks under each > > datacenter is better to handle than parsing a top level collection > > and comparing DC id in order to get all DC related networks. > > 3. as for breaking api/ backward compatibility, we can still hold > > the top level network collection ad deprecated and start exposing > > the sub collections > > under each datacenter. > From iheim at redhat.com Tue Jul 3 10:36:58 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 03 Jul 2012 13:36:58 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: References: Message-ID: <4FF2CB4A.3000802@redhat.com> On 07/03/2012 01:21 PM, Avi Tal wrote: > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Avi Tal" >> Cc: "Mike Kolesnik" , "engine-devel" >> Sent: Tuesday, July 3, 2012 10:00:38 AM >> Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks >> >> On 07/03/2012 09:51 AM, Avi Tal wrote: >> ... >>> >>> Why do we keep holding this Top level collection instead of having >>> each network related under his datacenter >>> (/api/datacenter/id/networks)??? >> >> why do we keep VMs as top level? they only exist in data center... >> why do we keep Clusters as top level? they only exist in data >> center... >> why do we keep Templates as top level? they only exist in data >> center... >> >> all entities are available today as top level as well, so networks >> are >> there for consistency > > So why don't we expose Network as TAB in rhevm UI? (we chose to manage it under DC) coming soon to an ovirt near you... > >> >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=741111 >>> >>> One solution which is must is to move the top level network >>> (/api/networks) under each Datacenter! >>> >>> 1. having top level networks path isn't symmetric to our entire >>> REST API implementation! >>> all other network collections (cluster, hosts, VMs, Templates) >>> placed under their related component. >>> 2. as a REST API user, having sub collection networks under each >>> datacenter is better to handle than parsing a top level collection >>> and comparing DC id in order to get all DC related networks. >>> 3. as for breaking api/ backward compatibility, we can still hold >>> the top level network collection ad deprecated and start exposing >>> the sub collections >>> under each datacenter. >> From oschreib at redhat.com Tue Jul 3 13:43:49 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Tue, 03 Jul 2012 09:43:49 -0400 (EDT) Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: <490d5f1f-3dc3-47cd-bea8-a2e610c78ec4@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <0135326e-782a-47a2-890d-33ddc65554a5@zmail14.collab.prod.int.phx2.redhat.com> In our days, ovirt-engine-setup is a part of the big ovirt-engine rpm. This means that each time you need to build yourself a new ovirt-engine-setup rpm, you need to compile all the engine. I've started to think about separating it into another git (similar to ovirt-iso-uploader), so we will be able to build this rpm separately. This change is really easy to implement (actually, I have already done it locally), and sounds to me like it's the right thing to do. Thought? Ofer. From jhernand at redhat.com Tue Jul 3 13:53:35 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Tue, 03 Jul 2012 15:53:35 +0200 Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: <0135326e-782a-47a2-890d-33ddc65554a5@zmail14.collab.prod.int.phx2.redhat.com> References: <0135326e-782a-47a2-890d-33ddc65554a5@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FF2F95F.4000302@redhat.com> On 07/03/2012 03:43 PM, Ofer Schreiber wrote: > In our days, ovirt-engine-setup is a part of the big ovirt-engine rpm. > This means that each time you need to build yourself a new ovirt-engine-setup rpm, you need to compile all the engine. > > I've started to think about separating it into another git (similar to ovirt-iso-uploader), so we will be able to build this rpm separately. > > This change is really easy to implement (actually, I have already done it locally), and sounds to me like it's the right thing to do. > > Thought? > Ofer. I agree that is the right thing to do. Take into account that this also means that ovirt-engine-setup will no longer be a subpackage of ovirt-engine, so you will have to submit a new package request to have it included in Fedora. -- 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 michal.skrivanek at redhat.com Tue Jul 3 15:20:43 2012 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Tue, 3 Jul 2012 18:20:43 +0300 Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: <4FF2F95F.4000302@redhat.com> References: <0135326e-782a-47a2-890d-33ddc65554a5@zmail14.collab.prod.int.phx2.redhat.com> <4FF2F95F.4000302@redhat.com> Message-ID: On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: > On 07/03/2012 03:43 PM, Ofer Schreiber wrote: >> In our days, ovirt-engine-setup is a part of the big ovirt-engine rpm. >> This means that each time you need to build yourself a new ovirt-engine-setup rpm, you need to compile all the engine. >> >> I've started to think about separating it into another git (similar to ovirt-iso-uploader), so we will be able to build this rpm separately. >> >> This change is really easy to implement (actually, I have already done it locally), and sounds to me like it's the right thing to do. >> >> Thought? >> Ofer. > > I agree that is the right thing to do. Take into account that this also > means that ovirt-engine-setup will no longer be a subpackage of > ovirt-engine, so you will have to submit a new package request to have > it included in Fedora. not quite sure having 10+ packages is a win? - why do you have to have a separate git? - why do you have to recompile when there's a change elsewhere? isn't that a matter of compilation scripts only? (though understand size of the rpm might be an issue?) I personally do not see a point in separating of something inseparable?but that's just me perhaps:) in other words, if you would kindly explain me the benefits please, I'll shut up:-) > > -- > 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. > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ashakarc at redhat.com Tue Jul 3 15:32:08 2012 From: ashakarc at redhat.com (Asaf Shakarchi) Date: Tue, 03 Jul 2012 11:32:08 -0400 (EDT) Subject: [Engine-devel] Search option for finding disks for templates / vms In-Reply-To: <31603964.94.1341329210803.JavaMail.asaf@asafnb.int.vertix-tech.com> Message-ID: <16225726.103.1341329516309.JavaMail.asaf@asafnb.int.vertix-tech.com> Hey, https://bugzilla.redhat.com/show_bug.cgi?id=828089 I would like add a search option for searching disks of a VM or Template, Please suggest a name for the search option, In the 'view' level we call it 'entity_type', but maybe 'type' is nicer ? (or not too specific?) Thanks, Regards, Asaf From mkenneth at redhat.com Tue Jul 3 15:44:40 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Tue, 03 Jul 2012 11:44:40 -0400 (EDT) Subject: [Engine-devel] Search option for finding disks for templates / vms In-Reply-To: <16225726.103.1341329516309.JavaMail.asaf@asafnb.int.vertix-tech.com> Message-ID: <30483804.5077.1341330277976.JavaMail.mkenneth@mkenneth.csb> ----- Original Message ----- > Hey, > > https://bugzilla.redhat.com/show_bug.cgi?id=828089 > > I would like add a search option for searching disks of a VM or > Template, > > Please suggest a name for the search option, > In the 'view' level we call it 'entity_type', but maybe 'type' is > nicer ? (or not too specific?) Belongs-To/Attached-To/ > > > Thanks, > > > > Regards, > Asaf > > > > From iheim at redhat.com Tue Jul 3 18:28:14 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 03 Jul 2012 21:28:14 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF29F82.6080602@redhat.com> References: <9edb9ba5-e158-40a2-b454-96807c486cce@zmail14.collab.prod.int.phx2.redhat.com> <4FF29F82.6080602@redhat.com> Message-ID: <4FF339BE.2040302@redhat.com> On 07/03/2012 10:30 AM, Livnat Peer wrote: > On 02/07/12 17:35, Mike Kolesnik wrote: >> Hi All, >> >> I would like to hear opinions about a behaviour that I think is >> problematic in >> REST API handling of logical networks. >> >> -- Intro -- >> Today in the REST API we are exposing two collections for "logical >> network" related entities. >> >> First is a top level collection which is out of any context at the address >> http://engine/api/networks. >> Second is a sub-collection in the context of a cluster: >> http://engine/api/cluster/xxx/networks >> >> The network itself is defined per DC level, so for each DC you would have >> at least one logical network for management, which has some properties such >> as STP, MTU, etc.. >> The top level collection is used to create/delete such network entities. >> >> The sub-collection in the context of a Cluster is used to attach/detach a >> network from the DC of that cluster. >> The network in the context of a cluster has some additional information, >> let's >> say for example 'status' of the network: >> If a network is defined on all hosts in the cluster then it's status is >> 'Operational'. >> If a network is not defined on some of the hosts in the cluster then >> it's >> status is 'Not Operational'[1]. >> >> >> -- Problem -- >> The problem is that details which are only relevant in context of a >> cluster, are still displayed in the root context as well (e.g: 'status'). >> This can, in certain cases, cause unexpected behaviour. >> >> For example, let's consider this topology: >> Data Center A >> | >> |\____ Network 'red' >> |\____ Cluster A1 >> | \______ Network 'red' attached >> \____ Cluster A2 >> \______ Network 'red' attached >> >> If the 'status' is the same on all the clusters that the network is >> attached to >> (A1, A2) then there will be one element in the top level collection, >> with the >> network details and the 'status' field representing the state (which is same >> for all networks in the cluster contexts of the cluster). >> If, however, the status is not the same (ie. on A1 the network is >> 'Operational' and on A2 it is 'Non Operational') then the top-level >> collection will show two elements for the network, where all network >> details are the same and only the 'status' field is different. >> > > That sounds like a bug to me. > I think that top collection should include only DC level properties and > not cluster level properties, status should not be there (same as > display required etc.) > > >> This is problematic IMHO for several reasons: >> 1. Showing one network in certain states, and multiple copies of this >> network in other states is not optimal, to say the least. >> 2. In the top-level collection there is no indicator of the cluster >> for which >> the network is displayed, so there is no way to differentiate >> between the >> two 'red' network elements (they will have same id, name, etc.). >> 3. There is a certain asymmetry between the remove action[2] and the >> result in that you would expect: you either remove a network but >> in the >> result you would see several elements removed. >> >> >> -- Proposed Solutions -- >> Personally I can think of several solutions to this problem: >> 1. Declare the top-level collection as a collection of all networks >> that are >> either attached to cluster or not, and if they are indeed attached >> then >> show the details for each cluster, including a link to the cluster. >> 2. Declare the top-level collection as a collection of all networks >> that are >> defined in data-centers, but they will not contain any cluster >> specific >> data, and thus each entry is unique. >> >> Solution #2 is breaking the API backwards-compatibility, since it includes >> removing certain fields that have appeared today (namely 'status' and >> 'display') but IMO would give a better experience since the top-level >> collection is actually used for managing networks, and not their attachment >> to clusters which should be done in the context of each cluster. >> > I really don't think top collections should include cluster networks it > is not user-friendly to say the least. how is that different from top collections including VMs and templates? (or logical networks becoming main tab in the UI going forward) > > I vote for the second option, I don't think that having a bug in > previous versions should drive this decision. > > >> I would like to hear what suggestions you have to solve this problem or if >> you prefer either of the above solutions. >> >> >> -- Footnotes -- >> [1] In 3.1 this is slightly different, but for the sake of simplicity I >> didn't >> specify the new behaviour. >> [2] Currently you can't update the network if it's attached to any cluster, >> but perhaps in the future this would be possible. >> >> Regards, >> Mike >> >> > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Tue Jul 3 18:56:29 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 03 Jul 2012 21:56:29 +0300 Subject: [Engine-devel] Search option for finding disks for templates / vms In-Reply-To: <30483804.5077.1341330277976.JavaMail.mkenneth@mkenneth.csb> References: <30483804.5077.1341330277976.JavaMail.mkenneth@mkenneth.csb> Message-ID: <4FF3405D.6040105@redhat.com> On 07/03/2012 06:44 PM, Miki Kenneth wrote: > > > ----- Original Message ----- >> Hey, >> >> https://bugzilla.redhat.com/show_bug.cgi?id=828089 >> >> I would like add a search option for searching disks of a VM or >> Template, >> >> Please suggest a name for the search option, >> In the 'view' level we call it 'entity_type', but maybe 'type' is >> nicer ? (or not too specific?) > Belongs-To/Attached-To/ iiuc, this isn't about the vm it is attached to (which would be vm=xxxx or disk.vm =xxxx i hope). this is about showing disks of VMs or Templates. so its more like "parent_type". though i don't have a good name to offer >> >> >> Thanks, >> >> >> >> Regards, >> Asaf >> >> >> >> From lpeer at redhat.com Tue Jul 3 19:06:37 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 03 Jul 2012 22:06:37 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF339BE.2040302@redhat.com> References: <9edb9ba5-e158-40a2-b454-96807c486cce@zmail14.collab.prod.int.phx2.redhat.com> <4FF29F82.6080602@redhat.com> <4FF339BE.2040302@redhat.com> Message-ID: <4FF342BD.4020007@redhat.com> On 03/07/12 21:28, Itamar Heim wrote: > On 07/03/2012 10:30 AM, Livnat Peer wrote: >> On 02/07/12 17:35, Mike Kolesnik wrote: >>> Hi All, >>> >>> I would like to hear opinions about a behaviour that I think is >>> problematic in >>> REST API handling of logical networks. >>> >>> -- Intro -- >>> Today in the REST API we are exposing two collections for "logical >>> network" related entities. >>> >>> First is a top level collection which is out of any context at the >>> address >>> http://engine/api/networks. >>> Second is a sub-collection in the context of a cluster: >>> http://engine/api/cluster/xxx/networks >>> >>> The network itself is defined per DC level, so for each DC you would >>> have >>> at least one logical network for management, which has some >>> properties such >>> as STP, MTU, etc.. >>> The top level collection is used to create/delete such network entities. >>> >>> The sub-collection in the context of a Cluster is used to >>> attach/detach a >>> network from the DC of that cluster. >>> The network in the context of a cluster has some additional information, >>> let's >>> say for example 'status' of the network: >>> If a network is defined on all hosts in the cluster then it's >>> status is >>> 'Operational'. >>> If a network is not defined on some of the hosts in the cluster >>> then >>> it's >>> status is 'Not Operational'[1]. >>> >>> >>> -- Problem -- >>> The problem is that details which are only relevant in context of a >>> cluster, are still displayed in the root context as well (e.g: >>> 'status'). >>> This can, in certain cases, cause unexpected behaviour. >>> >>> For example, let's consider this topology: >>> Data Center A >>> | >>> |\____ Network 'red' >>> |\____ Cluster A1 >>> | \______ Network 'red' attached >>> \____ Cluster A2 >>> \______ Network 'red' attached >>> >>> If the 'status' is the same on all the clusters that the network is >>> attached to >>> (A1, A2) then there will be one element in the top level collection, >>> with the >>> network details and the 'status' field representing the state (which >>> is same >>> for all networks in the cluster contexts of the cluster). >>> If, however, the status is not the same (ie. on A1 the network is >>> 'Operational' and on A2 it is 'Non Operational') then the top-level >>> collection will show two elements for the network, where all network >>> details are the same and only the 'status' field is different. >>> >> >> That sounds like a bug to me. >> I think that top collection should include only DC level properties and >> not cluster level properties, status should not be there (same as >> display required etc.) >> >> >>> This is problematic IMHO for several reasons: >>> 1. Showing one network in certain states, and multiple copies of this >>> network in other states is not optimal, to say the least. >>> 2. In the top-level collection there is no indicator of the cluster >>> for which >>> the network is displayed, so there is no way to differentiate >>> between the >>> two 'red' network elements (they will have same id, name, etc.). >>> 3. There is a certain asymmetry between the remove action[2] and the >>> result in that you would expect: you either remove a network but >>> in the >>> result you would see several elements removed. >>> >>> >>> -- Proposed Solutions -- >>> Personally I can think of several solutions to this problem: >>> 1. Declare the top-level collection as a collection of all networks >>> that are >>> either attached to cluster or not, and if they are indeed >>> attached >>> then >>> show the details for each cluster, including a link to the >>> cluster. >>> 2. Declare the top-level collection as a collection of all networks >>> that are >>> defined in data-centers, but they will not contain any cluster >>> specific >>> data, and thus each entry is unique. >>> >>> Solution #2 is breaking the API backwards-compatibility, since it >>> includes >>> removing certain fields that have appeared today (namely 'status' and >>> 'display') but IMO would give a better experience since the top-level >>> collection is actually used for managing networks, and not their >>> attachment >>> to clusters which should be done in the context of each cluster. >>> >> I really don't think top collections should include cluster networks it >> is not user-friendly to say the least. > > how is that different from top collections including VMs and templates? > (or logical networks becoming main tab in the UI going forward) > I think you missed the point of cluster network entity vs. DC network entity. we should have in the top collection a DC network, I think we should not display the network per cluster in top network collection (that can be viewed under the cluster context). >> >> I vote for the second option, I don't think that having a bug in >> previous versions should drive this decision. >> >> >>> I would like to hear what suggestions you have to solve this problem >>> or if >>> you prefer either of the above solutions. >>> >>> >>> -- Footnotes -- >>> [1] In 3.1 this is slightly different, but for the sake of simplicity I >>> didn't >>> specify the new behaviour. >>> [2] Currently you can't update the network if it's attached to any >>> cluster, >>> but perhaps in the future this would be possible. >>> >>> Regards, >>> Mike >>> >>> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > From danken at redhat.com Tue Jul 3 19:23:13 2012 From: danken at redhat.com (Dan Kenigsberg) Date: Tue, 3 Jul 2012 22:23:13 +0300 Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: References: <0135326e-782a-47a2-890d-33ddc65554a5@zmail14.collab.prod.int.phx2.redhat.com> <4FF2F95F.4000302@redhat.com> Message-ID: <20120703192312.GC22203@redhat.com> On Tue, Jul 03, 2012 at 06:20:43PM +0300, Michal Skrivanek wrote: > On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: > > > On 07/03/2012 03:43 PM, Ofer Schreiber wrote: > >> In our days, ovirt-engine-setup is a part of the big ovirt-engine rpm. > >> This means that each time you need to build yourself a new ovirt-engine-setup rpm, you need to compile all the engine. Could this possibly be avoided by an optional flag to the build script? > >> > >> I've started to think about separating it into another git (similar to ovirt-iso-uploader), so we will be able to build this rpm separately. > >> > >> This change is really easy to implement (actually, I have already done it locally), and sounds to me like it's the right thing to do. > >> > >> Thought? > >> Ofer. > > > > I agree that is the right thing to do. Take into account that this also > > means that ovirt-engine-setup will no longer be a subpackage of > > ovirt-engine, so you will have to submit a new package request to have > > it included in Fedora. > not quite sure having 10+ packages is a win? > - why do you have to have a separate git? > - why do you have to recompile when there's a change elsewhere? isn't that a matter of compilation scripts only? (though understand size of the rpm might be an issue?) > I personally do not see a point in separating of something inseparable?but that's just me perhaps:) > > in other words, if you would kindly explain me the benefits please, I'll shut up:-) indeed - having another package, with its own release cycle and versioning scheme is quite costy. and isn't ovirt-engine-setup quite tightly coupled with Engine's db scheme? (I really do not know, I should probably shut up, too). From iheim at redhat.com Tue Jul 3 19:29:10 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 03 Jul 2012 22:29:10 +0300 Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: <20120703192312.GC22203@redhat.com> References: <0135326e-782a-47a2-890d-33ddc65554a5@zmail14.collab.prod.int.phx2.redhat.com> <4FF2F95F.4000302@redhat.com> <20120703192312.GC22203@redhat.com> Message-ID: <4FF34806.5070400@redhat.com> On 07/03/2012 10:23 PM, Dan Kenigsberg wrote: > On Tue, Jul 03, 2012 at 06:20:43PM +0300, Michal Skrivanek wrote: >> On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: >> >>> On 07/03/2012 03:43 PM, Ofer Schreiber wrote: >>>> In our days, ovirt-engine-setup is a part of the big ovirt-engine rpm. >>>> This means that each time you need to build yourself a new ovirt-engine-setup rpm, you need to compile all the engine. > > Could this possibly be avoided by an optional flag to the build script? indeed. or make rpm after 'cd packaging' would only build the packaging, or configure script on what to build, etc. From abaron at redhat.com Tue Jul 3 20:33:27 2012 From: abaron at redhat.com (Ayal Baron) Date: Tue, 03 Jul 2012 16:33:27 -0400 (EDT) Subject: [Engine-devel] Search option for finding disks for templates / vms In-Reply-To: <4FF3405D.6040105@redhat.com> Message-ID: <70123791-23a9-4389-86a3-52df2e96b561@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 07/03/2012 06:44 PM, Miki Kenneth wrote: > > > > > > ----- Original Message ----- > >> Hey, > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=828089 > >> > >> I would like add a search option for searching disks of a VM or > >> Template, > >> > >> Please suggest a name for the search option, > >> In the 'view' level we call it 'entity_type', but maybe 'type' is > >> nicer ? (or not too specific?) > > Belongs-To/Attached-To/ > > iiuc, this isn't about the vm it is attached to (which would be > vm=xxxx > or disk.vm =xxxx i hope). > this is about showing disks of VMs or Templates. > so its more like "parent_type". > though i don't have a good name to offer Neither. There is no such thing as a VM disk or a Template disk. There are ReadOnly disks and Writeable disks. It just so happens that currently we only support read-only disks in templates, but we will probably remove this limitation in the future. > > >> > >> > >> Thanks, > >> > >> > >> > >> Regards, > >> Asaf > >> > >> > >> > >> > > > From yzaslavs at redhat.com Wed Jul 4 05:40:20 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Wed, 04 Jul 2012 08:40:20 +0300 Subject: [Engine-devel] Search option for finding disks for templates / vms In-Reply-To: <30483804.5077.1341330277976.JavaMail.mkenneth@mkenneth.csb> References: <30483804.5077.1341330277976.JavaMail.mkenneth@mkenneth.csb> Message-ID: <4FF3D744.1070403@redhat.com> On 07/03/2012 06:44 PM, Miki Kenneth wrote: > > > ----- Original Message ----- >> Hey, >> >> https://bugzilla.redhat.com/show_bug.cgi?id=828089 >> >> I would like add a search option for searching disks of a VM or >> Template, >> >> Please suggest a name for the search option, >> In the 'view' level we call it 'entity_type', but maybe 'type' is >> nicer ? (or not too specific?) > Belongs-To/Attached-To/ Part of? >> >> >> Thanks, >> >> >> >> Regards, >> Asaf >> >> >> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From abaron at redhat.com Wed Jul 4 06:29:55 2012 From: abaron at redhat.com (Ayal Baron) Date: Wed, 04 Jul 2012 02:29:55 -0400 (EDT) Subject: [Engine-devel] Search option for finding disks for templates / vms In-Reply-To: <4FF3D744.1070403@redhat.com> Message-ID: <4a80d8fe-39c8-450f-81a7-d39bdd40c5be@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 07/03/2012 06:44 PM, Miki Kenneth wrote: > > > > > > ----- Original Message ----- > >> Hey, > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=828089 > >> > >> I would like add a search option for searching disks of a VM or > >> Template, > >> > >> Please suggest a name for the search option, > >> In the 'view' level we call it 'entity_type', but maybe 'type' is > >> nicer ? (or not too specific?) > > Belongs-To/Attached-To/ > Part of? So what do you do with a disk that is both in a template and attached read-only to a VM? (no, we do not currently support it, but we will as there is no reason not to). When a container references the disk, that is not a property of the disk so there should be no column indicating that when looking at the disk. The disk is either read only or read write, that's it. The column should state that. > >> > >> > >> Thanks, > >> > >> > >> > >> Regards, > >> Asaf > >> > >> > >> > >> > > _______________________________________________ > > 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 oschreib at redhat.com Wed Jul 4 07:16:17 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 04 Jul 2012 03:16:17 -0400 (EDT) Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: <20120703192312.GC22203@redhat.com> Message-ID: ----- Original Message ----- > On Tue, Jul 03, 2012 at 06:20:43PM +0300, Michal Skrivanek wrote: > > On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: > > > > > On 07/03/2012 03:43 PM, Ofer Schreiber wrote: > > >> In our days, ovirt-engine-setup is a part of the big > > >> ovirt-engine rpm. > > >> This means that each time you need to build yourself a new > > >> ovirt-engine-setup rpm, you need to compile all the engine. > > Could this possibly be avoided by an optional flag to the build > script? It's problematic, as ovirt-engine-setup is a sub rpm of ovirt-engine. I have no idea how can we just build the setup without the engine, which is compiled in a temporary directory (and removed straight after the build) > > > >> > > >> I've started to think about separating it into another git > > >> (similar to ovirt-iso-uploader), so we will be able to build > > >> this rpm separately. > > >> > > >> This change is really easy to implement (actually, I have > > >> already done it locally), and sounds to me like it's the right > > >> thing to do. > > >> > > >> Thought? > > >> Ofer. > > > > > > I agree that is the right thing to do. Take into account that > > > this also > > > means that ovirt-engine-setup will no longer be a subpackage of > > > ovirt-engine, so you will have to submit a new package request to > > > have > > > it included in Fedora. > > not quite sure having 10+ packages is a win? > > - why do you have to have a separate git? > > - why do you have to recompile when there's a change elsewhere? > > isn't that a matter of compilation scripts only? (though > > understand size of the rpm might be an issue?) > > I personally do not see a point in separating of something > > inseparable?but that's just me perhaps:) > > > > in other words, if you would kindly explain me the benefits please, > > I'll shut up:-) > > indeed - having another package, with its own release cycle and > versioning scheme is quite costy. and isn't ovirt-engine-setup quite > tightly coupled with Engine's db scheme? (I really do not know, I > should > probably shut up, too). Quite costly? why? engine-setup is not tightly coupled with the db-scripts, we just execute the createDB script. > From oschreib at redhat.com Wed Jul 4 07:22:21 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 04 Jul 2012 03:22:21 -0400 (EDT) Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: <4FF34806.5070400@redhat.com> Message-ID: <8033072c-4499-45d3-b2cc-9839826555db@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 07/03/2012 10:23 PM, Dan Kenigsberg wrote: > > On Tue, Jul 03, 2012 at 06:20:43PM +0300, Michal Skrivanek wrote: > >> On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: > >> > >>> On 07/03/2012 03:43 PM, Ofer Schreiber wrote: > >>>> In our days, ovirt-engine-setup is a part of the big > >>>> ovirt-engine rpm. > >>>> This means that each time you need to build yourself a new > >>>> ovirt-engine-setup rpm, you need to compile all the engine. > > > > Could this possibly be avoided by an optional flag to the build > > script? > > indeed. > or make rpm after 'cd packaging' would only build the packaging, or > configure script on what to build, etc. 1. the "cd packaging" option is possible, but it means we will have another Makefile and spec file inside the packaging dir, just for engine-setup. This will actually separate engine-setup rpm from the ovirt-engine base rpm, and will require the same release-cycle/versioning/etc as Dan stated. Doing this will just save us the external git, as it will have to be a separate package, just inside the same git 2. configure script is fine, but as long as we're a sub-package of ovirt-engine, we will have to build the engine every time we want to build the setup. > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From oschreib at redhat.com Wed Jul 4 07:36:44 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 04 Jul 2012 03:36:44 -0400 (EDT) Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: Message-ID: <42985470-a0b3-4087-a9fd-f5d89e3f3b41@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: > > > On 07/03/2012 03:43 PM, Ofer Schreiber wrote: > >> In our days, ovirt-engine-setup is a part of the big ovirt-engine > >> rpm. > >> This means that each time you need to build yourself a new > >> ovirt-engine-setup rpm, you need to compile all the engine. > >> > >> I've started to think about separating it into another git > >> (similar to ovirt-iso-uploader), so we will be able to build this > >> rpm separately. > >> > >> This change is really easy to implement (actually, I have already > >> done it locally), and sounds to me like it's the right thing to > >> do. > >> > >> Thought? > >> Ofer. > > > > I agree that is the right thing to do. Take into account that this > > also > > means that ovirt-engine-setup will no longer be a subpackage of > > ovirt-engine, so you will have to submit a new package request to > > have > > it included in Fedora. > not quite sure having 10+ packages is a win? > - why do you have to have a separate git? I don't, we can do it in the same one. still, it will be a separate package... > - why do you have to recompile when there's a change elsewhere? isn't > that a matter of compilation scripts only? (though understand size > of the rpm might be an issue?) Well, the it's not just a "build script", we're doing this inside RPM. The process is as follows: 1. create tarball from the git 2. build srpm with the spec and the tarball 3. build the rpm from the srpm, which means: - open the tarball in a temp director - compile everything in the same temp dir - put the compiled binaries in the right directory (some sort of chroot env, like /home/ofer/rpmbuild/BUILDROOT/usr/share/ovirt-engine) - create the actual rpm AFAIK, this is the rpm-build way, I don't really have control over these steps. > I personally do not see a point in separating of something > inseparable?but that's just me perhaps:) > > in other words, if you would kindly explain me the benefits please, > I'll shut up:-) Benefits: 1. 10 seconds to build the setup rpm (this can be done also in the same git, but separating the spec/makefile) 2. No need to rebuild the entire engine for a small TEXT change in the setup (same) 3. No need to rebuild (and re-test) the setup with every change to the engine. (same) The only argument I have in favor of creating a separate git is that it sounds to me better than having two separate rpm spec/make in the same git. > > > > > > -- > > 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. > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From ecohen at redhat.com Wed Jul 4 07:58:35 2012 From: ecohen at redhat.com (Einav Cohen) Date: Wed, 04 Jul 2012 03:58:35 -0400 (EDT) Subject: [Engine-devel] Search option for finding disks for templates / vms In-Reply-To: <4a80d8fe-39c8-450f-81a7-d39bdd40c5be@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <68559418-f824-4300-92f8-e36be0bb7958@zmail20.collab.prod.int.phx2.redhat.com> > ----- Original Message ----- > From: "Ayal Baron" > Sent: Wednesday, July 4, 2012 9:29:55 AM > > ----- Original Message ----- > > On 07/03/2012 06:44 PM, Miki Kenneth wrote: > > > > > > > > > ----- Original Message ----- > > >> Hey, > > >> > > >> https://bugzilla.redhat.com/show_bug.cgi?id=828089 > > >> > > >> I would like add a search option for searching disks of a VM or > > >> Template, > > >> > > >> Please suggest a name for the search option, > > >> In the 'view' level we call it 'entity_type', but maybe 'type' > > >> is > > >> nicer ? (or not too specific?) > > > Belongs-To/Attached-To/ > > Part of? > > So what do you do with a disk that is both in a template and attached > read-only to a VM? (no, we do not currently support it, but we will > as there is no reason not to). > When a container references the disk, that is not a property of the > disk so there should be no column indicating that when looking at > the disk. > The disk is either read only or read write, that's it. The column > should state that. I think that "read-only/read-write" is not related to "attached to Template(s)/attached to VM(s)/attached to both (not supported yet)". Moreover, wouldn't we want "read-only/read-write" to be per VM/Template, and not a property of the Disk itself (i.e. a disk can be writable in VM1 and read-only in VM2/Template1)? As opposed to the "attached to Templates/attached to VMs" information, which is clearly a property of the Disk (well, not a "real" property, as Ayal has also mentioned - it is calculated information, based on the entities to which the disk is attached to; still, it is interesting information that "deserves" a column in the Disks main-grid IMO. ["read-only/read-write" is interesting information as well, and should also be displayed - don't know if in the main grid or in the VMs/Templates sub-tabs - probably worth a separate discussion] > > > > >> > > >> > > >> Thanks, > > >> > > >> > > >> > > >> Regards, > > >> Asaf > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > 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 jhernand at redhat.com Wed Jul 4 08:41:57 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 04 Jul 2012 10:41:57 +0200 Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: <42985470-a0b3-4087-a9fd-f5d89e3f3b41@zmail14.collab.prod.int.phx2.redhat.com> References: <42985470-a0b3-4087-a9fd-f5d89e3f3b41@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FF401D5.60305@redhat.com> On 07/04/2012 09:36 AM, Ofer Schreiber wrote: > > > ----- Original Message ----- >> On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: >> >>> On 07/03/2012 03:43 PM, Ofer Schreiber wrote: >>>> In our days, ovirt-engine-setup is a part of the big ovirt-engine >>>> rpm. >>>> This means that each time you need to build yourself a new >>>> ovirt-engine-setup rpm, you need to compile all the engine. >>>> >>>> I've started to think about separating it into another git >>>> (similar to ovirt-iso-uploader), so we will be able to build this >>>> rpm separately. >>>> >>>> This change is really easy to implement (actually, I have already >>>> done it locally), and sounds to me like it's the right thing to >>>> do. >>>> >>>> Thought? >>>> Ofer. >>> >>> I agree that is the right thing to do. Take into account that this >>> also >>> means that ovirt-engine-setup will no longer be a subpackage of >>> ovirt-engine, so you will have to submit a new package request to >>> have >>> it included in Fedora. >> not quite sure having 10+ packages is a win? >> - why do you have to have a separate git? > > I don't, we can do it in the same one. still, it will be a separate package... > >> - why do you have to recompile when there's a change elsewhere? isn't >> that a matter of compilation scripts only? (though understand size >> of the rpm might be an issue?) > > Well, the it's not just a "build script", we're doing this inside RPM. > The process is as follows: > 1. create tarball from the git > 2. build srpm with the spec and the tarball > 3. build the rpm from the srpm, which means: > - open the tarball in a temp director > - compile everything in the same temp dir > - put the compiled binaries in the right directory (some sort of chroot env, like /home/ofer/rpmbuild/BUILDROOT/usr/share/ovirt-engine) > - create the actual rpm > > AFAIK, this is the rpm-build way, I don't really have control over these steps. Correct, that is how the RPM build process works. It is not impossible to make it work in a different way, but then it becomes impossible to maintain very quickly. >> I personally do not see a point in separating of something >> inseparable?but that's just me perhaps:) >> >> in other words, if you would kindly explain me the benefits please, >> I'll shut up:-) > > Benefits: > 1. 10 seconds to build the setup rpm (this can be done also in the same git, but separating the spec/makefile) > 2. No need to rebuild the entire engine for a small TEXT change in the setup (same) > 3. No need to rebuild (and re-test) the setup with every change to the engine. (same) > > The only argument I have in favor of creating a separate git is that it sounds to me better than having two separate rpm spec/make in the same git. -- 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 danken at redhat.com Wed Jul 4 09:11:48 2012 From: danken at redhat.com (Dan Kenigsberg) Date: Wed, 4 Jul 2012 12:11:48 +0300 Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: References: <20120703192312.GC22203@redhat.com> Message-ID: <20120704091147.GC15123@redhat.com> On Wed, Jul 04, 2012 at 03:16:17AM -0400, Ofer Schreiber wrote: > > > ----- Original Message ----- > > On Tue, Jul 03, 2012 at 06:20:43PM +0300, Michal Skrivanek wrote: > > > On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: > > > > > > > On 07/03/2012 03:43 PM, Ofer Schreiber wrote: > > > >> In our days, ovirt-engine-setup is a part of the big > > > >> ovirt-engine rpm. > > > >> This means that each time you need to build yourself a new > > > >> ovirt-engine-setup rpm, you need to compile all the engine. > > > > Could this possibly be avoided by an optional flag to the build > > script? > > It's problematic, as ovirt-engine-setup is a sub rpm of ovirt-engine. > I have no idea how can we just build the setup without the engine, which is compiled in a temporary directory (and removed straight after the build) > > > > > > >> > > > >> I've started to think about separating it into another git > > > >> (similar to ovirt-iso-uploader), so we will be able to build > > > >> this rpm separately. > > > >> > > > >> This change is really easy to implement (actually, I have > > > >> already done it locally), and sounds to me like it's the right > > > >> thing to do. > > > >> > > > >> Thought? > > > >> Ofer. > > > > > > > > I agree that is the right thing to do. Take into account that > > > > this also > > > > means that ovirt-engine-setup will no longer be a subpackage of > > > > ovirt-engine, so you will have to submit a new package request to > > > > have > > > > it included in Fedora. > > > not quite sure having 10+ packages is a win? > > > - why do you have to have a separate git? > > > - why do you have to recompile when there's a change elsewhere? > > > isn't that a matter of compilation scripts only? (though > > > understand size of the rpm might be an issue?) > > > I personally do not see a point in separating of something > > > inseparable?but that's just me perhaps:) > > > > > > in other words, if you would kindly explain me the benefits please, > > > I'll shut up:-) > > > > indeed - having another package, with its own release cycle and > > versioning scheme is quite costy. and isn't ovirt-engine-setup quite > > tightly coupled with Engine's db scheme? (I really do not know, I > > should > > probably shut up, too). > > Quite costly? why? It is another package to release, that requires its own errata process and inter-package dependencies. If you envisage a user that would like to use ovirt-engine-setup of one version, with an ovirt-setup of another one, then go ahead. I simply do not see the use case for this, only the complications. > > engine-setup is not tightly coupled with the db-scripts, we just execute the createDB script. > > > From oschreib at redhat.com Wed Jul 4 14:51:13 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Wed, 04 Jul 2012 10:51:13 -0400 (EDT) Subject: [Engine-devel] oVirt 3.1 - New beta RPMs available In-Reply-To: Message-ID: <7e8320e8-a234-4d55-993c-a0460e8b4aba@zmail14.collab.prod.int.phx2.redhat.com> New set of VDSM & oVirt Engine RPMs (Fedora 17 based) has been uploaded to ovirt.org [1] As those RPMs contains critical bug fixes, the oVirt team will appreciate any kind input and bug verification [2]. Thanks, Ofer Schreiber oVirt Release Manager [1] www.ovirt.org/releases/beta/fedora/17/ [2] Specifically, We would like to verify the following BZs: https://bugzilla.redhat.com/buglist.cgi?quicksearch=831998%20832577%20833119%20833201&list_id=246593 From simon at redhat.com Wed Jul 4 16:27:12 2012 From: simon at redhat.com (Simon Grinberg) Date: Wed, 04 Jul 2012 12:27:12 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF342BD.4020007@redhat.com> Message-ID: <75d4bf72-d269-4ada-bbbc-958dca45073a@zmail17.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Livnat Peer" > To: "Itamar Heim" > Cc: "engine-devel" > Sent: Tuesday, July 3, 2012 10:06:37 PM > Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks > > On 03/07/12 21:28, Itamar Heim wrote: > > On 07/03/2012 10:30 AM, Livnat Peer wrote: > >> On 02/07/12 17:35, Mike Kolesnik wrote: > >>> Hi All, > >>> > >>> I would like to hear opinions about a behaviour that I think is > >>> problematic in > >>> REST API handling of logical networks. > >>> > >>> -- Intro -- > >>> Today in the REST API we are exposing two collections for > >>> "logical > >>> network" related entities. > >>> > >>> First is a top level collection which is out of any context at > >>> the > >>> address > >>> http://engine/api/networks. > >>> Second is a sub-collection in the context of a cluster: > >>> http://engine/api/cluster/xxx/networks > >>> > >>> The network itself is defined per DC level, so for each DC you > >>> would > >>> have > >>> at least one logical network for management, which has some > >>> properties such > >>> as STP, MTU, etc.. > >>> The top level collection is used to create/delete such network > >>> entities. > >>> > >>> The sub-collection in the context of a Cluster is used to > >>> attach/detach a > >>> network from the DC of that cluster. > >>> The network in the context of a cluster has some additional > >>> information, > >>> let's > >>> say for example 'status' of the network: > >>> If a network is defined on all hosts in the cluster then > >>> it's > >>> status is > >>> 'Operational'. > >>> If a network is not defined on some of the hosts in the > >>> cluster > >>> then > >>> it's > >>> status is 'Not Operational'[1]. > >>> > >>> > >>> -- Problem -- > >>> The problem is that details which are only relevant in context of > >>> a > >>> cluster, are still displayed in the root context as well (e.g: > >>> 'status'). > >>> This can, in certain cases, cause unexpected behaviour. > >>> > >>> For example, let's consider this topology: > >>> Data Center A > >>> | > >>> |\____ Network 'red' > >>> |\____ Cluster A1 > >>> | \______ Network 'red' attached > >>> \____ Cluster A2 > >>> \______ Network 'red' attached > >>> > >>> If the 'status' is the same on all the clusters that the network > >>> is > >>> attached to > >>> (A1, A2) then there will be one element in the top level > >>> collection, > >>> with the > >>> network details and the 'status' field representing the state > >>> (which > >>> is same > >>> for all networks in the cluster contexts of the cluster). > >>> If, however, the status is not the same (ie. on A1 the network is > >>> 'Operational' and on A2 it is 'Non Operational') then the > >>> top-level > >>> collection will show two elements for the network, where all > >>> network > >>> details are the same and only the 'status' field is different. > >>> > >> > >> That sounds like a bug to me. > >> I think that top collection should include only DC level > >> properties and > >> not cluster level properties, status should not be there (same as > >> display required etc.) > >> > >> > >>> This is problematic IMHO for several reasons: > >>> 1. Showing one network in certain states, and multiple copies > >>> of this > >>> network in other states is not optimal, to say the least. > >>> 2. In the top-level collection there is no indicator of the > >>> cluster > >>> for which > >>> the network is displayed, so there is no way to > >>> differentiate > >>> between the > >>> two 'red' network elements (they will have same id, name, > >>> etc.). > >>> 3. There is a certain asymmetry between the remove action[2] > >>> and the > >>> result in that you would expect: you either remove a > >>> network but > >>> in the > >>> result you would see several elements removed. > >>> > >>> > >>> -- Proposed Solutions -- > >>> Personally I can think of several solutions to this problem: > >>> 1. Declare the top-level collection as a collection of all > >>> networks > >>> that are > >>> either attached to cluster or not, and if they are indeed > >>> attached > >>> then > >>> show the details for each cluster, including a link to the > >>> cluster. > >>> 2. Declare the top-level collection as a collection of all > >>> networks > >>> that are > >>> defined in data-centers, but they will not contain any > >>> cluster > >>> specific > >>> data, and thus each entry is unique. > >>> > >>> Solution #2 is breaking the API backwards-compatibility, since it > >>> includes > >>> removing certain fields that have appeared today (namely 'status' > >>> and > >>> 'display') but IMO would give a better experience since the > >>> top-level > >>> collection is actually used for managing networks, and not their > >>> attachment > >>> to clusters which should be done in the context of each cluster. > >>> > >> I really don't think top collections should include cluster > >> networks it > >> is not user-friendly to say the least. > > > > how is that different from top collections including VMs and > > templates? > > (or logical networks becoming main tab in the UI going forward) > > > > I think you missed the point of cluster network entity vs. DC network > entity. > > we should have in the top collection a DC network, I think we should > not > display the network per cluster in top network collection (that can > be > viewed under the cluster context). Actually the API has the same concept as you suggest for storage domains. At the top level you don't have a status field, but under data center level, where it's valid then you get the status property. Same should go for networks. The status property should be added only where it's valid, in this case the cluster level sub-collection > > > >> > >> I vote for the second option, I don't think that having a bug in > >> previous versions should drive this decision. > >> > >> > >>> I would like to hear what suggestions you have to solve this > >>> problem > >>> or if > >>> you prefer either of the above solutions. > >>> > >>> > >>> -- Footnotes -- > >>> [1] In 3.1 this is slightly different, but for the sake of > >>> simplicity I > >>> didn't > >>> specify the new behaviour. > >>> [2] Currently you can't update the network if it's attached to > >>> any > >>> cluster, > >>> but perhaps in the future this would be possible. > >>> > >>> 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 > From iheim at redhat.com Wed Jul 4 16:38:46 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 04 Jul 2012 19:38:46 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <75d4bf72-d269-4ada-bbbc-958dca45073a@zmail17.collab.prod.int.phx2.redhat.com> References: <75d4bf72-d269-4ada-bbbc-958dca45073a@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FF47196.9090909@redhat.com> On 07/04/2012 07:27 PM, Simon Grinberg wrote: > > > ----- Original Message ----- >> From: "Livnat Peer" >> To: "Itamar Heim" >> Cc: "engine-devel" >> Sent: Tuesday, July 3, 2012 10:06:37 PM >> Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks >> >> On 03/07/12 21:28, Itamar Heim wrote: >>> On 07/03/2012 10:30 AM, Livnat Peer wrote: >>>> On 02/07/12 17:35, Mike Kolesnik wrote: >>>>> Hi All, >>>>> >>>>> I would like to hear opinions about a behaviour that I think is >>>>> problematic in >>>>> REST API handling of logical networks. >>>>> >>>>> -- Intro -- >>>>> Today in the REST API we are exposing two collections for >>>>> "logical >>>>> network" related entities. >>>>> >>>>> First is a top level collection which is out of any context at >>>>> the >>>>> address >>>>> http://engine/api/networks. >>>>> Second is a sub-collection in the context of a cluster: >>>>> http://engine/api/cluster/xxx/networks >>>>> >>>>> The network itself is defined per DC level, so for each DC you >>>>> would >>>>> have >>>>> at least one logical network for management, which has some >>>>> properties such >>>>> as STP, MTU, etc.. >>>>> The top level collection is used to create/delete such network >>>>> entities. >>>>> >>>>> The sub-collection in the context of a Cluster is used to >>>>> attach/detach a >>>>> network from the DC of that cluster. >>>>> The network in the context of a cluster has some additional >>>>> information, >>>>> let's >>>>> say for example 'status' of the network: >>>>> If a network is defined on all hosts in the cluster then >>>>> it's >>>>> status is >>>>> 'Operational'. >>>>> If a network is not defined on some of the hosts in the >>>>> cluster >>>>> then >>>>> it's >>>>> status is 'Not Operational'[1]. >>>>> >>>>> >>>>> -- Problem -- >>>>> The problem is that details which are only relevant in context of >>>>> a >>>>> cluster, are still displayed in the root context as well (e.g: >>>>> 'status'). >>>>> This can, in certain cases, cause unexpected behaviour. >>>>> >>>>> For example, let's consider this topology: >>>>> Data Center A >>>>> | >>>>> |\____ Network 'red' >>>>> |\____ Cluster A1 >>>>> | \______ Network 'red' attached >>>>> \____ Cluster A2 >>>>> \______ Network 'red' attached >>>>> >>>>> If the 'status' is the same on all the clusters that the network >>>>> is >>>>> attached to >>>>> (A1, A2) then there will be one element in the top level >>>>> collection, >>>>> with the >>>>> network details and the 'status' field representing the state >>>>> (which >>>>> is same >>>>> for all networks in the cluster contexts of the cluster). >>>>> If, however, the status is not the same (ie. on A1 the network is >>>>> 'Operational' and on A2 it is 'Non Operational') then the >>>>> top-level >>>>> collection will show two elements for the network, where all >>>>> network >>>>> details are the same and only the 'status' field is different. >>>>> >>>> >>>> That sounds like a bug to me. >>>> I think that top collection should include only DC level >>>> properties and >>>> not cluster level properties, status should not be there (same as >>>> display required etc.) >>>> >>>> >>>>> This is problematic IMHO for several reasons: >>>>> 1. Showing one network in certain states, and multiple copies >>>>> of this >>>>> network in other states is not optimal, to say the least. >>>>> 2. In the top-level collection there is no indicator of the >>>>> cluster >>>>> for which >>>>> the network is displayed, so there is no way to >>>>> differentiate >>>>> between the >>>>> two 'red' network elements (they will have same id, name, >>>>> etc.). >>>>> 3. There is a certain asymmetry between the remove action[2] >>>>> and the >>>>> result in that you would expect: you either remove a >>>>> network but >>>>> in the >>>>> result you would see several elements removed. >>>>> >>>>> >>>>> -- Proposed Solutions -- >>>>> Personally I can think of several solutions to this problem: >>>>> 1. Declare the top-level collection as a collection of all >>>>> networks >>>>> that are >>>>> either attached to cluster or not, and if they are indeed >>>>> attached >>>>> then >>>>> show the details for each cluster, including a link to the >>>>> cluster. >>>>> 2. Declare the top-level collection as a collection of all >>>>> networks >>>>> that are >>>>> defined in data-centers, but they will not contain any >>>>> cluster >>>>> specific >>>>> data, and thus each entry is unique. >>>>> >>>>> Solution #2 is breaking the API backwards-compatibility, since it >>>>> includes >>>>> removing certain fields that have appeared today (namely 'status' >>>>> and >>>>> 'display') but IMO would give a better experience since the >>>>> top-level >>>>> collection is actually used for managing networks, and not their >>>>> attachment >>>>> to clusters which should be done in the context of each cluster. >>>>> >>>> I really don't think top collections should include cluster >>>> networks it >>>> is not user-friendly to say the least. >>> >>> how is that different from top collections including VMs and >>> templates? >>> (or logical networks becoming main tab in the UI going forward) >>> >> >> I think you missed the point of cluster network entity vs. DC network >> entity. >> >> we should have in the top collection a DC network, I think we should >> not >> display the network per cluster in top network collection (that can >> be >> viewed under the cluster context). > > Actually the API has the same concept as you suggest for storage domains. > At the top level you don't have a status field, but under data center level, where it's valid then you get the status property. > > Same should go for networks. > The status property should be added only where it's valid, in this case the cluster level sub-collection so sounds like we want to declare these properties deprecated to be able to remove them in a future version? From simon at redhat.com Wed Jul 4 16:49:42 2012 From: simon at redhat.com (Simon Grinberg) Date: Wed, 04 Jul 2012 12:49:42 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF47196.9090909@redhat.com> Message-ID: ----- Original Message ----- > From: "Itamar Heim" > To: "Simon Grinberg" > Cc: "engine-devel" > Sent: Wednesday, July 4, 2012 7:38:46 PM > Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks > > On 07/04/2012 07:27 PM, Simon Grinberg wrote: > > > > > > ----- Original Message ----- > >> From: "Livnat Peer" > >> To: "Itamar Heim" > >> Cc: "engine-devel" > >> Sent: Tuesday, July 3, 2012 10:06:37 PM > >> Subject: Re: [Engine-devel] Fwd: Problem in REST API > >> handling/displaying of logical networks > >> > >> On 03/07/12 21:28, Itamar Heim wrote: > >>> On 07/03/2012 10:30 AM, Livnat Peer wrote: > >>>> On 02/07/12 17:35, Mike Kolesnik wrote: > >>>>> Hi All, > >>>>> > >>>>> I would like to hear opinions about a behaviour that I think is > >>>>> problematic in > >>>>> REST API handling of logical networks. > >>>>> > >>>>> -- Intro -- > >>>>> Today in the REST API we are exposing two collections for > >>>>> "logical > >>>>> network" related entities. > >>>>> > >>>>> First is a top level collection which is out of any context at > >>>>> the > >>>>> address > >>>>> http://engine/api/networks. > >>>>> Second is a sub-collection in the context of a cluster: > >>>>> http://engine/api/cluster/xxx/networks > >>>>> > >>>>> The network itself is defined per DC level, so for each DC you > >>>>> would > >>>>> have > >>>>> at least one logical network for management, which has some > >>>>> properties such > >>>>> as STP, MTU, etc.. > >>>>> The top level collection is used to create/delete such network > >>>>> entities. > >>>>> > >>>>> The sub-collection in the context of a Cluster is used to > >>>>> attach/detach a > >>>>> network from the DC of that cluster. > >>>>> The network in the context of a cluster has some additional > >>>>> information, > >>>>> let's > >>>>> say for example 'status' of the network: > >>>>> If a network is defined on all hosts in the cluster then > >>>>> it's > >>>>> status is > >>>>> 'Operational'. > >>>>> If a network is not defined on some of the hosts in the > >>>>> cluster > >>>>> then > >>>>> it's > >>>>> status is 'Not Operational'[1]. > >>>>> > >>>>> > >>>>> -- Problem -- > >>>>> The problem is that details which are only relevant in context > >>>>> of > >>>>> a > >>>>> cluster, are still displayed in the root context as well (e.g: > >>>>> 'status'). > >>>>> This can, in certain cases, cause unexpected behaviour. > >>>>> > >>>>> For example, let's consider this topology: > >>>>> Data Center A > >>>>> | > >>>>> |\____ Network 'red' > >>>>> |\____ Cluster A1 > >>>>> | \______ Network 'red' attached > >>>>> \____ Cluster A2 > >>>>> \______ Network 'red' attached > >>>>> > >>>>> If the 'status' is the same on all the clusters that the > >>>>> network > >>>>> is > >>>>> attached to > >>>>> (A1, A2) then there will be one element in the top level > >>>>> collection, > >>>>> with the > >>>>> network details and the 'status' field representing the state > >>>>> (which > >>>>> is same > >>>>> for all networks in the cluster contexts of the cluster). > >>>>> If, however, the status is not the same (ie. on A1 the network > >>>>> is > >>>>> 'Operational' and on A2 it is 'Non Operational') then the > >>>>> top-level > >>>>> collection will show two elements for the network, where all > >>>>> network > >>>>> details are the same and only the 'status' field is different. > >>>>> > >>>> > >>>> That sounds like a bug to me. > >>>> I think that top collection should include only DC level > >>>> properties and > >>>> not cluster level properties, status should not be there (same > >>>> as > >>>> display required etc.) > >>>> > >>>> > >>>>> This is problematic IMHO for several reasons: > >>>>> 1. Showing one network in certain states, and multiple > >>>>> copies > >>>>> of this > >>>>> network in other states is not optimal, to say the > >>>>> least. > >>>>> 2. In the top-level collection there is no indicator of the > >>>>> cluster > >>>>> for which > >>>>> the network is displayed, so there is no way to > >>>>> differentiate > >>>>> between the > >>>>> two 'red' network elements (they will have same id, > >>>>> name, > >>>>> etc.). > >>>>> 3. There is a certain asymmetry between the remove > >>>>> action[2] > >>>>> and the > >>>>> result in that you would expect: you either remove a > >>>>> network but > >>>>> in the > >>>>> result you would see several elements removed. > >>>>> > >>>>> > >>>>> -- Proposed Solutions -- > >>>>> Personally I can think of several solutions to this problem: > >>>>> 1. Declare the top-level collection as a collection of all > >>>>> networks > >>>>> that are > >>>>> either attached to cluster or not, and if they are > >>>>> indeed > >>>>> attached > >>>>> then > >>>>> show the details for each cluster, including a link to > >>>>> the > >>>>> cluster. > >>>>> 2. Declare the top-level collection as a collection of all > >>>>> networks > >>>>> that are > >>>>> defined in data-centers, but they will not contain any > >>>>> cluster > >>>>> specific > >>>>> data, and thus each entry is unique. > >>>>> > >>>>> Solution #2 is breaking the API backwards-compatibility, since > >>>>> it > >>>>> includes > >>>>> removing certain fields that have appeared today (namely > >>>>> 'status' > >>>>> and > >>>>> 'display') but IMO would give a better experience since the > >>>>> top-level > >>>>> collection is actually used for managing networks, and not > >>>>> their > >>>>> attachment > >>>>> to clusters which should be done in the context of each > >>>>> cluster. > >>>>> > >>>> I really don't think top collections should include cluster > >>>> networks it > >>>> is not user-friendly to say the least. > >>> > >>> how is that different from top collections including VMs and > >>> templates? > >>> (or logical networks becoming main tab in the UI going forward) > >>> > >> > >> I think you missed the point of cluster network entity vs. DC > >> network > >> entity. > >> > >> we should have in the top collection a DC network, I think we > >> should > >> not > >> display the network per cluster in top network collection (that > >> can > >> be > >> viewed under the cluster context). > > > > Actually the API has the same concept as you suggest for storage > > domains. > > At the top level you don't have a status field, but under data > > center level, where it's valid then you get the status property. > > > > Same should go for networks. > > The status property should be added only where it's valid, in this > > case the cluster level sub-collection > > so sounds like we want to declare these properties deprecated to be > able > to remove them in a future version? I guess so, The question is, are there other location where the status property (or any other property) exists at an irrelevant level. Unless we want to go into the effort of mapping them all now we probably need to define a concept and anything not complying to that is a bug that is allowed to be fixed without considering it as breaking the API. Thoughts? > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From iheim at redhat.com Wed Jul 4 17:25:11 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 04 Jul 2012 20:25:11 +0300 Subject: [Engine-devel] oVirt UI Plugins feature: Ready for review In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A4801205F4B@SACEXCMBX04-PRD.hq.netapp.com> References: <6C8AC8C50E170C4E9B44D47B39B24A4801205546@SACEXCMBX04-PRD.hq.netapp.com> <6C8AC8C50E170C4E9B44D47B39B24A4801205F4B@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: <4FF47C77.1090608@redhat.com> On 06/25/2012 10:11 PM, Costea, George wrote: > Thanks Vojtech. > > Since the plugins are embedded into the WebAdmin HTML page, that seems to simplify things; no external web service is needed. This approach ties into the issue over the freedom to decide which technology to use when developing a plugin. While I agree that jQuery is best for simple dialogs, a wizard-driven workflow is easier to develop in GWT. > > For example, if I want to step a user through the process of creating a new storage domain I would like to provide a workflow to select a storage array, provide credentials, and configure the details of the NFS export. This workflow could presumably have a GWT-RPC mechanism that relies on some additional libraries on the backend (libraries that allow me to communicate with the storage array). Using the GWT-Exporter, I could export the classes that would display the workflow which would then get launched as my extension is selected. You said that I would have my oVirt UI plugin depend on my compiled 'plugin support application'. My compiled plugin support application would normally be a war file containing my compiled GWT code and a web-inf folder containing my libraries. Is the plugin depending on the war file? Is that what I specify? > > -George > > -----Original Message----- > From: Vojtech Szocs [mailto:vszocs at redhat.com] > Sent: Monday, June 25, 2012 1:12 PM > To: Costea, George; engine-devel at ovirt.org > Cc: Schoenbrun, Dustin; Hopper, Ricky; Itamar Heim > Subject: Re: oVirt UI Plugins feature: Ready for review > > Hi George, > > thanks for your feedback. Please find my answers below. > > >> 1) Are the plugins hosted by the same jboss server that hosts the engine? It would appear the answer is yes and that no separate container is required for the plugins. > > In short, yes. > > Plugins, along with their configuration and 3rd party dependencies, are meant to be embedded into final WebAdmin HTML page, see [http://www.ovirt.org/wiki/Features/UIPlugins#Plugin_lifecycle] step #5. > JBoss AS instance serves WebAdmin HTML page (WebadminDynamicHostingServlet), along with providing GWT RPC and REST endpoints that delegate to Engine business logic through EJB BackendLocal interface. > > However, plugins are not 'hosted' in a typical sense - WebadminDynamicHostingServlet reads and embeds all plugin data directly into final WebAdmin HTML page. > > >> 2) Does each plugin map to a unique extension within WebAdmin? Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension. This is named pluginApi.plugins.myPlugin. Can I safely assume that this is per extension? I would have pluginApi.plugins.myPlugin2 for extending a storage domain? > > Extension points are represented by application events, triggered by WebAdmin and consumed by plugins. For example, 'tableContextMenu' event gets triggered when a table context menu is about to be shown to the user, which gives plugins the ability to do something custom with the context menu before it's shown. > > There can be multiple plugins handling the same event (extension point). You can have two plugins, say 'pluginApi.plugins.One' and 'pluginApi.plugins.Two', each providing 'tableContextMenu' function for handling the above mentioned event. WebAdmin will invoke all plugins for the given event. > > To answer your question, in order to handle X events (extension points), you don't need to write X plugins. You can write one plugin that handles X events. > > >> 3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs? > > You can do anything you want in your plugin event handler function. Show a jQuery UI dialog, make oVirt REST API request, call arbitrary remote server using cross-domain technique like JSONP [1] or CORS [2], etc. Plugin authors are free to decide if they want to rely on 3rd party JavaScript libraries, or if they want to write entire plugin code by themselves. > > In my opinion, tools like jQuery are far more elegant for handling simple things such as UI dialogs. But if you really want to use GWT for this purpose, I suggest following approach: > > a, develop a 'plugin support application' in GWT, which implements the necessary dialog functionality b, export its main (e.g. dialog handling) classes for use in native JavaScript through gwt-exporter [3] c, have your oVirt UI plugin depend on your compiled 'plugin support application' (this will cause your 'plugin support application' to be called during WebAdmin startup) d, in your oVirt UI plugin, invoke 'plugin support application' functionality through exported classes (plugin -> GWT delegate pattern) > > >> 4) Is session info passed into the plugin so that I can invoke APIs into the engine? To power on a VM for instance? Or to mount a new NFS storage domain? > > Yes, this should be part of [http://www.ovirt.org/wiki/Features/UIPlugins#Global_API_functions] "Plugin utility functions" (global API). > > Your plugin might access user session information in the following way: pluginApi.util().userInfo().* (replace * with id(), name(), domain(), etc.) > > As you pointed out, this could be used to authenticate oVirt REST API requests made from your plugin code. > > >> BTW, the link to the original design notes on the wiki doesn't work. > > This is strange, [http://rhevmf.pad.engineering.redhat.com/68] has its visibility set to "Public (Allow Internet guests)" ... Does anybody know why this doesn't work? > > > Vojtech > > > [1] http://en.wikipedia.org/wiki/JSONP > [2] http://en.wikipedia.org/wiki/Cross-origin_resource_sharing > [3] http://code.google.com/p/gwt-exporter/ > > > ----- Original Message ----- > From: "George Costea" > To: "Vojtech Szocs" , engine-devel at ovirt.org > Cc: "Dustin Schoenbrun" , "Ricky Hopper" > Sent: Monday, June 25, 2012 3:09:43 PM > Subject: RE: oVirt UI Plugins feature: Ready for review > > Hi Vojtech, > > I have a few questions on this feature. > > 1) Are the plugins hosted by the same jboss server that hosts the engine? It would appear the answer is yes and that no separate container is required for the plugins. > 2) Does each plugin map to a unique extension within WebAdmin? Your example shows that I can extend the VM table to have a "Show VM name and edit VM" context-sensitive extension. This is named pluginApi.plugins.myPlugin. Can I safely assume that this is per extension? I would have pluginApi.plugins.myPlugin2 for extending a storage domain? > 3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to display a dialog that fits my needs? > 4) Is session info passed into the plugin so that I can invoke APIs into the engine? To power on a VM for instance? Or to mount a new NFS storage domain? > > BTW, the link to the original design notes on the wiki doesn't work. > > Thanks, > George > > -----Original Message----- > From: Vojtech Szocs [mailto:vszocs at redhat.com] > Sent: Thursday, June 21, 2012 11:03 AM > To: engine-devel at ovirt.org > Cc: Schoenbrun, Dustin; Costea, George; Hopper, Ricky > Subject: oVirt UI Plugins feature: Ready for review > > Hi guys, > > I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration (WebAdmin) application: > http://www.ovirt.org/wiki/Features/UIPlugins > > Feature design is finished and ready for review. Please feel free to add comments, ask questions or reach me directly on #ovirt channel. > > Cheers, > Vojtech > reviewed the wiki, some notes: 1. nit: plugin is in {} - should only be function call there so not all of plugin needs such a deep indentation. 2. what are deps? 3. sorting/ordering of plugins. either part of their conf, or part of their name (nn-pluginname...) which is a normal linux convention 4. Proposed configuration file location: /etc/ovirt/webadmin add /extensions 5. events - should have before and after event calls 6. missing in api - api to perform a rest call (say using json) 7. future: provide a javascript sdk like the python one, rather than just a rest api level integration - not sure worth the hassle 8. reminder - extensions need can't use internal API, only the REST API. this goes to *entities* as well - either you expose a REST-like entity for the important fields, or we start moving parts of the UI to the REST entities to match (I'm not sure you want to go with latter yet, as it is a huge undertaking, but you need to expose matching entities to begin with, or extensions will break on upgrade since internal entities aren't backward compatible. to sum it up: ui plugins must get an SDK of what they can do, which will include entry points, entities and relevant methods. UI code should be as simple as possible to write for the main use cases (i.e., i think the SDK should provide very simple objets for adding subtabs, context menu items, etc.) - right now it is very java script oriented. From lpeer at redhat.com Thu Jul 5 05:58:20 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 05 Jul 2012 08:58:20 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: References: Message-ID: <4FF52CFC.3010708@redhat.com> On 04/07/12 19:49, Simon Grinberg wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Simon Grinberg" >> Cc: "engine-devel" >> Sent: Wednesday, July 4, 2012 7:38:46 PM >> Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks >> >> On 07/04/2012 07:27 PM, Simon Grinberg wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Livnat Peer" >>>> To: "Itamar Heim" >>>> Cc: "engine-devel" >>>> Sent: Tuesday, July 3, 2012 10:06:37 PM >>>> Subject: Re: [Engine-devel] Fwd: Problem in REST API >>>> handling/displaying of logical networks >>>> >>>> On 03/07/12 21:28, Itamar Heim wrote: >>>>> On 07/03/2012 10:30 AM, Livnat Peer wrote: >>>>>> On 02/07/12 17:35, Mike Kolesnik wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> I would like to hear opinions about a behaviour that I think is >>>>>>> problematic in >>>>>>> REST API handling of logical networks. >>>>>>> >>>>>>> -- Intro -- >>>>>>> Today in the REST API we are exposing two collections for >>>>>>> "logical >>>>>>> network" related entities. >>>>>>> >>>>>>> First is a top level collection which is out of any context at >>>>>>> the >>>>>>> address >>>>>>> http://engine/api/networks. >>>>>>> Second is a sub-collection in the context of a cluster: >>>>>>> http://engine/api/cluster/xxx/networks >>>>>>> >>>>>>> The network itself is defined per DC level, so for each DC you >>>>>>> would >>>>>>> have >>>>>>> at least one logical network for management, which has some >>>>>>> properties such >>>>>>> as STP, MTU, etc.. >>>>>>> The top level collection is used to create/delete such network >>>>>>> entities. >>>>>>> >>>>>>> The sub-collection in the context of a Cluster is used to >>>>>>> attach/detach a >>>>>>> network from the DC of that cluster. >>>>>>> The network in the context of a cluster has some additional >>>>>>> information, >>>>>>> let's >>>>>>> say for example 'status' of the network: >>>>>>> If a network is defined on all hosts in the cluster then >>>>>>> it's >>>>>>> status is >>>>>>> 'Operational'. >>>>>>> If a network is not defined on some of the hosts in the >>>>>>> cluster >>>>>>> then >>>>>>> it's >>>>>>> status is 'Not Operational'[1]. >>>>>>> >>>>>>> >>>>>>> -- Problem -- >>>>>>> The problem is that details which are only relevant in context >>>>>>> of >>>>>>> a >>>>>>> cluster, are still displayed in the root context as well (e.g: >>>>>>> 'status'). >>>>>>> This can, in certain cases, cause unexpected behaviour. >>>>>>> >>>>>>> For example, let's consider this topology: >>>>>>> Data Center A >>>>>>> | >>>>>>> |\____ Network 'red' >>>>>>> |\____ Cluster A1 >>>>>>> | \______ Network 'red' attached >>>>>>> \____ Cluster A2 >>>>>>> \______ Network 'red' attached >>>>>>> >>>>>>> If the 'status' is the same on all the clusters that the >>>>>>> network >>>>>>> is >>>>>>> attached to >>>>>>> (A1, A2) then there will be one element in the top level >>>>>>> collection, >>>>>>> with the >>>>>>> network details and the 'status' field representing the state >>>>>>> (which >>>>>>> is same >>>>>>> for all networks in the cluster contexts of the cluster). >>>>>>> If, however, the status is not the same (ie. on A1 the network >>>>>>> is >>>>>>> 'Operational' and on A2 it is 'Non Operational') then the >>>>>>> top-level >>>>>>> collection will show two elements for the network, where all >>>>>>> network >>>>>>> details are the same and only the 'status' field is different. >>>>>>> >>>>>> >>>>>> That sounds like a bug to me. >>>>>> I think that top collection should include only DC level >>>>>> properties and >>>>>> not cluster level properties, status should not be there (same >>>>>> as >>>>>> display required etc.) >>>>>> >>>>>> >>>>>>> This is problematic IMHO for several reasons: >>>>>>> 1. Showing one network in certain states, and multiple >>>>>>> copies >>>>>>> of this >>>>>>> network in other states is not optimal, to say the >>>>>>> least. >>>>>>> 2. In the top-level collection there is no indicator of the >>>>>>> cluster >>>>>>> for which >>>>>>> the network is displayed, so there is no way to >>>>>>> differentiate >>>>>>> between the >>>>>>> two 'red' network elements (they will have same id, >>>>>>> name, >>>>>>> etc.). >>>>>>> 3. There is a certain asymmetry between the remove >>>>>>> action[2] >>>>>>> and the >>>>>>> result in that you would expect: you either remove a >>>>>>> network but >>>>>>> in the >>>>>>> result you would see several elements removed. >>>>>>> >>>>>>> >>>>>>> -- Proposed Solutions -- >>>>>>> Personally I can think of several solutions to this problem: >>>>>>> 1. Declare the top-level collection as a collection of all >>>>>>> networks >>>>>>> that are >>>>>>> either attached to cluster or not, and if they are >>>>>>> indeed >>>>>>> attached >>>>>>> then >>>>>>> show the details for each cluster, including a link to >>>>>>> the >>>>>>> cluster. >>>>>>> 2. Declare the top-level collection as a collection of all >>>>>>> networks >>>>>>> that are >>>>>>> defined in data-centers, but they will not contain any >>>>>>> cluster >>>>>>> specific >>>>>>> data, and thus each entry is unique. >>>>>>> >>>>>>> Solution #2 is breaking the API backwards-compatibility, since >>>>>>> it >>>>>>> includes >>>>>>> removing certain fields that have appeared today (namely >>>>>>> 'status' >>>>>>> and >>>>>>> 'display') but IMO would give a better experience since the >>>>>>> top-level >>>>>>> collection is actually used for managing networks, and not >>>>>>> their >>>>>>> attachment >>>>>>> to clusters which should be done in the context of each >>>>>>> cluster. >>>>>>> >>>>>> I really don't think top collections should include cluster >>>>>> networks it >>>>>> is not user-friendly to say the least. >>>>> >>>>> how is that different from top collections including VMs and >>>>> templates? >>>>> (or logical networks becoming main tab in the UI going forward) >>>>> >>>> >>>> I think you missed the point of cluster network entity vs. DC >>>> network >>>> entity. >>>> >>>> we should have in the top collection a DC network, I think we >>>> should >>>> not >>>> display the network per cluster in top network collection (that >>>> can >>>> be >>>> viewed under the cluster context). >>> >>> Actually the API has the same concept as you suggest for storage >>> domains. >>> At the top level you don't have a status field, but under data >>> center level, where it's valid then you get the status property. >>> >>> Same should go for networks. >>> The status property should be added only where it's valid, in this >>> case the cluster level sub-collection >> >> so sounds like we want to declare these properties deprecated to be >> able >> to remove them in a future version? > > I guess so, > The question is, are there other location where the status property (or any other property) exists at an irrelevant level. Unless we want to go into the effort of mapping them all now we probably need to define a concept and anything not complying to that is a bug that is allowed to be fixed without considering it as breaking the API. > > Thoughts? > I agree with Simon, we should consider this as a bug and not go through a deprecation process. Example - we have 3 clusters with a 'red; network attached and for one of the clusters the network is non-operational. On the top collection we'll have two instances of the network one with status operational and the other with non-operational.... A user can't use the above information and if he did it is most likely wrong / a bug. Specifically for networks we reviewed the rest API and the problem is there only for the top level collection (for property 'status' and other properties that were only added in 3.1 so we can remove them safely). Livnat > > > >> _______________________________________________ >> 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 oliel at redhat.com Thu Jul 5 06:18:06 2012 From: oliel at redhat.com (Ori Liel) Date: Thu, 05 Jul 2012 02:18:06 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF52CFC.3010708@redhat.com> Message-ID: <453ec547-19ee-4023-93cd-f345a133c9a6@zmail17.collab.prod.int.phx2.redhat.com> > > >----- Original Message ----- >From: "Livnat Peer" >To: "Simon Grinberg" >Cc: "engine-devel" >Sent: Thursday, July 5, 2012 8:58:20 AM >Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks > >On 04/07/12 19:49, Simon Grinberg wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Simon Grinberg" >>> Cc: "engine-devel" >>> Sent: Wednesday, July 4, 2012 7:38:46 PM >>> Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks >>> >>> On 07/04/2012 07:27 PM, Simon Grinberg wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Livnat Peer" >>>>> To: "Itamar Heim" >>>>> Cc: "engine-devel" >>>>> Sent: Tuesday, July 3, 2012 10:06:37 PM >>>>> Subject: Re: [Engine-devel] Fwd: Problem in REST API >>>>> handling/displaying of logical networks >>>>> >>>>> On 03/07/12 21:28, Itamar Heim wrote: >>>>>> On 07/03/2012 10:30 AM, Livnat Peer wrote: >>>>>>> On 02/07/12 17:35, Mike Kolesnik wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I would like to hear opinions about a behaviour that I think is >>>>>>>> problematic in >>>>>>>> REST API handling of logical networks. >>>>>>>> >>>>>>>> -- Intro -- >>>>>>>> Today in the REST API we are exposing two collections for >>>>>>>> "logical >>>>>>>> network" related entities. >>>>>>>> >>>>>>>> First is a top level collection which is out of any context at >>>>>>>> the >>>>>>>> address >>>>>>>> http://engine/api/networks. >>>>>>>> Second is a sub-collection in the context of a cluster: >>>>>>>> http://engine/api/cluster/xxx/networks >>>>>>>> >>>>>>>> The network itself is defined per DC level, so for each DC you >>>>>>>> would >>>>>>>> have >>>>>>>> at least one logical network for management, which has some >>>>>>>> properties such >>>>>>>> as STP, MTU, etc.. >>>>>>>> The top level collection is used to create/delete such network >>>>>>>> entities. >>>>>>>> >>>>>>>> The sub-collection in the context of a Cluster is used to >>>>>>>> attach/detach a >>>>>>>> network from the DC of that cluster. >>>>>>>> The network in the context of a cluster has some additional >>>>>>>> information, >>>>>>>> let's >>>>>>>> say for example 'status' of the network: >>>>>>>> If a network is defined on all hosts in the cluster then >>>>>>>> it's >>>>>>>> status is >>>>>>>> 'Operational'. >>>>>>>> If a network is not defined on some of the hosts in the >>>>>>>> cluster >>>>>>>> then >>>>>>>> it's >>>>>>>> status is 'Not Operational'[1]. >>>>>>>> >>>>>>>> >>>>>>>> -- Problem -- >>>>>>>> The problem is that details which are only relevant in context >>>>>>>> of >>>>>>>> a >>>>>>>> cluster, are still displayed in the root context as well (e.g: >>>>>>>> 'status'). >>>>>>>> This can, in certain cases, cause unexpected behaviour. >>>>>>>> >>>>>>>> For example, let's consider this topology: >>>>>>>> Data Center A >>>>>>>> | >>>>>>>> |\____ Network 'red' >>>>>>>> |\____ Cluster A1 >>>>>>>> | \______ Network 'red' attached >>>>>>>> \____ Cluster A2 >>>>>>>> \______ Network 'red' attached >>>>>>>> >>>>>>>> If the 'status' is the same on all the clusters that the >>>>>>>> network >>>>>>>> is >>>>>>>> attached to >>>>>>>> (A1, A2) then there will be one element in the top level >>>>>>>> collection, >>>>>>>> with the >>>>>>>> network details and the 'status' field representing the state >>>>>>>> (which >>>>>>>> is same >>>>>>>> for all networks in the cluster contexts of the cluster). >>>>>>>> If, however, the status is not the same (ie. on A1 the network >>>>>>>> is >>>>>>>> 'Operational' and on A2 it is 'Non Operational') then the >>>>>>>> top-level >>>>>>>> collection will show two elements for the network, where all >>>>>>>> network >>>>>>>> details are the same and only the 'status' field is different. >>>>>>>> >>>>>>> >>>>>>> That sounds like a bug to me. >>>>>>> I think that top collection should include only DC level >>>>>>> properties and >>>>>>> not cluster level properties, status should not be there (same >>>>>>> as >>>>>>> display required etc.) >>>>>>> >>>>>>> >>>>>>>> This is problematic IMHO for several reasons: >>>>>>>> 1. Showing one network in certain states, and multiple >>>>>>>> copies >>>>>>>> of this >>>>>>>> network in other states is not optimal, to say the >>>>>>>> least. >>>>>>>> 2. In the top-level collection there is no indicator of the >>>>>>>> cluster >>>>>>>> for which >>>>>>>> the network is displayed, so there is no way to >>>>>>>> differentiate >>>>>>>> between the >>>>>>>> two 'red' network elements (they will have same id, >>>>>>>> name, >>>>>>>> etc.). >>>>>>>> 3. There is a certain asymmetry between the remove >>>>>>>> action[2] >>>>>>>> and the >>>>>>>> result in that you would expect: you either remove a >>>>>>>> network but >>>>>>>> in the >>>>>>>> result you would see several elements removed. >>>>>>>> >>>>>>>> >>>>>>>> -- Proposed Solutions -- >>>>>>>> Personally I can think of several solutions to this problem: >>>>>>>> 1. Declare the top-level collection as a collection of all >>>>>>>> networks >>>>>>>> that are >>>>>>>> either attached to cluster or not, and if they are >>>>>>>> indeed >>>>>>>> attached >>>>>>>> then >>>>>>>> show the details for each cluster, including a link to >>>>>>>> the >>>>>>>> cluster. >>>>>>>> 2. Declare the top-level collection as a collection of all >>>>>>>> networks >>>>>>>> that are >>>>>>>> defined in data-centers, but they will not contain any >>>>>>>> cluster >>>>>>>> specific >>>>>>>> data, and thus each entry is unique. >>>>>>>> >>>>>>>> Solution #2 is breaking the API backwards-compatibility, since >>>>>>>> it >>>>>>>> includes >>>>>>>> removing certain fields that have appeared today (namely >>>>>>>> 'status' >>>>>>>> and >>>>>>>> 'display') but IMO would give a better experience since the >>>>>>>> top-level >>>>>>>> collection is actually used for managing networks, and not >>>>>>>> their >>>>>>>> attachment >>>>>>>> to clusters which should be done in the context of each >>>>>>>> cluster. >>>>>>>> >>>>>>> I really don't think top collections should include cluster >>>>>>> networks it >>>>>>> is not user-friendly to say the least. >>>>>> >>>>>> how is that different from top collections including VMs and >>>>>> templates? >>>>>> (or logical networks becoming main tab in the UI going forward) >>>>>> >>>>> >>>>> I think you missed the point of cluster network entity vs. DC >>>>> network >>>>> entity. >>>>> >>>>> we should have in the top collection a DC network, I think we >>>>> should >>>>> not >>>>> display the network per cluster in top network collection (that >>>>> can >>>>> be >>>>> viewed under the cluster context). >>>> >>>> Actually the API has the same concept as you suggest for storage >>>> domains. >>>> At the top level you don't have a status field, but under data >>>> center level, where it's valid then you get the status property. >>>> >>>> Same should go for networks. >>>> The status property should be added only where it's valid, in this >>>> case the cluster level sub-collection >>> >>> so sounds like we want to declare these properties deprecated to be >>> able >>> to remove them in a future version? >> >> I guess so, >> The question is, are there other location where the status property (or any other property) exists at an irrelevant level. Unless we want to go into the effort of mapping them all now we probably need to define a concept and anything not complying to that is a bug that is allowed to be fixed without considering it as breaking the API. >> >> Thoughts? >> > > >I agree with Simon, we should consider this as a bug and not go through >a deprecation process. >Example - we have 3 clusters with a 'red; network attached and for one >of the clusters the network is non-operational. On the top collection >we'll have two instances of the network one with status operational and >the other with non-operational.... > >A user can't use the above information and if he did it is most likely >wrong / a bug. > +1 I also think it's broken enough to be seen as a bug; it's hard to imagine a useful script which uses 'status' field at root level. >Specifically for networks we reviewed the rest API and the problem is >there only for the top level collection (for property 'status' and other >properties that were only added in 3.1 so we can remove them safely). > >Livnat > > >> >> >> >>> _______________________________________________ >>> 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 michal.skrivanek at redhat.com Thu Jul 5 06:41:44 2012 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Thu, 5 Jul 2012 09:41:44 +0300 Subject: [Engine-devel] Separating engine-setup from ovirt-engine In-Reply-To: <20120704091147.GC15123@redhat.com> References: <20120703192312.GC22203@redhat.com> <20120704091147.GC15123@redhat.com> Message-ID: On Jul 4, 2012, at 12:11 , Dan Kenigsberg wrote: > On Wed, Jul 04, 2012 at 03:16:17AM -0400, Ofer Schreiber wrote: >> >> >> ----- Original Message ----- >>> On Tue, Jul 03, 2012 at 06:20:43PM +0300, Michal Skrivanek wrote: >>>> On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: >>>> >>>>> On 07/03/2012 03:43 PM, Ofer Schreiber wrote: >>>>>> In our days, ovirt-engine-setup is a part of the big >>>>>> ovirt-engine rpm. >>>>>> This means that each time you need to build yourself a new >>>>>> ovirt-engine-setup rpm, you need to compile all the engine I'd expect that when you need a proper rpm then you have to go through all the pain and build everything from scratch to make it perfect. If you want to test something and debug, etc, you'd not build a full blown rpm anyway, would you? Well, either way, if you'd have 15 minutes for me I'd appreciate you show me how it's being done today?. thanks, michal >>> Could this possibly be avoided by an optional flag to the build >>> script? >> >> It's problematic, as ovirt-engine-setup is a sub rpm of ovirt-engine. >> I have no idea how can we just build the setup without the engine, which is compiled in a temporary directory (and removed straight after the build) >> >>> >>>>>> >>>>>> I've started to think about separating it into another git >>>>>> (similar to ovirt-iso-uploader), so we will be able to build >>>>>> this rpm separately. >>>>>> >>>>>> This change is really easy to implement (actually, I have >>>>>> already done it locally), and sounds to me like it's the right >>>>>> thing to do. >>>>>> >>>>>> Thought? >>>>>> Ofer. >>>>> >>>>> I agree that is the right thing to do. Take into account that >>>>> this also >>>>> means that ovirt-engine-setup will no longer be a subpackage of >>>>> ovirt-engine, so you will have to submit a new package request to >>>>> have >>>>> it included in Fedora. >>>> not quite sure having 10+ packages is a win? >>>> - why do you have to have a separate git? >>>> - why do you have to recompile when there's a change elsewhere? >>>> isn't that a matter of compilation scripts only? (though >>>> understand size of the rpm might be an issue?) >>>> I personally do not see a point in separating of something >>>> inseparable?but that's just me perhaps:) >>>> >>>> in other words, if you would kindly explain me the benefits please, >>>> I'll shut up:-) >>> >>> indeed - having another package, with its own release cycle and >>> versioning scheme is quite costy. and isn't ovirt-engine-setup quite >>> tightly coupled with Engine's db scheme? (I really do not know, I >>> should >>> probably shut up, too). >> >> Quite costly? why? > > It is another package to release, that requires its own errata process > and inter-package dependencies. > > If you envisage a user that would like to use ovirt-engine-setup of one > version, with an ovirt-setup of another one, then go ahead. I simply do > not see the use case for this, only the complications. >> >> engine-setup is not tightly coupled with the db-scripts, we just execute the createDB script. >> >>> From mkenneth at redhat.com Thu Jul 5 07:24:58 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Thu, 05 Jul 2012 03:24:58 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: Message-ID: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Itamar Heim" > > To: "Simon Grinberg" > > Cc: "engine-devel" > > Sent: Wednesday, July 4, 2012 7:38:46 PM > > Subject: Re: [Engine-devel] Fwd: Problem in REST API > > handling/displaying of logical networks > > > > On 07/04/2012 07:27 PM, Simon Grinberg wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Livnat Peer" > > >> To: "Itamar Heim" > > >> Cc: "engine-devel" > > >> Sent: Tuesday, July 3, 2012 10:06:37 PM > > >> Subject: Re: [Engine-devel] Fwd: Problem in REST API > > >> handling/displaying of logical networks > > >> > > >> On 03/07/12 21:28, Itamar Heim wrote: > > >>> On 07/03/2012 10:30 AM, Livnat Peer wrote: > > >>>> On 02/07/12 17:35, Mike Kolesnik wrote: > > >>>>> Hi All, > > >>>>> > > >>>>> I would like to hear opinions about a behaviour that I think > > >>>>> is > > >>>>> problematic in > > >>>>> REST API handling of logical networks. > > >>>>> > > >>>>> -- Intro -- > > >>>>> Today in the REST API we are exposing two collections for > > >>>>> "logical > > >>>>> network" related entities. > > >>>>> > > >>>>> First is a top level collection which is out of any context > > >>>>> at > > >>>>> the > > >>>>> address > > >>>>> http://engine/api/networks. > > >>>>> Second is a sub-collection in the context of a cluster: > > >>>>> http://engine/api/cluster/xxx/networks > > >>>>> > > >>>>> The network itself is defined per DC level, so for each DC > > >>>>> you > > >>>>> would > > >>>>> have > > >>>>> at least one logical network for management, which has some > > >>>>> properties such > > >>>>> as STP, MTU, etc.. > > >>>>> The top level collection is used to create/delete such > > >>>>> network > > >>>>> entities. > > >>>>> > > >>>>> The sub-collection in the context of a Cluster is used to > > >>>>> attach/detach a > > >>>>> network from the DC of that cluster. > > >>>>> The network in the context of a cluster has some additional > > >>>>> information, > > >>>>> let's > > >>>>> say for example 'status' of the network: > > >>>>> If a network is defined on all hosts in the cluster > > >>>>> then > > >>>>> it's > > >>>>> status is > > >>>>> 'Operational'. > > >>>>> If a network is not defined on some of the hosts in the > > >>>>> cluster > > >>>>> then > > >>>>> it's > > >>>>> status is 'Not Operational'[1]. > > >>>>> > > >>>>> > > >>>>> -- Problem -- > > >>>>> The problem is that details which are only relevant in > > >>>>> context > > >>>>> of > > >>>>> a > > >>>>> cluster, are still displayed in the root context as well > > >>>>> (e.g: > > >>>>> 'status'). > > >>>>> This can, in certain cases, cause unexpected behaviour. > > >>>>> > > >>>>> For example, let's consider this topology: > > >>>>> Data Center A > > >>>>> | > > >>>>> |\____ Network 'red' > > >>>>> |\____ Cluster A1 > > >>>>> | \______ Network 'red' attached > > >>>>> \____ Cluster A2 > > >>>>> \______ Network 'red' attached > > >>>>> > > >>>>> If the 'status' is the same on all the clusters that the > > >>>>> network > > >>>>> is > > >>>>> attached to > > >>>>> (A1, A2) then there will be one element in the top level > > >>>>> collection, > > >>>>> with the > > >>>>> network details and the 'status' field representing the state > > >>>>> (which > > >>>>> is same > > >>>>> for all networks in the cluster contexts of the cluster). > > >>>>> If, however, the status is not the same (ie. on A1 the > > >>>>> network > > >>>>> is > > >>>>> 'Operational' and on A2 it is 'Non Operational') then the > > >>>>> top-level > > >>>>> collection will show two elements for the network, where all > > >>>>> network > > >>>>> details are the same and only the 'status' field is > > >>>>> different. > > >>>>> > > >>>> > > >>>> That sounds like a bug to me. > > >>>> I think that top collection should include only DC level > > >>>> properties and > > >>>> not cluster level properties, status should not be there (same > > >>>> as > > >>>> display required etc.) > > >>>> > > >>>> > > >>>>> This is problematic IMHO for several reasons: > > >>>>> 1. Showing one network in certain states, and multiple > > >>>>> copies > > >>>>> of this > > >>>>> network in other states is not optimal, to say the > > >>>>> least. > > >>>>> 2. In the top-level collection there is no indicator of > > >>>>> the > > >>>>> cluster > > >>>>> for which > > >>>>> the network is displayed, so there is no way to > > >>>>> differentiate > > >>>>> between the > > >>>>> two 'red' network elements (they will have same id, > > >>>>> name, > > >>>>> etc.). > > >>>>> 3. There is a certain asymmetry between the remove > > >>>>> action[2] > > >>>>> and the > > >>>>> result in that you would expect: you either remove a > > >>>>> network but > > >>>>> in the > > >>>>> result you would see several elements removed. > > >>>>> > > >>>>> > > >>>>> -- Proposed Solutions -- > > >>>>> Personally I can think of several solutions to this problem: > > >>>>> 1. Declare the top-level collection as a collection of > > >>>>> all > > >>>>> networks > > >>>>> that are > > >>>>> either attached to cluster or not, and if they are > > >>>>> indeed > > >>>>> attached > > >>>>> then > > >>>>> show the details for each cluster, including a link > > >>>>> to > > >>>>> the > > >>>>> cluster. > > >>>>> 2. Declare the top-level collection as a collection of > > >>>>> all > > >>>>> networks > > >>>>> that are > > >>>>> defined in data-centers, but they will not contain > > >>>>> any > > >>>>> cluster > > >>>>> specific > > >>>>> data, and thus each entry is unique. > > >>>>> > > >>>>> Solution #2 is breaking the API backwards-compatibility, > > >>>>> since > > >>>>> it > > >>>>> includes > > >>>>> removing certain fields that have appeared today (namely > > >>>>> 'status' > > >>>>> and > > >>>>> 'display') but IMO would give a better experience since the > > >>>>> top-level > > >>>>> collection is actually used for managing networks, and not > > >>>>> their > > >>>>> attachment > > >>>>> to clusters which should be done in the context of each > > >>>>> cluster. > > >>>>> > > >>>> I really don't think top collections should include cluster > > >>>> networks it > > >>>> is not user-friendly to say the least. > > >>> > > >>> how is that different from top collections including VMs and > > >>> templates? > > >>> (or logical networks becoming main tab in the UI going forward) > > >>> > > >> > > >> I think you missed the point of cluster network entity vs. DC > > >> network > > >> entity. > > >> > > >> we should have in the top collection a DC network, I think we > > >> should > > >> not > > >> display the network per cluster in top network collection (that > > >> can > > >> be > > >> viewed under the cluster context). > > > > > > Actually the API has the same concept as you suggest for storage > > > domains. > > > At the top level you don't have a status field, but under data > > > center level, where it's valid then you get the status property. > > > > > > Same should go for networks. > > > The status property should be added only where it's valid, in > > > this > > > case the cluster level sub-collection > > > > so sounds like we want to declare these properties deprecated to be > > able > > to remove them in a future version? > > I guess so, > The question is, are there other location where the status property > (or any other property) exists at an irrelevant level. Unless we > want to go into the effort of mapping them all now we probably need > to define a concept and anything not complying to that is a bug that > is allowed to be fixed without considering it as breaking the API. > > Thoughts? > +1 I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. This is too major to just fix this one, and wait until we bump into another one... Any suggestions of how to do that? > > > > > _______________________________________________ > > 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 lpeer at redhat.com Thu Jul 5 07:51:28 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 05 Jul 2012 10:51:28 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> References: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> Message-ID: <4FF54780.9070703@redhat.com> On 05/07/12 10:24, Miki Kenneth wrote: > > > ----- Original Message ----- >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Simon Grinberg" >>> Cc: "engine-devel" >>> Sent: Wednesday, July 4, 2012 7:38:46 PM >>> Subject: Re: [Engine-devel] Fwd: Problem in REST API >>> handling/displaying of logical networks >>> >>> On 07/04/2012 07:27 PM, Simon Grinberg wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Livnat Peer" >>>>> To: "Itamar Heim" >>>>> Cc: "engine-devel" >>>>> Sent: Tuesday, July 3, 2012 10:06:37 PM >>>>> Subject: Re: [Engine-devel] Fwd: Problem in REST API >>>>> handling/displaying of logical networks >>>>> >>>>> On 03/07/12 21:28, Itamar Heim wrote: >>>>>> On 07/03/2012 10:30 AM, Livnat Peer wrote: >>>>>>> On 02/07/12 17:35, Mike Kolesnik wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I would like to hear opinions about a behaviour that I think >>>>>>>> is >>>>>>>> problematic in >>>>>>>> REST API handling of logical networks. >>>>>>>> >>>>>>>> -- Intro -- >>>>>>>> Today in the REST API we are exposing two collections for >>>>>>>> "logical >>>>>>>> network" related entities. >>>>>>>> >>>>>>>> First is a top level collection which is out of any context >>>>>>>> at >>>>>>>> the >>>>>>>> address >>>>>>>> http://engine/api/networks. >>>>>>>> Second is a sub-collection in the context of a cluster: >>>>>>>> http://engine/api/cluster/xxx/networks >>>>>>>> >>>>>>>> The network itself is defined per DC level, so for each DC >>>>>>>> you >>>>>>>> would >>>>>>>> have >>>>>>>> at least one logical network for management, which has some >>>>>>>> properties such >>>>>>>> as STP, MTU, etc.. >>>>>>>> The top level collection is used to create/delete such >>>>>>>> network >>>>>>>> entities. >>>>>>>> >>>>>>>> The sub-collection in the context of a Cluster is used to >>>>>>>> attach/detach a >>>>>>>> network from the DC of that cluster. >>>>>>>> The network in the context of a cluster has some additional >>>>>>>> information, >>>>>>>> let's >>>>>>>> say for example 'status' of the network: >>>>>>>> If a network is defined on all hosts in the cluster >>>>>>>> then >>>>>>>> it's >>>>>>>> status is >>>>>>>> 'Operational'. >>>>>>>> If a network is not defined on some of the hosts in the >>>>>>>> cluster >>>>>>>> then >>>>>>>> it's >>>>>>>> status is 'Not Operational'[1]. >>>>>>>> >>>>>>>> >>>>>>>> -- Problem -- >>>>>>>> The problem is that details which are only relevant in >>>>>>>> context >>>>>>>> of >>>>>>>> a >>>>>>>> cluster, are still displayed in the root context as well >>>>>>>> (e.g: >>>>>>>> 'status'). >>>>>>>> This can, in certain cases, cause unexpected behaviour. >>>>>>>> >>>>>>>> For example, let's consider this topology: >>>>>>>> Data Center A >>>>>>>> | >>>>>>>> |\____ Network 'red' >>>>>>>> |\____ Cluster A1 >>>>>>>> | \______ Network 'red' attached >>>>>>>> \____ Cluster A2 >>>>>>>> \______ Network 'red' attached >>>>>>>> >>>>>>>> If the 'status' is the same on all the clusters that the >>>>>>>> network >>>>>>>> is >>>>>>>> attached to >>>>>>>> (A1, A2) then there will be one element in the top level >>>>>>>> collection, >>>>>>>> with the >>>>>>>> network details and the 'status' field representing the state >>>>>>>> (which >>>>>>>> is same >>>>>>>> for all networks in the cluster contexts of the cluster). >>>>>>>> If, however, the status is not the same (ie. on A1 the >>>>>>>> network >>>>>>>> is >>>>>>>> 'Operational' and on A2 it is 'Non Operational') then the >>>>>>>> top-level >>>>>>>> collection will show two elements for the network, where all >>>>>>>> network >>>>>>>> details are the same and only the 'status' field is >>>>>>>> different. >>>>>>>> >>>>>>> >>>>>>> That sounds like a bug to me. >>>>>>> I think that top collection should include only DC level >>>>>>> properties and >>>>>>> not cluster level properties, status should not be there (same >>>>>>> as >>>>>>> display required etc.) >>>>>>> >>>>>>> >>>>>>>> This is problematic IMHO for several reasons: >>>>>>>> 1. Showing one network in certain states, and multiple >>>>>>>> copies >>>>>>>> of this >>>>>>>> network in other states is not optimal, to say the >>>>>>>> least. >>>>>>>> 2. In the top-level collection there is no indicator of >>>>>>>> the >>>>>>>> cluster >>>>>>>> for which >>>>>>>> the network is displayed, so there is no way to >>>>>>>> differentiate >>>>>>>> between the >>>>>>>> two 'red' network elements (they will have same id, >>>>>>>> name, >>>>>>>> etc.). >>>>>>>> 3. There is a certain asymmetry between the remove >>>>>>>> action[2] >>>>>>>> and the >>>>>>>> result in that you would expect: you either remove a >>>>>>>> network but >>>>>>>> in the >>>>>>>> result you would see several elements removed. >>>>>>>> >>>>>>>> >>>>>>>> -- Proposed Solutions -- >>>>>>>> Personally I can think of several solutions to this problem: >>>>>>>> 1. Declare the top-level collection as a collection of >>>>>>>> all >>>>>>>> networks >>>>>>>> that are >>>>>>>> either attached to cluster or not, and if they are >>>>>>>> indeed >>>>>>>> attached >>>>>>>> then >>>>>>>> show the details for each cluster, including a link >>>>>>>> to >>>>>>>> the >>>>>>>> cluster. >>>>>>>> 2. Declare the top-level collection as a collection of >>>>>>>> all >>>>>>>> networks >>>>>>>> that are >>>>>>>> defined in data-centers, but they will not contain >>>>>>>> any >>>>>>>> cluster >>>>>>>> specific >>>>>>>> data, and thus each entry is unique. >>>>>>>> >>>>>>>> Solution #2 is breaking the API backwards-compatibility, >>>>>>>> since >>>>>>>> it >>>>>>>> includes >>>>>>>> removing certain fields that have appeared today (namely >>>>>>>> 'status' >>>>>>>> and >>>>>>>> 'display') but IMO would give a better experience since the >>>>>>>> top-level >>>>>>>> collection is actually used for managing networks, and not >>>>>>>> their >>>>>>>> attachment >>>>>>>> to clusters which should be done in the context of each >>>>>>>> cluster. >>>>>>>> >>>>>>> I really don't think top collections should include cluster >>>>>>> networks it >>>>>>> is not user-friendly to say the least. >>>>>> >>>>>> how is that different from top collections including VMs and >>>>>> templates? >>>>>> (or logical networks becoming main tab in the UI going forward) >>>>>> >>>>> >>>>> I think you missed the point of cluster network entity vs. DC >>>>> network >>>>> entity. >>>>> >>>>> we should have in the top collection a DC network, I think we >>>>> should >>>>> not >>>>> display the network per cluster in top network collection (that >>>>> can >>>>> be >>>>> viewed under the cluster context). >>>> >>>> Actually the API has the same concept as you suggest for storage >>>> domains. >>>> At the top level you don't have a status field, but under data >>>> center level, where it's valid then you get the status property. >>>> >>>> Same should go for networks. >>>> The status property should be added only where it's valid, in >>>> this >>>> case the cluster level sub-collection >>> >>> so sounds like we want to declare these properties deprecated to be >>> able >>> to remove them in a future version? >> >> I guess so, >> The question is, are there other location where the status property >> (or any other property) exists at an irrelevant level. Unless we >> want to go into the effort of mapping them all now we probably need >> to define a concept and anything not complying to that is a bug that >> is allowed to be fixed without considering it as breaking the API. >> >> Thoughts? >> > +1 > I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. > This is too major to just fix this one, and wait until we bump into another one... Mike i see there a general consensus that this is a bug and the top level entity should be a DC network. Can you please open a bug / update the existing bug to reflect that. Thanks, Livnat > Any suggestions of how to do that? >> >> >> >>> _______________________________________________ >>> 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 mkolesni at redhat.com Thu Jul 5 08:13:09 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Thu, 05 Jul 2012 04:13:09 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF54780.9070703@redhat.com> Message-ID: <999c43f6-6f2d-4aa3-82a7-5dfe547e15b3@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 05/07/12 10:24, Miki Kenneth wrote: > > > > > > ----- Original Message ----- > >> > >> > >> ----- Original Message ----- > >>> From: "Itamar Heim" > >>> To: "Simon Grinberg" > >>> Cc: "engine-devel" > >>> Sent: Wednesday, July 4, 2012 7:38:46 PM > >>> Subject: Re: [Engine-devel] Fwd: Problem in REST API > >>> handling/displaying of logical networks > >>> > >>> On 07/04/2012 07:27 PM, Simon Grinberg wrote: > >>>> > >>>> > >>>> > >>>> Actually the API has the same concept as you suggest for storage > >>>> domains. > >>>> At the top level you don't have a status field, but under data > >>>> center level, where it's valid then you get the status property. > >>>> > >>>> Same should go for networks. > >>>> The status property should be added only where it's valid, in > >>>> this > >>>> case the cluster level sub-collection > >>> > >>> so sounds like we want to declare these properties deprecated to > >>> be > >>> able > >>> to remove them in a future version? > >> > >> I guess so, > >> The question is, are there other location where the status > >> property > >> (or any other property) exists at an irrelevant level. Unless we > >> want to go into the effort of mapping them all now we probably > >> need > >> to define a concept and anything not complying to that is a bug > >> that > >> is allowed to be fixed without considering it as breaking the API. > >> > >> Thoughts? > >> > > +1 > > I agree that this is a bug and I DO suggest we go into the effort > > of reviewing the other objects as well. > > This is too major to just fix this one, and wait until we bump into > > another one... > > Mike i see there a general consensus that this is a bug and the top > level entity should be a DC network. > Can you please open a bug / update the existing bug to reflect that. OK then I will review the relevant bug(s) and update as needed. Thank you all for the feedback! Thanks, Mike > > Thanks, Livnat > > > > > Any suggestions of how to do that? > > > From mpastern at redhat.com Thu Jul 5 08:31:41 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 05 Jul 2012 11:31:41 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF54780.9070703@redhat.com> References: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> <4FF54780.9070703@redhat.com> Message-ID: <4FF550ED.70001@redhat.com> On 07/05/2012 10:51 AM, Livnat Peer wrote: >>>>> Actually the API has the same concept as you suggest for storage >>>>> >>>> domains. >>>>> >>>> At the top level you don't have a status field, but under data >>>>> >>>> center level, where it's valid then you get the status property. >>>>> >>>> >>>>> >>>> Same should go for networks. >>>>> >>>> The status property should be added only where it's valid, in >>>>> >>>> this >>>>> >>>> case the cluster level sub-collection >>>> >>> >>>> >>> so sounds like we want to declare these properties deprecated to be >>>> >>> able >>>> >>> to remove them in a future version? >>> >> >>> >> I guess so, >>> >> The question is, are there other location where the status property >>> >> (or any other property) exists at an irrelevant level. Unless we >>> >> want to go into the effort of mapping them all now we probably need >>> >> to define a concept and anything not complying to that is a bug that >>> >> is allowed to be fixed without considering it as breaking the API. >>> >> >>> >> Thoughts? >>> >> >> > +1 >> > I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. >> > This is too major to just fix this one, and wait until we bump into another one... > Mike i see there a general consensus that this is a bug and the top > level entity should be a DC network. i disagree that should be completely removed, instead as bug fix it should contain different members: ATTACHED|UNATTACHED (same concept we using in /api/storagedomains/xxx) > Can you please open a bug / update the existing bug to reflect that. > > Thanks, Livnat > > > -- Michael Pasternak RedHat, ENG-Virtualization R&D From lpeer at redhat.com Thu Jul 5 08:40:24 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 05 Jul 2012 11:40:24 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF550ED.70001@redhat.com> References: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> <4FF54780.9070703@redhat.com> <4FF550ED.70001@redhat.com> Message-ID: <4FF552F8.5010707@redhat.com> On 05/07/12 11:31, Michael Pasternak wrote: > On 07/05/2012 10:51 AM, Livnat Peer wrote: >>>>>> Actually the API has the same concept as you suggest for storage >>>>>>>>>> domains. >>>>>>>>>> At the top level you don't have a status field, but under data >>>>>>>>>> center level, where it's valid then you get the status property. >>>>>>>>>> >>>>>>>>>> Same should go for networks. >>>>>>>>>> The status property should be added only where it's valid, in >>>>>>>>>> this >>>>>>>>>> case the cluster level sub-collection >>>>>>>> >>>>>>>> so sounds like we want to declare these properties deprecated to be >>>>>>>> able >>>>>>>> to remove them in a future version? >>>>>> >>>>>> I guess so, >>>>>> The question is, are there other location where the status property >>>>>> (or any other property) exists at an irrelevant level. Unless we >>>>>> want to go into the effort of mapping them all now we probably need >>>>>> to define a concept and anything not complying to that is a bug that >>>>>> is allowed to be fixed without considering it as breaking the API. >>>>>> >>>>>> Thoughts? >>>>>> >>>> +1 >>>> I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. >>>> This is too major to just fix this one, and wait until we bump into another one... >> Mike i see there a general consensus that this is a bug and the top >> level entity should be a DC network. > > i disagree that should be completely removed, instead as bug fix it > should contain different members: ATTACHED|UNATTACHED (same concept we using in > /api/storagedomains/xxx) first you agree we should remove the status as it is today as it does not indicate anything to the user. second you suggest that we'll add attached unattached status, I don't see value in it unless you specify the clusters it is attached to as a sub - collection, I don't see us getting to this anytime soon. we can always add it later and it does not change the fact that the API changes. > >> Can you please open a bug / update the existing bug to reflect that. >> >> Thanks, Livnat >> >> >> > > From mpastern at redhat.com Thu Jul 5 08:56:03 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 05 Jul 2012 11:56:03 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF552F8.5010707@redhat.com> References: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> <4FF54780.9070703@redhat.com> <4FF550ED.70001@redhat.com> <4FF552F8.5010707@redhat.com> Message-ID: <4FF556A3.1030101@redhat.com> On 07/05/2012 11:40 AM, Livnat Peer wrote: > On 05/07/12 11:31, Michael Pasternak wrote: >> On 07/05/2012 10:51 AM, Livnat Peer wrote: >>>>>>> Actually the API has the same concept as you suggest for storage >>>>>>>>>>> domains. >>>>>>>>>>> At the top level you don't have a status field, but under data >>>>>>>>>>> center level, where it's valid then you get the status property. >>>>>>>>>>> >>>>>>>>>>> Same should go for networks. >>>>>>>>>>> The status property should be added only where it's valid, in >>>>>>>>>>> this >>>>>>>>>>> case the cluster level sub-collection >>>>>>>>> >>>>>>>>> so sounds like we want to declare these properties deprecated to be >>>>>>>>> able >>>>>>>>> to remove them in a future version? >>>>>>> >>>>>>> I guess so, >>>>>>> The question is, are there other location where the status property >>>>>>> (or any other property) exists at an irrelevant level. Unless we >>>>>>> want to go into the effort of mapping them all now we probably need >>>>>>> to define a concept and anything not complying to that is a bug that >>>>>>> is allowed to be fixed without considering it as breaking the API. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>> +1 >>>>> I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. >>>>> This is too major to just fix this one, and wait until we bump into another one... >>> Mike i see there a general consensus that this is a bug and the top >>> level entity should be a DC network. >> >> i disagree that should be completely removed, instead as bug fix it >> should contain different members: ATTACHED|UNATTACHED (same concept we using in >> /api/storagedomains/xxx) > > first you agree we should remove the status as it is today as it does > not indicate anything to the user. http://lists.ovirt.org/pipermail/engine-devel/2012-July/002009.html > > second you suggest that we'll add attached unattached status, I don't > see value in it unless you specify the clusters it is attached to as a > sub - collection, I don't see us getting to this anytime soon. exactly on opposite, if network would have /clusters links sub-collection, attached|unattached will not be needed as it obvious by absence or existence of clusters links in sub-collection, the use-case is: when you have N networks in DC and want to find unused one to attach it to cluster. (without this you'll have to traverse over all networks against all clusters to find one unused) > > we can always add it later and it does not change the fact that the API the solution is very simple and does not require any resources: 1. to enum NetworkStatus add new (default) member UNATTACHED 2. clients will show UNATTACHED if NetworkStatus == UNATTACHED or ATTACHED otherwise > changes. > > >> >>> Can you please open a bug / update the existing bug to reflect that. >>> >>> Thanks, Livnat >>> >>> >>> >> >> > > -- Michael Pasternak RedHat, ENG-Virtualization R&D From simon at redhat.com Thu Jul 5 09:00:26 2012 From: simon at redhat.com (Simon Grinberg) Date: Thu, 05 Jul 2012 05:00:26 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF550ED.70001@redhat.com> Message-ID: <158d3e73-7c4f-4507-ad76-d5eb3d653bf3@zmail17.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Michael Pasternak" > To: "Livnat Peer" > Cc: "engine-devel" , "Simon Grinberg" > Sent: Thursday, July 5, 2012 11:31:41 AM > Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks > > On 07/05/2012 10:51 AM, Livnat Peer wrote: > >>>>> Actually the API has the same concept as you suggest for > >>>>> storage > >>>>> >>>> domains. > >>>>> >>>> At the top level you don't have a status field, but under > >>>>> >>>> data > >>>>> >>>> center level, where it's valid then you get the status > >>>>> >>>> property. > >>>>> >>>> > >>>>> >>>> Same should go for networks. > >>>>> >>>> The status property should be added only where it's valid, > >>>>> >>>> in > >>>>> >>>> this > >>>>> >>>> case the cluster level sub-collection > >>>> >>> > >>>> >>> so sounds like we want to declare these properties > >>>> >>> deprecated to be > >>>> >>> able > >>>> >>> to remove them in a future version? > >>> >> > >>> >> I guess so, > >>> >> The question is, are there other location where the status > >>> >> property > >>> >> (or any other property) exists at an irrelevant level. Unless > >>> >> we > >>> >> want to go into the effort of mapping them all now we probably > >>> >> need > >>> >> to define a concept and anything not complying to that is a > >>> >> bug that > >>> >> is allowed to be fixed without considering it as breaking the > >>> >> API. > >>> >> > >>> >> Thoughts? > >>> >> > >> > +1 > >> > I agree that this is a bug and I DO suggest we go into the > >> > effort of reviewing the other objects as well. > >> > This is too major to just fix this one, and wait until we bump > >> > into another one... > > Mike i see there a general consensus that this is a bug and the top > > level entity should be a DC network. > > i disagree that should be completely removed, instead as bug > fix it > should contain different members: ATTACHED|UNATTACHED (same concept > we using in > /api/storagedomains/xxx) With storage domains attached/unattached is generally a 1:1 so it may make sense in a way. * not sure it's going to be in the future with shared read only export domain * It's probably wrong even today with ISO domain in case that the setup contains more then one DC. With Networks it fore may be attached to partial collection on clusters, de facto that will only say it is in uses by at least one cluster. So in both cases this is wrong, If you insist on maintaining this property the only valid values that I can see ATM is INUSE vs UNUSED. - This should be true both for storage domains and logical networks. > > > Can you please open a bug / update the existing bug to reflect > > that. > > > > Thanks, Livnat > > > > > > > > > -- > > 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 lpeer at redhat.com Thu Jul 5 09:06:25 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 05 Jul 2012 12:06:25 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF556A3.1030101@redhat.com> References: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> <4FF54780.9070703@redhat.com> <4FF550ED.70001@redhat.com> <4FF552F8.5010707@redhat.com> <4FF556A3.1030101@redhat.com> Message-ID: <4FF55911.2050104@redhat.com> On 05/07/12 11:56, Michael Pasternak wrote: > On 07/05/2012 11:40 AM, Livnat Peer wrote: >> On 05/07/12 11:31, Michael Pasternak wrote: >>> On 07/05/2012 10:51 AM, Livnat Peer wrote: >>>>>>>> Actually the API has the same concept as you suggest for storage >>>>>>>>>>>> domains. >>>>>>>>>>>> At the top level you don't have a status field, but under data >>>>>>>>>>>> center level, where it's valid then you get the status property. >>>>>>>>>>>> >>>>>>>>>>>> Same should go for networks. >>>>>>>>>>>> The status property should be added only where it's valid, in >>>>>>>>>>>> this >>>>>>>>>>>> case the cluster level sub-collection >>>>>>>>>> >>>>>>>>>> so sounds like we want to declare these properties deprecated to be >>>>>>>>>> able >>>>>>>>>> to remove them in a future version? >>>>>>>> >>>>>>>> I guess so, >>>>>>>> The question is, are there other location where the status property >>>>>>>> (or any other property) exists at an irrelevant level. Unless we >>>>>>>> want to go into the effort of mapping them all now we probably need >>>>>>>> to define a concept and anything not complying to that is a bug that >>>>>>>> is allowed to be fixed without considering it as breaking the API. >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>> +1 >>>>>> I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. >>>>>> This is too major to just fix this one, and wait until we bump into another one... >>>> Mike i see there a general consensus that this is a bug and the top >>>> level entity should be a DC network. >>> >>> i disagree that should be completely removed, instead as bug fix it >>> should contain different members: ATTACHED|UNATTACHED (same concept we using in >>> /api/storagedomains/xxx) >> >> first you agree we should remove the status as it is today as it does >> not indicate anything to the user. > > http://lists.ovirt.org/pipermail/engine-devel/2012-July/002009.html > >> >> second you suggest that we'll add attached unattached status, I don't >> see value in it unless you specify the clusters it is attached to as a >> sub - collection, I don't see us getting to this anytime soon. > > exactly on opposite, if network would have /clusters links sub-collection, > attached|unattached will not be needed as it obvious by > absence or existence of clusters links in sub-collection, > > the use-case is: when you have N networks in DC and want to find unused one > to attach it to cluster. > I don't see the logic in this use case, you don't attach a network to a cluster because it is unused, you attach it because you want to use it, having it attached to another cluster does not make much of a difference. I don't see the need for the attached/detached property. I do think that adding a sub-collection of attached cluster can give some value to the user but again not an immediate action. > (without this you'll have to traverse over all networks against all > clusters to find one unused) > >> >> we can always add it later and it does not change the fact that the API > > the solution is very simple and does not require any resources: > > 1. to enum NetworkStatus add new (default) member UNATTACHED > 2. clients will show UNATTACHED if NetworkStatus == UNATTACHED > or ATTACHED otherwise > >> changes. >> >> >>> >>>> Can you please open a bug / update the existing bug to reflect that. >>>> >>>> Thanks, Livnat >>>> >>>> >>>> >>> >>> >> >> > > From simon at redhat.com Thu Jul 5 09:06:30 2012 From: simon at redhat.com (Simon Grinberg) Date: Thu, 05 Jul 2012 05:06:30 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF556A3.1030101@redhat.com> Message-ID: ----- Original Message ----- > From: "Michael Pasternak" > To: "Livnat Peer" > Cc: "engine-devel" , "Simon Grinberg" > Sent: Thursday, July 5, 2012 11:56:03 AM > Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks > > On 07/05/2012 11:40 AM, Livnat Peer wrote: > > On 05/07/12 11:31, Michael Pasternak wrote: > >> On 07/05/2012 10:51 AM, Livnat Peer wrote: > >>>>>>> Actually the API has the same concept as you suggest for > >>>>>>> storage > >>>>>>>>>>> domains. > >>>>>>>>>>> At the top level you don't have a status field, but under > >>>>>>>>>>> data > >>>>>>>>>>> center level, where it's valid then you get the status > >>>>>>>>>>> property. > >>>>>>>>>>> > >>>>>>>>>>> Same should go for networks. > >>>>>>>>>>> The status property should be added only where it's > >>>>>>>>>>> valid, in > >>>>>>>>>>> this > >>>>>>>>>>> case the cluster level sub-collection > >>>>>>>>> > >>>>>>>>> so sounds like we want to declare these properties > >>>>>>>>> deprecated to be > >>>>>>>>> able > >>>>>>>>> to remove them in a future version? > >>>>>>> > >>>>>>> I guess so, > >>>>>>> The question is, are there other location where the status > >>>>>>> property > >>>>>>> (or any other property) exists at an irrelevant level. Unless > >>>>>>> we > >>>>>>> want to go into the effort of mapping them all now we > >>>>>>> probably need > >>>>>>> to define a concept and anything not complying to that is a > >>>>>>> bug that > >>>>>>> is allowed to be fixed without considering it as breaking the > >>>>>>> API. > >>>>>>> > >>>>>>> Thoughts? > >>>>>>> > >>>>> +1 > >>>>> I agree that this is a bug and I DO suggest we go into the > >>>>> effort of reviewing the other objects as well. > >>>>> This is too major to just fix this one, and wait until we bump > >>>>> into another one... > >>> Mike i see there a general consensus that this is a bug and the > >>> top > >>> level entity should be a DC network. > >> > >> i disagree that should be completely removed, instead as > >> bug fix it > >> should contain different members: ATTACHED|UNATTACHED (same > >> concept we using in > >> /api/storagedomains/xxx) > > > > first you agree we should remove the status as it is today as it > > does > > not indicate anything to the user. > > http://lists.ovirt.org/pipermail/engine-devel/2012-July/002009.html > > > > > second you suggest that we'll add attached unattached status, I > > don't > > see value in it unless you specify the clusters it is attached to > > as a > > sub - collection, I don't see us getting to this anytime soon. > > exactly on opposite, if network would have /clusters links > sub-collection, > attached|unattached will not be needed as it obvious > by > absence or existence of clusters links in sub-collection, > > the use-case is: when you have N networks in DC and want to find > unused one > to attach it to cluster. > > (without this you'll have to traverse over all networks > against all > clusters to find one unused) Previous email sent in delay due to network disconnection, So we are saying the same, that the status if left de facto indicates used/unused so why not to use the proper terminology? attached is already an over loaded term > > > > > we can always add it later and it does not change the fact that the > > API > > the solution is very simple and does not require any resources: > > 1. to enum NetworkStatus add new (default) member UNATTACHED > 2. clients will show UNATTACHED if NetworkStatus == UNATTACHED > or ATTACHED otherwise > > > changes. > > > > > >> > >>> Can you please open a bug / update the existing bug to reflect > >>> that. > >>> > >>> Thanks, Livnat > >>> > >>> > >>> > >> > >> > > > > > > > -- > > 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 Thu Jul 5 09:09:20 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 05 Jul 2012 12:09:20 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <158d3e73-7c4f-4507-ad76-d5eb3d653bf3@zmail17.collab.prod.int.phx2.redhat.com> References: <158d3e73-7c4f-4507-ad76-d5eb3d653bf3@zmail17.collab.prod.int.phx2.redhat.com> Message-ID: <4FF559C0.4040003@redhat.com> On 07/05/2012 12:00 PM, Simon Grinberg wrote: > > > ----- Original Message ----- >> From: "Michael Pasternak" >> To: "Livnat Peer" >> Cc: "engine-devel" , "Simon Grinberg" >> Sent: Thursday, July 5, 2012 11:31:41 AM >> Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks >> >> On 07/05/2012 10:51 AM, Livnat Peer wrote: >>>>>>> Actually the API has the same concept as you suggest for >>>>>>> storage >>>>>>>>>>> domains. >>>>>>>>>>> At the top level you don't have a status field, but under >>>>>>>>>>> data >>>>>>>>>>> center level, where it's valid then you get the status >>>>>>>>>>> property. >>>>>>>>>>> >>>>>>>>>>> Same should go for networks. >>>>>>>>>>> The status property should be added only where it's valid, >>>>>>>>>>> in >>>>>>>>>>> this >>>>>>>>>>> case the cluster level sub-collection >>>>>>>>> >>>>>>>>> so sounds like we want to declare these properties >>>>>>>>> deprecated to be >>>>>>>>> able >>>>>>>>> to remove them in a future version? >>>>>>> >>>>>>> I guess so, >>>>>>> The question is, are there other location where the status >>>>>>> property >>>>>>> (or any other property) exists at an irrelevant level. Unless >>>>>>> we >>>>>>> want to go into the effort of mapping them all now we probably >>>>>>> need >>>>>>> to define a concept and anything not complying to that is a >>>>>>> bug that >>>>>>> is allowed to be fixed without considering it as breaking the >>>>>>> API. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>> +1 >>>>> I agree that this is a bug and I DO suggest we go into the >>>>> effort of reviewing the other objects as well. >>>>> This is too major to just fix this one, and wait until we bump >>>>> into another one... >>> Mike i see there a general consensus that this is a bug and the top >>> level entity should be a DC network. >> >> i disagree that should be completely removed, instead as bug >> fix it >> should contain different members: ATTACHED|UNATTACHED (same concept >> we using in >> /api/storagedomains/xxx) > > With storage domains attached/unattached is generally a 1:1 so it may make sense in a way. > * not sure it's going to be in the future with shared read only export domain > * It's probably wrong even today with ISO domain in case that the setup contains more then one DC. attached|unattached does not imply on amount of resources it being used in, only used/not-used > > With Networks it fore may be attached to partial collection on clusters, de facto that will only say it is in uses by at least one cluster. that's the purpose, see my other email (to Livnat) on this. > > So in both cases this is wrong, why? i'd say it's exactly serve the goal. > > If you insist on maintaining this property the only valid values that I can see ATM is INUSE vs UNUSED. - This should be true both for storage domains and logical networks. i don't mind, only problem is that SD uses UNATTACHED and you told by yourself that it's 1:1, so i guess we won't break SD api for consistency ... > > >> >>> Can you please open a bug / update the existing bug to reflect >>> that. >>> >>> Thanks, Livnat >>> >>> >>> >> >> >> -- >> >> 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 mpastern at redhat.com Thu Jul 5 09:13:34 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 05 Jul 2012 12:13:34 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF55911.2050104@redhat.com> References: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> <4FF54780.9070703@redhat.com> <4FF550ED.70001@redhat.com> <4FF552F8.5010707@redhat.com> <4FF556A3.1030101@redhat.com> <4FF55911.2050104@redhat.com> Message-ID: <4FF55ABE.4030704@redhat.com> On 07/05/2012 12:06 PM, Livnat Peer wrote: > On 05/07/12 11:56, Michael Pasternak wrote: >> On 07/05/2012 11:40 AM, Livnat Peer wrote: >>> On 05/07/12 11:31, Michael Pasternak wrote: >>>> On 07/05/2012 10:51 AM, Livnat Peer wrote: >>>>>>>>> Actually the API has the same concept as you suggest for storage >>>>>>>>>>>>> domains. >>>>>>>>>>>>> At the top level you don't have a status field, but under data >>>>>>>>>>>>> center level, where it's valid then you get the status property. >>>>>>>>>>>>> >>>>>>>>>>>>> Same should go for networks. >>>>>>>>>>>>> The status property should be added only where it's valid, in >>>>>>>>>>>>> this >>>>>>>>>>>>> case the cluster level sub-collection >>>>>>>>>>> >>>>>>>>>>> so sounds like we want to declare these properties deprecated to be >>>>>>>>>>> able >>>>>>>>>>> to remove them in a future version? >>>>>>>>> >>>>>>>>> I guess so, >>>>>>>>> The question is, are there other location where the status property >>>>>>>>> (or any other property) exists at an irrelevant level. Unless we >>>>>>>>> want to go into the effort of mapping them all now we probably need >>>>>>>>> to define a concept and anything not complying to that is a bug that >>>>>>>>> is allowed to be fixed without considering it as breaking the API. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>> +1 >>>>>>> I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. >>>>>>> This is too major to just fix this one, and wait until we bump into another one... >>>>> Mike i see there a general consensus that this is a bug and the top >>>>> level entity should be a DC network. >>>> >>>> i disagree that should be completely removed, instead as bug fix it >>>> should contain different members: ATTACHED|UNATTACHED (same concept we using in >>>> /api/storagedomains/xxx) >>> >>> first you agree we should remove the status as it is today as it does >>> not indicate anything to the user. >> >> http://lists.ovirt.org/pipermail/engine-devel/2012-July/002009.html >> >>> >>> second you suggest that we'll add attached unattached status, I don't >>> see value in it unless you specify the clusters it is attached to as a >>> sub - collection, I don't see us getting to this anytime soon. >> >> exactly on opposite, if network would have /clusters links sub-collection, >> attached|unattached will not be needed as it obvious by >> absence or existence of clusters links in sub-collection, >> >> the use-case is: when you have N networks in DC and want to find unused one >> to attach it to cluster. >> > > I don't see the logic in this use case, you don't attach a network to a > cluster because it is unused, you attach it because you want to use it, > having it attached to another cluster does not make much of a difference. > > I don't see the need for the attached/detached property. > I do think that adding a sub-collection of attached cluster can give > some value to the user but again not an immediate action. I'll give you one scenario and I'm sure there are lot more: delete all unused networks .... > > >> (without this you'll have to traverse over all networks against all >> clusters to find one unused) >> >>> >>> we can always add it later and it does not change the fact that the API >> >> the solution is very simple and does not require any resources: >> >> 1. to enum NetworkStatus add new (default) member UNATTACHED >> 2. clients will show UNATTACHED if NetworkStatus == UNATTACHED >> or ATTACHED otherwise >> >>> changes. >>> >>> >>>> >>>>> Can you please open a bug / update the existing bug to reflect that. >>>>> >>>>> Thanks, Livnat >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- Michael Pasternak RedHat, ENG-Virtualization R&D From lpeer at redhat.com Thu Jul 5 09:19:23 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 05 Jul 2012 12:19:23 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF55ABE.4030704@redhat.com> References: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> <4FF54780.9070703@redhat.com> <4FF550ED.70001@redhat.com> <4FF552F8.5010707@redhat.com> <4FF556A3.1030101@redhat.com> <4FF55911.2050104@redhat.com> <4FF55ABE.4030704@redhat.com> Message-ID: <4FF55C1B.70604@redhat.com> On 05/07/12 12:13, Michael Pasternak wrote: > On 07/05/2012 12:06 PM, Livnat Peer wrote: >> On 05/07/12 11:56, Michael Pasternak wrote: >>> On 07/05/2012 11:40 AM, Livnat Peer wrote: >>>> On 05/07/12 11:31, Michael Pasternak wrote: >>>>> On 07/05/2012 10:51 AM, Livnat Peer wrote: >>>>>>>>>> Actually the API has the same concept as you suggest for storage >>>>>>>>>>>>>> domains. >>>>>>>>>>>>>> At the top level you don't have a status field, but under data >>>>>>>>>>>>>> center level, where it's valid then you get the status property. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Same should go for networks. >>>>>>>>>>>>>> The status property should be added only where it's valid, in >>>>>>>>>>>>>> this >>>>>>>>>>>>>> case the cluster level sub-collection >>>>>>>>>>>> >>>>>>>>>>>> so sounds like we want to declare these properties deprecated to be >>>>>>>>>>>> able >>>>>>>>>>>> to remove them in a future version? >>>>>>>>>> >>>>>>>>>> I guess so, >>>>>>>>>> The question is, are there other location where the status property >>>>>>>>>> (or any other property) exists at an irrelevant level. Unless we >>>>>>>>>> want to go into the effort of mapping them all now we probably need >>>>>>>>>> to define a concept and anything not complying to that is a bug that >>>>>>>>>> is allowed to be fixed without considering it as breaking the API. >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>> +1 >>>>>>>> I agree that this is a bug and I DO suggest we go into the effort of reviewing the other objects as well. >>>>>>>> This is too major to just fix this one, and wait until we bump into another one... >>>>>> Mike i see there a general consensus that this is a bug and the top >>>>>> level entity should be a DC network. >>>>> >>>>> i disagree that should be completely removed, instead as bug fix it >>>>> should contain different members: ATTACHED|UNATTACHED (same concept we using in >>>>> /api/storagedomains/xxx) >>>> >>>> first you agree we should remove the status as it is today as it does >>>> not indicate anything to the user. >>> >>> http://lists.ovirt.org/pipermail/engine-devel/2012-July/002009.html >>> >>>> >>>> second you suggest that we'll add attached unattached status, I don't >>>> see value in it unless you specify the clusters it is attached to as a >>>> sub - collection, I don't see us getting to this anytime soon. >>> >>> exactly on opposite, if network would have /clusters links sub-collection, >>> attached|unattached will not be needed as it obvious by >>> absence or existence of clusters links in sub-collection, >>> >>> the use-case is: when you have N networks in DC and want to find unused one >>> to attach it to cluster. >>> >> >> I don't see the logic in this use case, you don't attach a network to a >> cluster because it is unused, you attach it because you want to use it, >> having it attached to another cluster does not make much of a difference. >> >> I don't see the need for the attached/detached property. >> I do think that adding a sub-collection of attached cluster can give >> some value to the user but again not an immediate action. > > I'll give you one scenario and I'm sure there are lot more: > delete all unused networks .... > not strong enough use case in my opinion to add this yet another confusing property. BTW - If a requirement will get from the field to add properties we can do them later why add something we think is not needed. >> >> >>> (without this you'll have to traverse over all networks against all >>> clusters to find one unused) >>> >>>> >>>> we can always add it later and it does not change the fact that the API >>> >>> the solution is very simple and does not require any resources: >>> >>> 1. to enum NetworkStatus add new (default) member UNATTACHED >>> 2. clients will show UNATTACHED if NetworkStatus == UNATTACHED >>> or ATTACHED otherwise >>> >>>> changes. >>>> >>>> >>>>> >>>>>> Can you please open a bug / update the existing bug to reflect that. >>>>>> >>>>>> Thanks, Livnat >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From mpastern at redhat.com Thu Jul 5 09:32:41 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 05 Jul 2012 12:32:41 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF55C1B.70604@redhat.com> References: <32814608.128.1341473089196.JavaMail.mkenneth@mkenneth.csb> <4FF54780.9070703@redhat.com> <4FF550ED.70001@redhat.com> <4FF552F8.5010707@redhat.com> <4FF556A3.1030101@redhat.com> <4FF55911.2050104@redhat.com> <4FF55ABE.4030704@redhat.com> <4FF55C1B.70604@redhat.com> Message-ID: <4FF55F39.90801@redhat.com> On 07/05/2012 12:19 PM, Livnat Peer wrote: >> I'll give you one scenario and I'm sure there are lot more: >> > delete all unused networks .... >> > > not strong enough use case in my opinion i do see sense in this, and based on my experience of closing ~5 bugs on this for SD and explaining like ~10 times on ML to users why /api/storagedomains/xxx doesn't have , I'm sure it should be done this way as it creates clear differentiation between root-resource and cluster-resource (shared) status. > to add this yet another confusing property. you not adding another property, you fix existent (which was incorrectly used/implemented). > > BTW - If a requirement will get from the field to add properties we can > do them later why add something we think is not needed. > > -- Michael Pasternak RedHat, ENG-Virtualization R&D From abaron at redhat.com Thu Jul 5 09:57:48 2012 From: abaron at redhat.com (Ayal Baron) Date: Thu, 05 Jul 2012 05:57:48 -0400 (EDT) Subject: [Engine-devel] Search option for finding disks for templates / vms In-Reply-To: <68559418-f824-4300-92f8-e36be0bb7958@zmail20.collab.prod.int.phx2.redhat.com> Message-ID: <56a3e660-1987-4352-b7ef-565e39e05d48@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > ----- Original Message ----- > > From: "Ayal Baron" > > Sent: Wednesday, July 4, 2012 9:29:55 AM > > > > ----- Original Message ----- > > > On 07/03/2012 06:44 PM, Miki Kenneth wrote: > > > > > > > > > > > > ----- Original Message ----- > > > >> Hey, > > > >> > > > >> https://bugzilla.redhat.com/show_bug.cgi?id=828089 > > > >> > > > >> I would like add a search option for searching disks of a VM > > > >> or > > > >> Template, > > > >> > > > >> Please suggest a name for the search option, > > > >> In the 'view' level we call it 'entity_type', but maybe 'type' > > > >> is > > > >> nicer ? (or not too specific?) > > > > Belongs-To/Attached-To/ > > > Part of? > > > > So what do you do with a disk that is both in a template and > > attached > > read-only to a VM? (no, we do not currently support it, but we will > > as there is no reason not to). > > When a container references the disk, that is not a property of the > > disk so there should be no column indicating that when looking at > > the disk. > > The disk is either read only or read write, that's it. The column > > should state that. > > I think that "read-only/read-write" is not related to "attached to > Template(s)/attached to VM(s)/attached to both (not supported yet)". Indeed, it is related to the actual requirement afaiu. > Moreover, wouldn't we want "read-only/read-write" to be per > VM/Template, and not a property of the Disk itself (i.e. a disk can > be writable in VM1 and read-only in VM2/Template1)? As opposed to > the "attached to Templates/attached to VMs" information, which is > clearly a property of the Disk (well, not a "real" property, as Ayal > has also mentioned - it is calculated information, based on the You can mount a r/w disk as read-only in a VM, so how to mount it is indeed a vm-disk relationship. However, a disk can be immutable (iso, read-only snapshot as we use for templates, etc). I've seen 2 RFEs here: 1. Be able to differentiate between disks (currently when you create a template from a VM then the disks would have the same alias and user has to stand on the disk itself to differentiate. As a result, what was requested is this column, however, if we create 2 templates from the same VM (different times so different content) the disks would end up still having the same alias, so this column would be useless for that purpose. What we need to do is: 1. make sure that by default we give different aliases to disks when creating a template 2. allow user to change the aliases when creating 3. allow user to change the aliases on existing disks (even when part of a template) Second type of request I've seen is about the types of operations that can be performed on the disks. The differences I know of are: 1. VM disks can only be moved between SDs - This has to do with the disk being r/w. You cannot have 2 copies of the same disk (you can clone it, but then you'd have 2 different disks with different UUIDs). 2. Template disks can only be copied between domains - This is actually not exactly true, as it can be copied, and also deleted from a domain (as long as one copy remains somewhere), just no 'move' operation. But again, the reason we can have multiple copies of the same disk (and one disk entity in engine referencing them all) is because it is immutable (i.e. read only). 3. Currently "template" disks cannot be deleted - This is the tricky one. "Template" disks are similar to "Shared disks" in the sense that there are multiple VMs using them. However, depending on the implementation, sometimes there is no problem in deleting the object (when using storage array cloning) and sometimes there is (with current images implementation). With the new image implementation in vdsm (no code committed yet) you should always be able to 'delete' the disk and underlying it would perform the correct operation (in case of file system - just delete it because we have hard links to it in each VM, in case of storage offloading - actually delete it and in case of block domains simply remove the image tag). So in fact, I see no reason why the user should not be able to delete the disk. As you can see, in the scenarios above there isn't a single case where 'attached-to-object(s)-of-type template/VM' is relevant. Are there additional use cases/something else which I'm missing? > entities to which the disk is attached to; still, it is interesting > information that "deserves" a column in the Disks main-grid IMO. Why? > ["read-only/read-write" is interesting information as well, and > should also be displayed - don't know if in the main grid or in the > VMs/Templates sub-tabs - probably worth a separate discussion] > On top of all this, our current approach to templates is quite limited. Our templates are comprised of 3 elements: 1. immutable disks 2. hardware configuration 3. migration domain + network config (which hosts can run it, what specific networks to attach to, etc). There is no reason for a user not to be able to mix and match. e.g. Provision from a disk with Fedora 16 + LibreOffice + whatever Hardware profile Medium (2 cores, 4GB memory. ...) Host Cluster - whatever (different than the one the VM used to create the template is in with different networks) In this view, for convenience, user could be able to create predefined profiles containing everything, but doesn't have to. Assuming we want to go down this path (open for discussion), then the column we're discussing would be totally irrelevant and wrong. > > > > > > > > >> > > > >> > > > >> Thanks, > > > >> > > > >> > > > >> > > > >> Regards, > > > >> Asaf > > > >> > > > >> > > > >> > > > >> > > > > _______________________________________________ > > > > 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 mkolesni at redhat.com Thu Jul 5 10:23:13 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Thu, 05 Jul 2012 06:23:13 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF55F39.90801@redhat.com> Message-ID: > On 07/05/2012 12:19 PM, Livnat Peer wrote: > >> I'll give you one scenario and I'm sure there are lot more: > >> > delete all unused networks .... > >> > > > not strong enough use case in my opinion > > i do see sense in this, and based on my experience of > closing ~5 bugs on this for SD and explaining like > ~10 times on ML to users why /api/storagedomains/xxx > doesn't have , I'm sure it should be done this way > as it creates clear differentiation between root-resource > and cluster-resource (shared) status. > > > to add this yet another confusing property. > > you not adding another property, you fix existent > (which was incorrectly used/implemented). > > > > > BTW - If a requirement will get from the field to add properties we > > can > > do them later why add something we think is not needed. > > > > > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > I think we got a little bit off the topic here, so if you don't mind I would like to see if everyone agrees on this: We have at the api/networks collection these properties and their possible values: status - OPERATIONAL, NON_OPERATIONAL display - true, false We (as far as I understood) agreed that these fields causea problem in this context since they can be different for a given network, and current representation will return the network element multiple times with only difference in either one of these fields. Also I understood we agreed that this is bad behaviour (even a bug) and we don't want to support this anymore. This gives 2 choices IMHO: 1. Fix the behaviour but keep the fields with some default values. 2. Fix the behaviour and remove these field as well, which isn't really breaking an API since the behaviour was broken to begin with. Please comment what option seems valid (I though we were going to the direction of fix #2). Thanks, Mike From lpeer at redhat.com Thu Jul 5 10:38:52 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 05 Jul 2012 13:38:52 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: References: Message-ID: <4FF56EBC.7000104@redhat.com> On 05/07/12 13:23, Mike Kolesnik wrote: >> On 07/05/2012 12:19 PM, Livnat Peer wrote: >>>> I'll give you one scenario and I'm sure there are lot more: >>>>> delete all unused networks .... >>>>> >>> not strong enough use case in my opinion >> >> i do see sense in this, and based on my experience of >> closing ~5 bugs on this for SD and explaining like >> ~10 times on ML to users why /api/storagedomains/xxx >> doesn't have , I'm sure it should be done this way >> as it creates clear differentiation between root-resource >> and cluster-resource (shared) status. >> >>> to add this yet another confusing property. >> >> you not adding another property, you fix existent >> (which was incorrectly used/implemented). >> >>> >>> BTW - If a requirement will get from the field to add properties we >>> can >>> do them later why add something we think is not needed. >>> >>> >> >> >> -- >> >> Michael Pasternak >> RedHat, ENG-Virtualization R&D >> > > I think we got a little bit off the topic here, so if you don't mind I would like to see if everyone agrees on this: > > We have at the api/networks collection these properties and their possible values: > status - OPERATIONAL, NON_OPERATIONAL > display - true, false > > We (as far as I understood) agreed that these fields causea problem in this context since they can be different for a given network, and current representation will return the network element multiple times with only difference in either one of these fields. > Also I understood we agreed that this is bad behaviour (even a bug) and we don't want to support this anymore. > > This gives 2 choices IMHO: > 1. Fix the behaviour but keep the fields with some default values. > 2. Fix the behaviour and remove these field as well, which isn't really breaking an API since the behaviour was broken to begin with. > So a summary of the thread so far: Simon, Miki Ori and me voted +1 for option #2 Michael wants to change the value of the status field to attach/detach Anyone else wants to vote in on this? > Please comment what option seems valid (I though we were going to the direction of fix #2). > > Thanks, > Mike > From mkolesni at redhat.com Thu Jul 5 10:43:26 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Thu, 05 Jul 2012 06:43:26 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF56EBC.7000104@redhat.com> Message-ID: <0d7c140c-6c7c-43af-b0fe-732abb4422cd@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 05/07/12 13:23, Mike Kolesnik wrote: > >> On 07/05/2012 12:19 PM, Livnat Peer wrote: > >>>> I'll give you one scenario and I'm sure there are lot more: > >>>>> delete all unused networks .... > >>>>> > >>> not strong enough use case in my opinion > >> > >> i do see sense in this, and based on my experience of > >> closing ~5 bugs on this for SD and explaining like > >> ~10 times on ML to users why /api/storagedomains/xxx > >> doesn't have , I'm sure it should be done this way > >> as it creates clear differentiation between root-resource > >> and cluster-resource (shared) status. > >> > >>> to add this yet another confusing property. > >> > >> you not adding another property, you fix existent > >> (which was incorrectly used/implemented). > >> > >>> > >>> BTW - If a requirement will get from the field to add properties > >>> we > >>> can > >>> do them later why add something we think is not needed. > >>> > >>> > >> > >> > >> -- > >> > >> Michael Pasternak > >> RedHat, ENG-Virtualization R&D > >> > > > > I think we got a little bit off the topic here, so if you don't > > mind I would like to see if everyone agrees on this: > > > > We have at the api/networks collection these properties and their > > possible values: > > status - OPERATIONAL, NON_OPERATIONAL > > display - true, false > > > > We (as far as I understood) agreed that these fields causea problem > > in this context since they can be different for a given network, > > and current representation will return the network element > > multiple times with only difference in either one of these fields. > > Also I understood we agreed that this is bad behaviour (even a bug) > > and we don't want to support this anymore. > > > > This gives 2 choices IMHO: > > 1. Fix the behaviour but keep the fields with some default > > values. > > 2. Fix the behaviour and remove these field as well, which isn't > > really breaking an API since the behaviour was broken to begin > > with. > > > > So a summary of the thread so far: > > Simon, Miki Ori and me voted +1 for option #2 > > Michael wants to change the value of the status field to > attach/detach > > Anyone else wants to vote in on this? I vote for fix #2. I think not only is leaving these fields with some defaults a mistake, but also changing their possible values is breaking the API either way, so if we already breaking the API I think removing the fields entirely is cleaner, and in future if we have request to add fields then we can model them correctly. > > > > Please comment what option seems valid (I though we were going to > > the direction of fix #2). > > > > Thanks, > > Mike > > > > > From masayag at redhat.com Thu Jul 5 10:50:31 2012 From: masayag at redhat.com (Moti Asayag) Date: Thu, 05 Jul 2012 13:50:31 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF56EBC.7000104@redhat.com> References: <4FF56EBC.7000104@redhat.com> Message-ID: <4FF57177.8060407@redhat.com> On 07/05/2012 01:38 PM, Livnat Peer wrote: > On 05/07/12 13:23, Mike Kolesnik wrote: >>> On 07/05/2012 12:19 PM, Livnat Peer wrote: >>>>> I'll give you one scenario and I'm sure there are lot more: >>>>>> delete all unused networks .... >>>>>> >>>> not strong enough use case in my opinion >>> >>> i do see sense in this, and based on my experience of >>> closing ~5 bugs on this for SD and explaining like >>> ~10 times on ML to users why /api/storagedomains/xxx >>> doesn't have , I'm sure it should be done this way >>> as it creates clear differentiation between root-resource >>> and cluster-resource (shared) status. >>> >>>> to add this yet another confusing property. >>> >>> you not adding another property, you fix existent >>> (which was incorrectly used/implemented). >>> >>>> >>>> BTW - If a requirement will get from the field to add properties we >>>> can >>>> do them later why add something we think is not needed. >>>> >>>> >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >>> >> >> I think we got a little bit off the topic here, so if you don't mind I would like to see if everyone agrees on this: >> >> We have at the api/networks collection these properties and their possible values: >> status - OPERATIONAL, NON_OPERATIONAL >> display - true, false >> >> We (as far as I understood) agreed that these fields causea problem in this context since they can be different for a given network, and current representation will return the network element multiple times with only difference in either one of these fields. >> Also I understood we agreed that this is bad behaviour (even a bug) and we don't want to support this anymore. >> >> This gives 2 choices IMHO: >> 1. Fix the behaviour but keep the fields with some default values. >> 2. Fix the behaviour and remove these field as well, which isn't really breaking an API since the behaviour was broken to begin with. >> > > So a summary of the thread so far: > > Simon, Miki Ori and me voted +1 for option #2 > > Michael wants to change the value of the status field to attach/detach > > Anyone else wants to vote in on this? > +1 for #2. It will simplify the presentation of the networks on DC level. > >> Please comment what option seems valid (I though we were going to the direction of fix #2). >> >> Thanks, >> Mike >> > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From ovedo at redhat.com Thu Jul 5 10:53:50 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Thu, 05 Jul 2012 06:53:50 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <0d7c140c-6c7c-43af-b0fe-732abb4422cd@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <09a5363d-eba9-4712-a3b7-1b65cc64607a@zmail02.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Mike Kolesnik" > To: "engine-devel" > Cc: "Simon Grinberg" > Sent: Thursday, July 5, 2012 1:43:26 PM > Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks > > ----- Original Message ----- > > On 05/07/12 13:23, Mike Kolesnik wrote: > > >> On 07/05/2012 12:19 PM, Livnat Peer wrote: > > >>>> I'll give you one scenario and I'm sure there are lot more: > > >>>>> delete all unused networks .... > > >>>>> > > >>> not strong enough use case in my opinion > > >> > > >> i do see sense in this, and based on my experience of > > >> closing ~5 bugs on this for SD and explaining like > > >> ~10 times on ML to users why /api/storagedomains/xxx > > >> doesn't have , I'm sure it should be done this way > > >> as it creates clear differentiation between root-resource > > >> and cluster-resource (shared) status. > > >> > > >>> to add this yet another confusing property. > > >> > > >> you not adding another property, you fix existent > > >> (which was incorrectly used/implemented). > > >> > > >>> > > >>> BTW - If a requirement will get from the field to add > > >>> properties > > >>> we > > >>> can > > >>> do them later why add something we think is not needed. > > >>> > > >>> > > >> > > >> > > >> -- > > >> > > >> Michael Pasternak > > >> RedHat, ENG-Virtualization R&D > > >> > > > > > > I think we got a little bit off the topic here, so if you don't > > > mind I would like to see if everyone agrees on this: > > > > > > We have at the api/networks collection these properties and their > > > possible values: > > > status - OPERATIONAL, NON_OPERATIONAL > > > display - true, false > > > > > > We (as far as I understood) agreed that these fields causea > > > problem > > > in this context since they can be different for a given network, > > > and current representation will return the network element > > > multiple times with only difference in either one of these > > > fields. > > > Also I understood we agreed that this is bad behaviour (even a > > > bug) > > > and we don't want to support this anymore. > > > > > > This gives 2 choices IMHO: > > > 1. Fix the behaviour but keep the fields with some default > > > values. > > > 2. Fix the behaviour and remove these field as well, which > > > isn't > > > really breaking an API since the behaviour was broken to begin > > > with. > > > > > > > So a summary of the thread so far: > > > > Simon, Miki Ori and me voted +1 for option #2 > > > > Michael wants to change the value of the status field to > > attach/detach > > > > Anyone else wants to vote in on this? > > I vote for fix #2. > > I think not only is leaving these fields with some defaults a > mistake, but also changing their possible values is breaking the API > either way, so if we already breaking the API I think removing the > fields entirely is cleaner, and in future if we have request to add > fields then we can model them correctly. > I vote for fix #2 as well. It makes more sense, as IMO there is no need to display cluster-specific fields on the top-level network collection. Mixing cluster related fields in the logical network resource is wrong as it mixes two abstraction layers in one resource. Also, looks like logical networks will become main entities in the future, which also strengthen this approach. > > > > > > > Please comment what option seems valid (I though we were going to > > > the direction of fix #2). > > > > > > Thanks, > > > Mike > > > > > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mpastern at redhat.com Thu Jul 5 11:26:23 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Thu, 05 Jul 2012 14:26:23 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <0d7c140c-6c7c-43af-b0fe-732abb4422cd@zmail14.collab.prod.int.phx2.redhat.com> References: <0d7c140c-6c7c-43af-b0fe-732abb4422cd@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <4FF579DF.1090507@redhat.com> On 07/05/2012 01:43 PM, Mike Kolesnik wrote: > ----- Original Message ----- >> On 05/07/12 13:23, Mike Kolesnik wrote: >>>> On 07/05/2012 12:19 PM, Livnat Peer wrote: >>>>>> I'll give you one scenario and I'm sure there are lot more: >>>>>>> delete all unused networks .... >>>>>>> >>>>> not strong enough use case in my opinion >>>> >>>> i do see sense in this, and based on my experience of >>>> closing ~5 bugs on this for SD and explaining like >>>> ~10 times on ML to users why /api/storagedomains/xxx >>>> doesn't have , I'm sure it should be done this way >>>> as it creates clear differentiation between root-resource >>>> and cluster-resource (shared) status. >>>> >>>>> to add this yet another confusing property. >>>> >>>> you not adding another property, you fix existent >>>> (which was incorrectly used/implemented). >>>> >>>>> >>>>> BTW - If a requirement will get from the field to add properties >>>>> we >>>>> can >>>>> do them later why add something we think is not needed. >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >>>> >>> >>> I think we got a little bit off the topic here, so if you don't >>> mind I would like to see if everyone agrees on this: >>> >>> We have at the api/networks collection these properties and their >>> possible values: >>> status - OPERATIONAL, NON_OPERATIONAL >>> display - true, false >>> >>> We (as far as I understood) agreed that these fields causea problem >>> in this context since they can be different for a given network, >>> and current representation will return the network element >>> multiple times with only difference in either one of these fields. >>> Also I understood we agreed that this is bad behaviour (even a bug) >>> and we don't want to support this anymore. >>> >>> This gives 2 choices IMHO: >>> 1. Fix the behaviour but keep the fields with some default >>> values. >>> 2. Fix the behaviour and remove these field as well, which isn't >>> really breaking an API since the behaviour was broken to begin >>> with. >>> >> >> So a summary of the thread so far: >> >> Simon, Miki Ori and me voted +1 for option #2 >> >> Michael wants to change the value of the status field to >> attach/detach >> >> Anyone else wants to vote in on this? > > I vote for fix #2. > > I think not only is leaving these fields with some defaults a mistake, but also changing their possible values is breaking the API either way, so if we already breaking the API I think removing the fields entirely is cleaner, and in future if we have request to add fields then we can model them correctly. +1 for #2 (but only for and new 3.1 props), -2 for removing (based on told above) > >> >> >>> Please comment what option seems valid (I though we were going to >>> the direction of fix #2). >>> >>> Thanks, >>> Mike >>> >> >> >> -- Michael Pasternak RedHat, ENG-Virtualization R&D From ilvovsky at redhat.com Thu Jul 5 11:38:07 2012 From: ilvovsky at redhat.com (Igor Lvovsky) Date: Thu, 05 Jul 2012 07:38:07 -0400 (EDT) Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF56EBC.7000104@redhat.com> References: <4FF56EBC.7000104@redhat.com> Message-ID: <05d001cd5aa2$99e25080$cda6f180$@com> > -----Original Message----- > From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] > On Behalf Of Livnat Peer > Sent: Thursday, July 05, 2012 1:39 PM > To: Mike Kolesnik > Cc: engine-devel; Simon Grinberg > Subject: Re: [Engine-devel] Fwd: Problem in REST API handling/displaying of > logical networks > > On 05/07/12 13:23, Mike Kolesnik wrote: > >> On 07/05/2012 12:19 PM, Livnat Peer wrote: > >>>> I'll give you one scenario and I'm sure there are lot more: > >>>>> delete all unused networks .... > >>>>> > >>> not strong enough use case in my opinion > >> > >> i do see sense in this, and based on my experience of closing ~5 bugs > >> on this for SD and explaining like > >> ~10 times on ML to users why /api/storagedomains/xxx doesn't have > >> , I'm sure it should be done this way as it creates clear > >> differentiation between root-resource and cluster-resource (shared) > >> status. > >> > >>> to add this yet another confusing property. > >> > >> you not adding another property, you fix existent (which was > >> incorrectly used/implemented). > >> > >>> > >>> BTW - If a requirement will get from the field to add properties we > >>> can do them later why add something we think is not needed. > >>> > >>> > >> > >> > >> -- > >> > >> Michael Pasternak > >> RedHat, ENG-Virtualization R&D > >> > > > > I think we got a little bit off the topic here, so if you don't mind I would > like to see if everyone agrees on this: > > > > We have at the api/networks collection these properties and their possible > values: > > status - OPERATIONAL, NON_OPERATIONAL > > display - true, false > > > > We (as far as I understood) agreed that these fields causea problem in this > context since they can be different for a given network, and current > representation will return the network element multiple times with only > difference in either one of these fields. > > Also I understood we agreed that this is bad behaviour (even a bug) and we > don't want to support this anymore. > > > > This gives 2 choices IMHO: > > 1. Fix the behaviour but keep the fields with some default values. > > 2. Fix the behaviour and remove these field as well, which isn't really > breaking an API since the behaviour was broken to begin with. > > > > So a summary of the thread so far: > > Simon, Miki Ori and me voted +1 for option #2 > > Michael wants to change the value of the status field to attach/detach > > Anyone else wants to vote in on this? > It seems like #2 is more reasonable. +1 for #2 > > > Please comment what option seems valid (I though we were going to the > direction of fix #2). > > > > Thanks, > > Mike > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From mpastern at redhat.com Sun Jul 8 11:57:44 2012 From: mpastern at redhat.com (Michael Pasternak) Date: Sun, 08 Jul 2012 14:57:44 +0300 Subject: [Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks In-Reply-To: <4FF579DF.1090507@redhat.com> References: <0d7c140c-6c7c-43af-b0fe-732abb4422cd@zmail14.collab.prod.int.phx2.redhat.com> <4FF579DF.1090507@redhat.com> Message-ID: <4FF975B8.7050608@redhat.com> On 07/05/2012 02:26 PM, Michael Pasternak wrote: > +1 for #2 (but only for and new 3.1 props), > -2 for removing (based on told above) agreed with Livnat that we may implement collection of links to clusters given network attached to instead of field. +1 -- Michael Pasternak RedHat, ENG-Virtualization R&D From ydary at redhat.com Mon Jul 9 07:26:56 2012 From: ydary at redhat.com (Yaniv Dary) Date: Mon, 09 Jul 2012 03:26:56 -0400 (EDT) Subject: [Engine-devel] Changes to engine DB DWH views. In-Reply-To: <6de92e9b-dce5-4f76-ad3d-6dbe629730a7@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <73ee5c03-5a45-42c5-acf0-de3942077aa6@zmail14.collab.prod.int.phx2.redhat.com> Good morning, I have encountered several cases in which people have broken the dwh views in the engine DB and have fixed this by modifying them themselves to make the create DB scripts to work. This causes the ETL that collects samples from the engine to stop working and a real big headache for me with blockers on builds and so on. Developers please email me, if changes you make break any of these views. Reviewers please don't approve changes to these views, if you are not sure the dwh side was handled. Have a great week! --- 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 : Yaniv D From mkolesni at redhat.com Wed Jul 11 08:57:42 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Wed, 11 Jul 2012 04:57:42 -0400 (EDT) Subject: [Engine-devel] Please review: Sync Networks enhancement In-Reply-To: <3f6fb520-4810-46f2-98b6-db36d39c54be@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks Please review this enhancement to the way network attachment on host network device is kept in sync or not. Regards, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From acathrow at redhat.com Wed Jul 11 21:35:40 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Wed, 11 Jul 2012 17:35:40 -0400 (EDT) Subject: [Engine-devel] Please review: Sync Networks enhancement In-Reply-To: Message-ID: <6300021.341.1342042552848.JavaMail.javamailuser@localhost> ----- Original Message ----- > From: "Mike Kolesnik" > To: "engine-devel" > Sent: Wednesday, July 11, 2012 4:57:42 AM > Subject: [Engine-devel] Please review: Sync Networks enhancement > http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks > Please review this enhancement to the way network attachment on host > network device is kept in sync or not. Perhaps we need a way on the host for the administrator to label a network so it is flagged by vdsm? For example on a RHEL/Fedora system you can use NM_CONTROLLED=no in the ifcfg-* files to tell network manager to ignore it. > Regards, > Mike > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From sgordon at redhat.com Thu Jul 12 13:19:32 2012 From: sgordon at redhat.com (Steve Gordon) Date: Thu, 12 Jul 2012 09:19:32 -0400 (EDT) Subject: [Engine-devel] Requirements for hosts in a non-virt cluster. In-Reply-To: Message-ID: <1a630e2c-c801-4f0c-8ccc-80a1820d50fb@zmail15.collab.prod.int.phx2.redhat.com> Hi guys, When creating a cluster with 'Enable virt service' selected when a host is later added to it we use vdsGetCaps to check that the host has the required virtualization extensions etc. What checks are performed if 'Enable virt service' is *not* checked but 'Enable gluster service' is? Steve From acathrow at redhat.com Thu Jul 12 13:24:48 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 12 Jul 2012 09:24:48 -0400 (EDT) Subject: [Engine-devel] Requirements for hosts in a non-virt cluster. In-Reply-To: <1a630e2c-c801-4f0c-8ccc-80a1820d50fb@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <23356470.746.1342099500250.JavaMail.javamailuser@localhost> ----- Original Message ----- > From: "Steve Gordon" > To: engine-devel at ovirt.org > Sent: Thursday, July 12, 2012 9:19:32 AM > Subject: [Engine-devel] Requirements for hosts in a non-virt cluster. > > Hi guys, > > When creating a cluster with 'Enable virt service' selected when a > host is later added to it we use vdsGetCaps to check that the host > has the required virtualization extensions etc. What checks are > performed if 'Enable virt service' is *not* checked but 'Enable > gluster service' is? worth checking here /usr/share/vdsm-bootstrap/vds_bootstrap.py > > Steve > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From Chris.Frantz at hp.com Thu Jul 12 16:25:09 2012 From: Chris.Frantz at hp.com (Frantz, Chris) Date: Thu, 12 Jul 2012 16:25:09 +0000 Subject: [Engine-devel] Minor trouble getting SSL enabled in JBOSS Message-ID: Greetings, I've been getting my feet wet with the ovirt-engine codebase. I've followed the instructions on the Building_oVirt_engine page and everything went rather well except for enabling SSL in JBOSS (7.1.1-Final). I had to do this, instead of what is in the wiki page: $ cd /usr/share/jboss-as $ keytool -genkey -alias jboss -keyalg RSA -keysize 1024 -keystore .keystore -validity 3650 $ chown jboss-as:jboss-as .keystore $ /usr/share/jboss-as/bin/jboss-cli.sh --connect [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:add [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=name,value=https) [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=key-alias,value=jboss) [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=password,value=PASSWORD) [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=certificate-key-file,value=/usr/share/jboss-as/.keystore) [standalone at localhost:9999 /] exit # service jboss-as restart My knowledge of jboss is extremely limited, so I don't know if this different procedure is related to a change from one jboss version to the next, a misconfiguration on my part or some other factor. Would anyone care to comment? Should I update the wiki page with this alternate procedure? Thanks, --Chris From jhernand at redhat.com Thu Jul 12 16:41:36 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Thu, 12 Jul 2012 18:41:36 +0200 Subject: [Engine-devel] Minor trouble getting SSL enabled in JBOSS In-Reply-To: References: Message-ID: <4FFEFE40.1050701@redhat.com> On 07/12/2012 06:25 PM, Frantz, Chris wrote: > Greetings, > > I've been getting my feet wet with the ovirt-engine codebase. I've followed the instructions on the Building_oVirt_engine page and everything went rather well except for enabling SSL in JBOSS (7.1.1-Final). > > I had to do this, instead of what is in the wiki page: > > $ cd /usr/share/jboss-as > $ keytool -genkey -alias jboss -keyalg RSA -keysize 1024 -keystore .keystore -validity 3650 > $ chown jboss-as:jboss-as .keystore > $ /usr/share/jboss-as/bin/jboss-cli.sh --connect > [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:add > [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=name,value=https) > [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=key-alias,value=jboss) > [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=password,value=PASSWORD) > [standalone at localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=certificate-key-file,value=/usr/share/jboss-as/.keystore) > [standalone at localhost:9999 /] exit > > # service jboss-as restart > > My knowledge of jboss is extremely limited, so I don't know if this different procedure is related to a change from one jboss version to the next, a misconfiguration on my part or some other factor. > > Would anyone care to comment? Should I update the wiki page with this alternate procedure? The procedure in that wiki page worked with a previous version of JBoss AS7, it is not up to date, as you discovered. I am preparing an updated version of that page here: http://www.ovirt.org/wiki/Building_Engine_Draft I would appreciate if you can check and maybe amend it. Then, if there are no objections, we could maybe replace the existing page with this one. -- 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 iheim at redhat.com Thu Jul 12 19:49:30 2012 From: iheim at redhat.com (Itamar Heim) Date: Thu, 12 Jul 2012 22:49:30 +0300 Subject: [Engine-devel] Requirements for hosts in a non-virt cluster. In-Reply-To: <1a630e2c-c801-4f0c-8ccc-80a1820d50fb@zmail15.collab.prod.int.phx2.redhat.com> References: <1a630e2c-c801-4f0c-8ccc-80a1820d50fb@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4FFF2A4A.3010001@redhat.com> On 07/12/2012 04:19 PM, Steve Gordon wrote: > Hi guys, > > When creating a cluster with 'Enable virt service' selected when a host is later added to it we use vdsGetCaps to check that the host has the required virtualization extensions etc. What checks are performed if 'Enable virt service' is *not* checked but 'Enable gluster service' is? iirc, same checks except the kvm / VT is enabled in host and bios. gluster still need to add bootstrap code to install and configure the gluster rpms, ip tables, etc. > > Steve > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lpeer at redhat.com Sun Jul 15 06:29:19 2012 From: lpeer at redhat.com (Livnat Peer) Date: Sun, 15 Jul 2012 09:29:19 +0300 Subject: [Engine-devel] Requirements for hosts in a non-virt cluster. In-Reply-To: <4FFF2A4A.3010001@redhat.com> References: <1a630e2c-c801-4f0c-8ccc-80a1820d50fb@zmail15.collab.prod.int.phx2.redhat.com> <4FFF2A4A.3010001@redhat.com> Message-ID: <5002633F.9030100@redhat.com> On 12/07/12 22:49, Itamar Heim wrote: > On 07/12/2012 04:19 PM, Steve Gordon wrote: >> Hi guys, >> >> When creating a cluster with 'Enable virt service' selected when a >> host is later added to it we use vdsGetCaps to check that the host has >> the required virtualization extensions etc. What checks are performed >> if 'Enable virt service' is *not* checked but 'Enable gluster service' >> is? > > iirc, same checks except the kvm / VT is enabled in host and bios. > gluster still need to add bootstrap code to install and configure the > gluster rpms, ip tables, etc. > Adding to the above - from a quick look we have 3 phases - 1. Networking validation - shared for virt and gluster (network topology that is required by the cluster is enforced) 2. processSoftwareCapabilities - empty implementation for gluster (GlusterMonitoringStrategy) 3. processHardwareCapabilities - empty implementation for gluster (GlusterMonitoringStrategy) Livnat >> >> Steve >> _______________________________________________ >> 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 Jul 15 06:33:40 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Sun, 15 Jul 2012 02:33:40 -0400 (EDT) Subject: [Engine-devel] Please review: Sync Networks enhancement In-Reply-To: <6300021.341.1342042552848.JavaMail.javamailuser@localhost> Message-ID: <096c282a-88df-46a9-be51-5c96c94e2326@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > ----- Original Message ----- > > > From: "Mike Kolesnik" > > To: "engine-devel" > > Sent: Wednesday, July 11, 2012 4:57:42 AM > > Subject: [Engine-devel] Please review: Sync Networks enhancement > > > http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks > > > Please review this enhancement to the way network attachment on > > host > > network device is kept in sync or not. > > Perhaps we need a way on the host for the administrator to label a > network so it is flagged by vdsm? > For example on a RHEL/Fedora system you can use NM_CONTROLLED=no in > the ifcfg-* files to tell network manager to ignore it. > > Can you please elaborate on this? > > > > Regards, > > Mike > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > From mkenneth at redhat.com Sun Jul 15 08:14:30 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Sun, 15 Jul 2012 04:14:30 -0400 (EDT) Subject: [Engine-devel] Please review: Sync Networks enhancement In-Reply-To: <096c282a-88df-46a9-be51-5c96c94e2326@zmail14.collab.prod.int.phx2.redhat.com> Message-ID: <14009391.153.1342340067646.JavaMail.mkenneth@mkenneth.csb> I would like to see an alert notification when the host is Installed/added, and not only on the network dialog. There should be a message on the audit log for sure, alert ? ----- Original Message ----- > ----- Original Message ----- > > > > ----- Original Message ----- > > > > > From: "Mike Kolesnik" > > > To: "engine-devel" > > > Sent: Wednesday, July 11, 2012 4:57:42 AM > > > Subject: [Engine-devel] Please review: Sync Networks enhancement > > > > > http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks > > > > > Please review this enhancement to the way network attachment on > > > host > > > network device is kept in sync or not. > > > > Perhaps we need a way on the host for the administrator to label a > > network so it is flagged by vdsm? > > For example on a RHEL/Fedora system you can use NM_CONTROLLED=no in > > the ifcfg-* files to tell network manager to ignore it. > > > > > > Can you please elaborate on this? > > > > > > > > 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 > From abaron at redhat.com Sun Jul 15 08:53:04 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 15 Jul 2012 04:53:04 -0400 (EDT) Subject: [Engine-devel] Getting rid of arch@ovirt.org? In-Reply-To: <09b48d98-8055-466a-9cbb-0134f29e6878@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> Hi all, Sorry for cross-posting, but in this case I think it's relevant. The original idea was that every time we wish to discuss a new cross-component feature we should do it over arch list. However, it would appear that de-facto usually engine-devel and vdsm-devel are being used (cross posted). Currently engine-devel has 211 subscribers, arch has 160 and vdsm-devel has 128 so from this perspective again, arch seems less relevant. I propose we ditch arch and keep the other 2 mailing lists. I'm not sure whether new cross-component features should be discussed solely on engine-devel or cross-posted (there are probably people who wouldn't care about engine side but would still like to know about such changes). Thoughts? Regards, Ayal. From lpeer at redhat.com Sun Jul 15 08:54:34 2012 From: lpeer at redhat.com (Livnat Peer) Date: Sun, 15 Jul 2012 11:54:34 +0300 Subject: [Engine-devel] Please review: Sync Networks enhancement In-Reply-To: <14009391.153.1342340067646.JavaMail.mkenneth@mkenneth.csb> References: <14009391.153.1342340067646.JavaMail.mkenneth@mkenneth.csb> Message-ID: <5002854A.2000101@redhat.com> On 15/07/12 11:14, Miki Kenneth wrote: > I would like to see an alert notification when the host is Installed/added, and not only on the network dialog. > There should be a message on the audit log for sure, alert ? > > Miki, Are you talking about issuing an audit log message when installing a host ( / changing the host DC ) if there is a mismatch between the logical network definition and the actual host network configuration? Thanks, Livnat > > > ----- Original Message ----- >> ----- Original Message ----- >>> >>> ----- Original Message ----- >>> >>>> From: "Mike Kolesnik" >>>> To: "engine-devel" >>>> Sent: Wednesday, July 11, 2012 4:57:42 AM >>>> Subject: [Engine-devel] Please review: Sync Networks enhancement >>> >>>> http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks >>> >>>> Please review this enhancement to the way network attachment on >>>> host >>>> network device is kept in sync or not. >>> >>> Perhaps we need a way on the host for the administrator to label a >>> network so it is flagged by vdsm? >>> For example on a RHEL/Fedora system you can use NM_CONTROLLED=no in >>> the ifcfg-* files to tell network manager to ignore it. >>> >>> >> >> Can you please elaborate on this? >> >>> >>> >>>> 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 > From mkenneth at redhat.com Sun Jul 15 09:03:50 2012 From: mkenneth at redhat.com (Miki Kenneth) Date: Sun, 15 Jul 2012 05:03:50 -0400 (EDT) Subject: [Engine-devel] Please review: Sync Networks enhancement In-Reply-To: <5002854A.2000101@redhat.com> Message-ID: <28245288.176.1342343026853.JavaMail.mkenneth@mkenneth.csb> ----- Original Message ----- > On 15/07/12 11:14, Miki Kenneth wrote: > > I would like to see an alert notification when the host is > > Installed/added, and not only on the network dialog. > > There should be a message on the audit log for sure, alert ? > > > > > > Miki, > > Are you talking about issuing an audit log message when installing a > host ( / changing the host DC ) if there is a mismatch between the > logical network definition and the actual host network configuration? yes, that is what i was referring to. > > Thanks, Livnat > > > > > > > > ----- Original Message ----- > >> ----- Original Message ----- > >>> > >>> ----- Original Message ----- > >>> > >>>> From: "Mike Kolesnik" > >>>> To: "engine-devel" > >>>> Sent: Wednesday, July 11, 2012 4:57:42 AM > >>>> Subject: [Engine-devel] Please review: Sync Networks enhancement > >>> > >>>> http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks > >>> > >>>> Please review this enhancement to the way network attachment on > >>>> host > >>>> network device is kept in sync or not. > >>> > >>> Perhaps we need a way on the host for the administrator to label > >>> a > >>> network so it is flagged by vdsm? > >>> For example on a RHEL/Fedora system you can use NM_CONTROLLED=no > >>> in > >>> the ifcfg-* files to tell network manager to ignore it. > >>> > >>> > >> > >> Can you please elaborate on this? > >> > >>> > >>> > >>>> 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 > > > > > From lpeer at redhat.com Sun Jul 15 09:05:27 2012 From: lpeer at redhat.com (Livnat Peer) Date: Sun, 15 Jul 2012 12:05:27 +0300 Subject: [Engine-devel] Please review: Sync Networks enhancement In-Reply-To: <28245288.176.1342343026853.JavaMail.mkenneth@mkenneth.csb> References: <28245288.176.1342343026853.JavaMail.mkenneth@mkenneth.csb> Message-ID: <500287D7.1070606@redhat.com> On 15/07/12 12:03, Miki Kenneth wrote: > > > ----- Original Message ----- >> On 15/07/12 11:14, Miki Kenneth wrote: >>> I would like to see an alert notification when the host is >>> Installed/added, and not only on the network dialog. >>> There should be a message on the audit log for sure, alert ? >>> >>> >> >> Miki, >> >> Are you talking about issuing an audit log message when installing a >> host ( / changing the host DC ) if there is a mismatch between the >> logical network definition and the actual host network configuration? > yes, that is what i was referring to. Mike - can you please add that to the wiki. >> >> Thanks, Livnat >> >> >>> >>> >>> ----- Original Message ----- >>>> ----- Original Message ----- >>>>> >>>>> ----- Original Message ----- >>>>> >>>>>> From: "Mike Kolesnik" >>>>>> To: "engine-devel" >>>>>> Sent: Wednesday, July 11, 2012 4:57:42 AM >>>>>> Subject: [Engine-devel] Please review: Sync Networks enhancement >>>>> >>>>>> http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks >>>>> >>>>>> Please review this enhancement to the way network attachment on >>>>>> host >>>>>> network device is kept in sync or not. >>>>> >>>>> Perhaps we need a way on the host for the administrator to label >>>>> a >>>>> network so it is flagged by vdsm? >>>>> For example on a RHEL/Fedora system you can use NM_CONTROLLED=no >>>>> in >>>>> the ifcfg-* files to tell network manager to ignore it. >>>>> >>>>> >>>> >>>> Can you please elaborate on this? >>>> >>>>> >>>>> >>>>>> 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 >>> >> >> >> From mkolesni at redhat.com Sun Jul 15 12:56:54 2012 From: mkolesni at redhat.com (Mike Kolesnik) Date: Sun, 15 Jul 2012 08:56:54 -0400 (EDT) Subject: [Engine-devel] Please review: Sync Networks enhancement In-Reply-To: <500287D7.1070606@redhat.com> Message-ID: <662e1ab6-2701-437d-853d-a7fe17688a75@zmail14.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 15/07/12 12:03, Miki Kenneth wrote: > > > > > > ----- Original Message ----- > >> On 15/07/12 11:14, Miki Kenneth wrote: > >>> I would like to see an alert notification when the host is > >>> Installed/added, and not only on the network dialog. > >>> There should be a message on the audit log for sure, alert ? > >>> > >>> > >> > >> Miki, > >> > >> Are you talking about issuing an audit log message when installing > >> a > >> host ( / changing the host DC ) if there is a mismatch between the > >> logical network definition and the actual host network > >> configuration? > > yes, that is what i was referring to. > > > Mike - can you please add that to the wiki. Yes, added in the Engine section. > > > > > >> > >> Thanks, Livnat > >> > >> > >>> > >>> > >>> ----- Original Message ----- > >>>> ----- Original Message ----- > >>>>> > >>>>> ----- Original Message ----- > >>>>> > >>>>>> From: "Mike Kolesnik" > >>>>>> To: "engine-devel" > >>>>>> Sent: Wednesday, July 11, 2012 4:57:42 AM > >>>>>> Subject: [Engine-devel] Please review: Sync Networks > >>>>>> enhancement > >>>>> > >>>>>> http://www.ovirt.org/wiki/SetupNetworks_SyncNetworks > >>>>> > >>>>>> Please review this enhancement to the way network attachment > >>>>>> on > >>>>>> host > >>>>>> network device is kept in sync or not. > >>>>> > >>>>> Perhaps we need a way on the host for the administrator to > >>>>> label > >>>>> a > >>>>> network so it is flagged by vdsm? > >>>>> For example on a RHEL/Fedora system you can use > >>>>> NM_CONTROLLED=no > >>>>> in > >>>>> the ifcfg-* files to tell network manager to ignore it. > >>>>> > >>>>> > >>>> > >>>> Can you please elaborate on this? > >>>> > >>>>> > >>>>> > >>>>>> 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 > >>> > >> > >> > >> > > > From agl at us.ibm.com Sun Jul 15 14:00:38 2012 From: agl at us.ibm.com (Adam Litke) Date: Sun, 15 Jul 2012 09:00:38 -0500 Subject: [Engine-devel] [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> References: <09b48d98-8055-466a-9cbb-0134f29e6878@zmail13.collab.prod.int.phx2.redhat.com> <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <20120715140038.GH2937@aglitke> On Sun, Jul 15, 2012 at 04:53:04AM -0400, Ayal Baron wrote: > Hi all, > > Sorry for cross-posting, but in this case I think it's relevant. > > The original idea was that every time we wish to discuss a new cross-component feature we should do it over arch list. However, it would appear that de-facto usually engine-devel and vdsm-devel are being used (cross posted). > Currently engine-devel has 211 subscribers, arch has 160 and vdsm-devel has 128 so from this perspective again, arch seems less relevant. > I propose we ditch arch and keep the other 2 mailing lists. > I'm not sure whether new cross-component features should be discussed solely on engine-devel or cross-posted (there are probably people who wouldn't care about engine side but would still like to know about such changes). +1 to ditching arch. I would still prefer that cross-component features cross-post to vdsm-devel and engine-devel. My current focus is on vdsm and the traffic level on that list is currently far more manageable than that of engine-devel. -- Adam Litke IBM Linux Technology Center From abaron at redhat.com Sun Jul 15 14:16:11 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 15 Jul 2012 10:16:11 -0400 (EDT) Subject: [Engine-devel] [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <20120715140038.GH2937@aglitke> Message-ID: <9f4325ea-d1df-4481-919e-f1e7270d9129@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On Sun, Jul 15, 2012 at 04:53:04AM -0400, Ayal Baron wrote: > > Hi all, > > > > Sorry for cross-posting, but in this case I think it's relevant. > > > > The original idea was that every time we wish to discuss a new > > cross-component feature we should do it over arch list. However, > > it would appear that de-facto usually engine-devel and vdsm-devel > > are being used (cross posted). > > Currently engine-devel has 211 subscribers, arch has 160 and > > vdsm-devel has 128 so from this perspective again, arch seems less > > relevant. > > I propose we ditch arch and keep the other 2 mailing lists. > > I'm not sure whether new cross-component features should be > > discussed solely on engine-devel or cross-posted (there are > > probably people who wouldn't care about engine side but would > > still like to know about such changes). > > +1 to ditching arch. I would still prefer that cross-component > features > cross-post to vdsm-devel and engine-devel. My current focus is on > vdsm and the > traffic level on that list is currently far more manageable than that > of > engine-devel. That's my sentiment as well (plus I have a rule to drop duplicates so I don't care much about it ;) > > -- > Adam Litke > IBM Linux Technology Center > > From kwade at redhat.com Sun Jul 15 19:37:06 2012 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Sun, 15 Jul 2012 12:37:06 -0700 Subject: [Engine-devel] Getting rid of arch@ovirt.org? In-Reply-To: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> References: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <50031BE2.4010507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/15/2012 01:53 AM, Ayal Baron wrote: > Hi all, > > Sorry for cross-posting, but in this case I think it's relevant. > > The original idea was that every time we wish to discuss a new > cross-component feature we should do it over arch list. However, it > would appear that de-facto usually engine-devel and vdsm-devel are > being used (cross posted). Currently engine-devel has 211 > subscribers, arch has 160 and vdsm-devel has 128 so from this > perspective again, arch seems less relevant. I propose we ditch > arch and keep the other 2 mailing lists. I'm not sure whether new > cross-component features should be discussed solely on engine-devel > or cross-posted (there are probably people who wouldn't care about > engine side but would still like to know about such changes). > > Thoughts? - -1 I don't normally read engine-devel and vdsm-devel, so I hadn't noticed that discussions I would expect to be on arch@ are not happening here. I'm probably not the only person in that situation. If this project were 100% about Engine and VDSM, then I could understand your reasoning. But we've already added a few new incubating projects, we have subsystem teams such as documentation and infrastructure, and we all need a single location where we know we can reach *all* contributors to this project. If we try to force all that discussion on to engine-devel, not everyone would be interested. There is enough on engine-devel that is not general interest that it would become noise (as it has for me, so I filter it) or people would drop it all together. Perhaps what we need to do is have the discipline to cross-post *all* general interest discussions from the project mailing list back to arch@? Enforce the rule that decisions that affect the whole project have to be ratified on arch@ instead of whatever project list the discussions started on? Strongly suggest that all contributors be on arch@ and announce@ as a minimum? I'm sure there are open source projects that don't have a general interest contributor list, preferring to run all that discussion on a technical-focused list. But I don't recommend it. It's the kind of thing that repels contributors who don't want to sort through deep developer discussions just to find out what is generally going on. - - Karsten - -- Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQAxvi2ZIOBq0ODEERAlaXAKDMCwHjZzS/mtWkzvYt+Px+iEhl/wCZASvN AYHTXhHYq33yJMebr4bmijE= =iBdY -----END PGP SIGNATURE----- From jbrooks at redhat.com Sun Jul 15 19:41:43 2012 From: jbrooks at redhat.com (Jason Brooks) Date: Sun, 15 Jul 2012 12:41:43 -0700 Subject: [Engine-devel] Getting rid of arch@ovirt.org? In-Reply-To: <50031BE2.4010507@redhat.com> References: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> <50031BE2.4010507@redhat.com> Message-ID: <50031CF7.80601@redhat.com> On 07/15/2012 12:37 PM, Karsten 'quaid' Wade wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/15/2012 01:53 AM, Ayal Baron wrote: >> Hi all, >> >> Sorry for cross-posting, but in this case I think it's relevant. >> >> The original idea was that every time we wish to discuss a new >> cross-component feature we should do it over arch list. However, it >> would appear that de-facto usually engine-devel and vdsm-devel are >> being used (cross posted). Currently engine-devel has 211 >> subscribers, arch has 160 and vdsm-devel has 128 so from this >> perspective again, arch seems less relevant. I propose we ditch >> arch and keep the other 2 mailing lists. I'm not sure whether new >> cross-component features should be discussed solely on engine-devel >> or cross-posted (there are probably people who wouldn't care about >> engine side but would still like to know about such changes). >> >> Thoughts? > > - -1 I've been understanding @arch as sort of a catch all list for many project types that aren't -devel or -user -- infra and marketing issues, for instance, but maybe this misses the initial intention of @arch. I don't know if more cross-posting is the answer -- I'm subbed to all the ovirt lists and I'm seeing a ton of duplication, which I'm finding annoying. Just this morning, in fact, I was looking into deduping addons for thunderbird. > > I don't normally read engine-devel and vdsm-devel, so I hadn't noticed > that discussions I would expect to be on arch@ are not happening here. > I'm probably not the only person in that situation. > > If this project were 100% about Engine and VDSM, then I could > understand your reasoning. But we've already added a few new > incubating projects, we have subsystem teams such as documentation and > infrastructure, and we all need a single location where we know we can > reach *all* contributors to this project. > > If we try to force all that discussion on to engine-devel, not > everyone would be interested. There is enough on engine-devel that is > not general interest that it would become noise (as it has for me, so > I filter it) or people would drop it all together. > > Perhaps what we need to do is have the discipline to cross-post *all* > general interest discussions from the project mailing list back to > arch@? Enforce the rule that decisions that affect the whole project > have to be ratified on arch@ instead of whatever project list the > discussions started on? Strongly suggest that all contributors be on > arch@ and announce@ as a minimum? > > I'm sure there are open source projects that don't have a general > interest contributor list, preferring to run all that discussion on a > technical-focused list. But I don't recommend it. It's the kind of > thing that repels contributors who don't want to sort through deep > developer discussions just to find out what is generally going on. > > - - Karsten > - -- > Karsten 'quaid' Wade, Sr. Analyst - Community Growth > http://TheOpenSourceWay.org .^\ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFQAxvi2ZIOBq0ODEERAlaXAKDMCwHjZzS/mtWkzvYt+Px+iEhl/wCZASvN > AYHTXhHYq33yJMebr4bmijE= > =iBdY > -----END PGP SIGNATURE----- > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- Jason Brooks Media & Communications Open Source and Standards @ Red Hat identi.ca/jasonbrooks twitter.com/jasonbrooks From abaron at redhat.com Sun Jul 15 19:59:45 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 15 Jul 2012 15:59:45 -0400 (EDT) Subject: [Engine-devel] [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <50031BE2.4010507@redhat.com> Message-ID: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/15/2012 01:53 AM, Ayal Baron wrote: > > Hi all, > > > > Sorry for cross-posting, but in this case I think it's relevant. > > > > The original idea was that every time we wish to discuss a new > > cross-component feature we should do it over arch list. However, it > > would appear that de-facto usually engine-devel and vdsm-devel are > > being used (cross posted). Currently engine-devel has 211 > > subscribers, arch has 160 and vdsm-devel has 128 so from this > > perspective again, arch seems less relevant. I propose we ditch > > arch and keep the other 2 mailing lists. I'm not sure whether new > > cross-component features should be discussed solely on engine-devel > > or cross-posted (there are probably people who wouldn't care about > > engine side but would still like to know about such changes). > > > > Thoughts? > > - -1 > > I don't normally read engine-devel and vdsm-devel, so I hadn't > noticed > that discussions I would expect to be on arch@ are not happening > here. > I'm probably not the only person in that situation. > > If this project were 100% about Engine and VDSM, then I could > understand your reasoning. But we've already added a few new > incubating projects, we have subsystem teams such as documentation > and > infrastructure, and we all need a single location where we know we > can > reach *all* contributors to this project. > > If we try to force all that discussion on to engine-devel, not > everyone would be interested. There is enough on engine-devel that is > not general interest that it would become noise (as it has for me, so > I filter it) or people would drop it all together. > > Perhaps what we need to do is have the discipline to cross-post *all* > general interest discussions from the project mailing list back to > arch@? Enforce the rule that decisions that affect the whole project > have to be ratified on arch@ instead of whatever project list the > discussions started on? Strongly suggest that all contributors be on > arch@ and announce@ as a minimum? I find that anything that should go on arch would interest anyone on the devel lists (as it is about new features, design, etc) so I believe that arch should have at least everyone on engine-devel and vdsm-devel. However, right now this is not the case as is evident by number of subs to each list (e.g. I haven't compared to see if everyone on arch is on engine). So imo something needs to be done. I'm fine with keeping arch, but as you said, that means we need to enforce it to be *the* list for feature discussions and I'm not exactly sure how you'd go about doing that. > > I'm sure there are open source projects that don't have a general > interest contributor list, preferring to run all that discussion on a > technical-focused list. But I don't recommend it. It's the kind of > thing that repels contributors who don't want to sort through deep > developer discussions just to find out what is generally going on. > > - - Karsten > - -- > Karsten 'quaid' Wade, Sr. Analyst - Community Growth > http://TheOpenSourceWay.org .^\ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iD8DBQFQAxvi2ZIOBq0ODEERAlaXAKDMCwHjZzS/mtWkzvYt+Px+iEhl/wCZASvN > AYHTXhHYq33yJMebr4bmijE= > =iBdY > -----END PGP SIGNATURE----- > _______________________________________________ > vdsm-devel mailing list > vdsm-devel at lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/vdsm-devel > From robert at middleswarth.net Sun Jul 15 22:46:03 2012 From: robert at middleswarth.net (Robert Middleswarth) Date: Sun, 15 Jul 2012 18:46:03 -0400 Subject: [Engine-devel] Getting rid of arch@ovirt.org? In-Reply-To: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <5003482B.60406@middleswarth.net> On 07/15/2012 03:59 PM, Ayal Baron wrote: > > ----- Original Message ----- >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>> Hi all, >>> >>> Sorry for cross-posting, but in this case I think it's relevant. >>> >>> The original idea was that every time we wish to discuss a new >>> cross-component feature we should do it over arch list. However, it >>> would appear that de-facto usually engine-devel and vdsm-devel are >>> being used (cross posted). Currently engine-devel has 211 >>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>> perspective again, arch seems less relevant. I propose we ditch >>> arch and keep the other 2 mailing lists. I'm not sure whether new >>> cross-component features should be discussed solely on engine-devel >>> or cross-posted (there are probably people who wouldn't care about >>> engine side but would still like to know about such changes). >>> >>> Thoughts? >> - -1 >> >> I don't normally read engine-devel and vdsm-devel, so I hadn't >> noticed >> that discussions I would expect to be on arch@ are not happening >> here. >> I'm probably not the only person in that situation. >> >> If this project were 100% about Engine and VDSM, then I could >> understand your reasoning. But we've already added a few new >> incubating projects, we have subsystem teams such as documentation >> and >> infrastructure, and we all need a single location where we know we >> can >> reach *all* contributors to this project. >> >> If we try to force all that discussion on to engine-devel, not >> everyone would be interested. There is enough on engine-devel that is >> not general interest that it would become noise (as it has for me, so >> I filter it) or people would drop it all together. >> >> Perhaps what we need to do is have the discipline to cross-post *all* >> general interest discussions from the project mailing list back to >> arch@? Enforce the rule that decisions that affect the whole project >> have to be ratified on arch@ instead of whatever project list the >> discussions started on? Strongly suggest that all contributors be on >> arch@ and announce@ as a minimum? > I find that anything that should go on arch would interest anyone on the devel lists (as it is about new features, design, etc) so I believe that arch should have at least everyone on engine-devel and vdsm-devel. > However, right now this is not the case as is evident by number of subs to each list (e.g. I haven't compared to see if everyone on arch is on engine). > So imo something needs to be done. > I'm fine with keeping arch, but as you said, that means we need to enforce it to be *the* list for feature discussions and I'm not exactly sure how you'd go about doing that. Maybe arch needs renamed to make it clear what if is for? Maybe something simple like ovirt-devel to make it clear it is for generally ovirt development? Thanks Robert >> I'm sure there are open source projects that don't have a general >> interest contributor list, preferring to run all that discussion on a >> technical-focused list. But I don't recommend it. It's the kind of >> thing that repels contributors who don't want to sort through deep >> developer discussions just to find out what is generally going on. >> >> - - Karsten >> - -- >> Karsten 'quaid' Wade, Sr. Analyst - Community Growth >> http://TheOpenSourceWay.org .^\ http://community.redhat.com >> @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iD8DBQFQAxvi2ZIOBq0ODEERAlaXAKDMCwHjZzS/mtWkzvYt+Px+iEhl/wCZASvN >> AYHTXhHYq33yJMebr4bmijE= >> =iBdY >> -----END PGP SIGNATURE----- >> _______________________________________________ >> vdsm-devel mailing list >> vdsm-devel at lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/vdsm-devel >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Mon Jul 16 06:41:51 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 16 Jul 2012 09:41:51 +0300 Subject: [Engine-devel] [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003482B.60406@middleswarth.net> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> Message-ID: <5003B7AF.8020409@redhat.com> On 07/16/2012 01:46 AM, Robert Middleswarth wrote: > On 07/15/2012 03:59 PM, Ayal Baron wrote: >> >> ----- Original Message ----- >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>> Hi all, >>>> >>>> Sorry for cross-posting, but in this case I think it's relevant. >>>> >>>> The original idea was that every time we wish to discuss a new >>>> cross-component feature we should do it over arch list. However, it >>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>> being used (cross posted). Currently engine-devel has 211 >>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>> perspective again, arch seems less relevant. I propose we ditch >>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>> cross-component features should be discussed solely on engine-devel >>>> or cross-posted (there are probably people who wouldn't care about >>>> engine side but would still like to know about such changes). >>>> >>>> Thoughts? >>> - -1 >>> >>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>> noticed >>> that discussions I would expect to be on arch@ are not happening >>> here. >>> I'm probably not the only person in that situation. >>> >>> If this project were 100% about Engine and VDSM, then I could >>> understand your reasoning. But we've already added a few new >>> incubating projects, we have subsystem teams such as documentation >>> and >>> infrastructure, and we all need a single location where we know we >>> can >>> reach *all* contributors to this project. >>> >>> If we try to force all that discussion on to engine-devel, not >>> everyone would be interested. There is enough on engine-devel that is >>> not general interest that it would become noise (as it has for me, so >>> I filter it) or people would drop it all together. >>> >>> Perhaps what we need to do is have the discipline to cross-post *all* >>> general interest discussions from the project mailing list back to >>> arch@? Enforce the rule that decisions that affect the whole project >>> have to be ratified on arch@ instead of whatever project list the >>> discussions started on? Strongly suggest that all contributors be on >>> arch@ and announce@ as a minimum? >> I find that anything that should go on arch would interest anyone on >> the devel lists (as it is about new features, design, etc) so I >> believe that arch should have at least everyone on engine-devel and >> vdsm-devel. >> However, right now this is not the case as is evident by number of >> subs to each list (e.g. I haven't compared to see if everyone on arch >> is on engine). >> So imo something needs to be done. >> I'm fine with keeping arch, but as you said, that means we need to >> enforce it to be *the* list for feature discussions and I'm not >> exactly sure how you'd go about doing that. > Maybe arch needs renamed to make it clear what if is for? > > Maybe something simple like ovirt-devel to make it clear it is for > generally ovirt development? we can simply make it arch include the other mailing lists, so sending to arch would be sending to all other mailing lists. wouldn't resolve the dupes, but will resolve need of everyone to subscribe to it as well. (for dupes i also use a mail filter to delete emails arriving from engine-devel and cc other mailing list, etc. From lpeer at redhat.com Mon Jul 16 06:56:27 2012 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 16 Jul 2012 09:56:27 +0300 Subject: [Engine-devel] [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003B7AF.8020409@redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> <5003B7AF.8020409@redhat.com> Message-ID: <5003BB1B.8040002@redhat.com> On 16/07/12 09:41, Itamar Heim wrote: > On 07/16/2012 01:46 AM, Robert Middleswarth wrote: >> On 07/15/2012 03:59 PM, Ayal Baron wrote: >>> >>> ----- Original Message ----- >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>>> Hi all, >>>>> >>>>> Sorry for cross-posting, but in this case I think it's relevant. >>>>> >>>>> The original idea was that every time we wish to discuss a new >>>>> cross-component feature we should do it over arch list. However, it >>>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>>> being used (cross posted). Currently engine-devel has 211 >>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>>> perspective again, arch seems less relevant. I propose we ditch >>>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>>> cross-component features should be discussed solely on engine-devel >>>>> or cross-posted (there are probably people who wouldn't care about >>>>> engine side but would still like to know about such changes). >>>>> >>>>> Thoughts? >>>> - -1 >>>> >>>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>>> noticed >>>> that discussions I would expect to be on arch@ are not happening >>>> here. >>>> I'm probably not the only person in that situation. >>>> >>>> If this project were 100% about Engine and VDSM, then I could >>>> understand your reasoning. But we've already added a few new >>>> incubating projects, we have subsystem teams such as documentation >>>> and >>>> infrastructure, and we all need a single location where we know we >>>> can >>>> reach *all* contributors to this project. >>>> >>>> If we try to force all that discussion on to engine-devel, not >>>> everyone would be interested. There is enough on engine-devel that is >>>> not general interest that it would become noise (as it has for me, so >>>> I filter it) or people would drop it all together. >>>> >>>> Perhaps what we need to do is have the discipline to cross-post *all* >>>> general interest discussions from the project mailing list back to >>>> arch@? Enforce the rule that decisions that affect the whole project >>>> have to be ratified on arch@ instead of whatever project list the >>>> discussions started on? Strongly suggest that all contributors be on >>>> arch@ and announce@ as a minimum? >>> I find that anything that should go on arch would interest anyone on >>> the devel lists (as it is about new features, design, etc) so I >>> believe that arch should have at least everyone on engine-devel and >>> vdsm-devel. >>> However, right now this is not the case as is evident by number of >>> subs to each list (e.g. I haven't compared to see if everyone on arch >>> is on engine). >>> So imo something needs to be done. >>> I'm fine with keeping arch, but as you said, that means we need to >>> enforce it to be *the* list for feature discussions and I'm not >>> exactly sure how you'd go about doing that. >> Maybe arch needs renamed to make it clear what if is for? >> >> Maybe something simple like ovirt-devel to make it clear it is for >> generally ovirt development? > > we can simply make it arch include the other mailing lists, so sending > to arch would be sending to all other mailing lists. What would happen if someone reply on the engine-list to a mail originally sent to arch? wouldn't we end-up starting a thread on arch and then loosing it to one of the other lists? > wouldn't resolve the dupes, but will resolve need of everyone to > subscribe to it as well. > (for dupes i also use a mail filter to delete emails arriving from > engine-devel and cc other mailing list, etc. > _______________________________________________ > Arch mailing list > Arch at ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch From iheim at redhat.com Mon Jul 16 07:01:26 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 16 Jul 2012 10:01:26 +0300 Subject: [Engine-devel] [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003BB1B.8040002@redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> <5003B7AF.8020409@redhat.com> <5003BB1B.8040002@redhat.com> Message-ID: <5003BC46.9040903@redhat.com> On 07/16/2012 09:56 AM, Livnat Peer wrote: > On 16/07/12 09:41, Itamar Heim wrote: >> On 07/16/2012 01:46 AM, Robert Middleswarth wrote: >>> On 07/15/2012 03:59 PM, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>>>> Hi all, >>>>>> >>>>>> Sorry for cross-posting, but in this case I think it's relevant. >>>>>> >>>>>> The original idea was that every time we wish to discuss a new >>>>>> cross-component feature we should do it over arch list. However, it >>>>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>>>> being used (cross posted). Currently engine-devel has 211 >>>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>>>> perspective again, arch seems less relevant. I propose we ditch >>>>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>>>> cross-component features should be discussed solely on engine-devel >>>>>> or cross-posted (there are probably people who wouldn't care about >>>>>> engine side but would still like to know about such changes). >>>>>> >>>>>> Thoughts? >>>>> - -1 >>>>> >>>>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>>>> noticed >>>>> that discussions I would expect to be on arch@ are not happening >>>>> here. >>>>> I'm probably not the only person in that situation. >>>>> >>>>> If this project were 100% about Engine and VDSM, then I could >>>>> understand your reasoning. But we've already added a few new >>>>> incubating projects, we have subsystem teams such as documentation >>>>> and >>>>> infrastructure, and we all need a single location where we know we >>>>> can >>>>> reach *all* contributors to this project. >>>>> >>>>> If we try to force all that discussion on to engine-devel, not >>>>> everyone would be interested. There is enough on engine-devel that is >>>>> not general interest that it would become noise (as it has for me, so >>>>> I filter it) or people would drop it all together. >>>>> >>>>> Perhaps what we need to do is have the discipline to cross-post *all* >>>>> general interest discussions from the project mailing list back to >>>>> arch@? Enforce the rule that decisions that affect the whole project >>>>> have to be ratified on arch@ instead of whatever project list the >>>>> discussions started on? Strongly suggest that all contributors be on >>>>> arch@ and announce@ as a minimum? >>>> I find that anything that should go on arch would interest anyone on >>>> the devel lists (as it is about new features, design, etc) so I >>>> believe that arch should have at least everyone on engine-devel and >>>> vdsm-devel. >>>> However, right now this is not the case as is evident by number of >>>> subs to each list (e.g. I haven't compared to see if everyone on arch >>>> is on engine). >>>> So imo something needs to be done. >>>> I'm fine with keeping arch, but as you said, that means we need to >>>> enforce it to be *the* list for feature discussions and I'm not >>>> exactly sure how you'd go about doing that. >>> Maybe arch needs renamed to make it clear what if is for? >>> >>> Maybe something simple like ovirt-devel to make it clear it is for >>> generally ovirt development? >> >> we can simply make it arch include the other mailing lists, so sending >> to arch would be sending to all other mailing lists. > > What would happen if someone reply on the engine-list to a mail > originally sent to arch? > > wouldn't we end-up starting a thread on arch and then loosing it to one > of the other lists? reply-to is not set to reply-to-list, rather to original sender/cc list, so shouldn't be an issue > > >> wouldn't resolve the dupes, but will resolve need of everyone to >> subscribe to it as well. >> (for dupes i also use a mail filter to delete emails arriving from >> engine-devel and cc other mailing list, etc. >> _______________________________________________ >> Arch mailing list >> Arch at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/arch > > From lpeer at redhat.com Mon Jul 16 07:55:20 2012 From: lpeer at redhat.com (Livnat Peer) Date: Mon, 16 Jul 2012 10:55:20 +0300 Subject: [Engine-devel] [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003BC46.9040903@redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> <5003B7AF.8020409@redhat.com> <5003BB1B.8040002@redhat.com> <5003BC46.9040903@redhat.com> Message-ID: <5003C8E8.306@redhat.com> On 16/07/12 10:01, Itamar Heim wrote: > On 07/16/2012 09:56 AM, Livnat Peer wrote: >> On 16/07/12 09:41, Itamar Heim wrote: >>> On 07/16/2012 01:46 AM, Robert Middleswarth wrote: >>>> On 07/15/2012 03:59 PM, Ayal Baron wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Sorry for cross-posting, but in this case I think it's relevant. >>>>>>> >>>>>>> The original idea was that every time we wish to discuss a new >>>>>>> cross-component feature we should do it over arch list. However, it >>>>>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>>>>> being used (cross posted). Currently engine-devel has 211 >>>>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>>>>> perspective again, arch seems less relevant. I propose we ditch >>>>>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>>>>> cross-component features should be discussed solely on engine-devel >>>>>>> or cross-posted (there are probably people who wouldn't care about >>>>>>> engine side but would still like to know about such changes). >>>>>>> >>>>>>> Thoughts? >>>>>> - -1 >>>>>> >>>>>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>>>>> noticed >>>>>> that discussions I would expect to be on arch@ are not happening >>>>>> here. >>>>>> I'm probably not the only person in that situation. >>>>>> >>>>>> If this project were 100% about Engine and VDSM, then I could >>>>>> understand your reasoning. But we've already added a few new >>>>>> incubating projects, we have subsystem teams such as documentation >>>>>> and >>>>>> infrastructure, and we all need a single location where we know we >>>>>> can >>>>>> reach *all* contributors to this project. >>>>>> >>>>>> If we try to force all that discussion on to engine-devel, not >>>>>> everyone would be interested. There is enough on engine-devel that is >>>>>> not general interest that it would become noise (as it has for me, so >>>>>> I filter it) or people would drop it all together. >>>>>> >>>>>> Perhaps what we need to do is have the discipline to cross-post *all* >>>>>> general interest discussions from the project mailing list back to >>>>>> arch@? Enforce the rule that decisions that affect the whole project >>>>>> have to be ratified on arch@ instead of whatever project list the >>>>>> discussions started on? Strongly suggest that all contributors be on >>>>>> arch@ and announce@ as a minimum? >>>>> I find that anything that should go on arch would interest anyone on >>>>> the devel lists (as it is about new features, design, etc) so I >>>>> believe that arch should have at least everyone on engine-devel and >>>>> vdsm-devel. >>>>> However, right now this is not the case as is evident by number of >>>>> subs to each list (e.g. I haven't compared to see if everyone on arch >>>>> is on engine). >>>>> So imo something needs to be done. >>>>> I'm fine with keeping arch, but as you said, that means we need to >>>>> enforce it to be *the* list for feature discussions and I'm not >>>>> exactly sure how you'd go about doing that. >>>> Maybe arch needs renamed to make it clear what if is for? >>>> >>>> Maybe something simple like ovirt-devel to make it clear it is for >>>> generally ovirt development? >>> >>> we can simply make it arch include the other mailing lists, so sending >>> to arch would be sending to all other mailing lists. >> >> What would happen if someone reply on the engine-list to a mail >> originally sent to arch? >> >> wouldn't we end-up starting a thread on arch and then loosing it to one >> of the other lists? > > reply-to is not set to reply-to-list, rather to original sender/cc list, > so shouldn't be an issue > ok so if reply to such mail de-facto I'll send a mail to the arch list - shouldn't I be register to the arch list (or I need someone to approve the mail)? >> >> >>> wouldn't resolve the dupes, but will resolve need of everyone to >>> subscribe to it as well. >>> (for dupes i also use a mail filter to delete emails arriving from >>> engine-devel and cc other mailing list, etc. >>> _______________________________________________ >>> Arch mailing list >>> Arch at ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/arch >> >> > > From iheim at redhat.com Mon Jul 16 10:18:49 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 16 Jul 2012 13:18:49 +0300 Subject: [Engine-devel] [vdsm] Getting rid of arch@ovirt.org? In-Reply-To: <5003C8E8.306@redhat.com> References: <66371106-0980-4506-9855-af5c24b6b051@zmail13.collab.prod.int.phx2.redhat.com> <5003482B.60406@middleswarth.net> <5003B7AF.8020409@redhat.com> <5003BB1B.8040002@redhat.com> <5003BC46.9040903@redhat.com> <5003C8E8.306@redhat.com> Message-ID: <5003EA89.8060206@redhat.com> On 07/16/2012 10:55 AM, Livnat Peer wrote: > On 16/07/12 10:01, Itamar Heim wrote: >> On 07/16/2012 09:56 AM, Livnat Peer wrote: >>> On 16/07/12 09:41, Itamar Heim wrote: >>>> On 07/16/2012 01:46 AM, Robert Middleswarth wrote: >>>>> On 07/15/2012 03:59 PM, Ayal Baron wrote: >>>>>> >>>>>> ----- Original Message ----- >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> On 07/15/2012 01:53 AM, Ayal Baron wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Sorry for cross-posting, but in this case I think it's relevant. >>>>>>>> >>>>>>>> The original idea was that every time we wish to discuss a new >>>>>>>> cross-component feature we should do it over arch list. However, it >>>>>>>> would appear that de-facto usually engine-devel and vdsm-devel are >>>>>>>> being used (cross posted). Currently engine-devel has 211 >>>>>>>> subscribers, arch has 160 and vdsm-devel has 128 so from this >>>>>>>> perspective again, arch seems less relevant. I propose we ditch >>>>>>>> arch and keep the other 2 mailing lists. I'm not sure whether new >>>>>>>> cross-component features should be discussed solely on engine-devel >>>>>>>> or cross-posted (there are probably people who wouldn't care about >>>>>>>> engine side but would still like to know about such changes). >>>>>>>> >>>>>>>> Thoughts? >>>>>>> - -1 >>>>>>> >>>>>>> I don't normally read engine-devel and vdsm-devel, so I hadn't >>>>>>> noticed >>>>>>> that discussions I would expect to be on arch@ are not happening >>>>>>> here. >>>>>>> I'm probably not the only person in that situation. >>>>>>> >>>>>>> If this project were 100% about Engine and VDSM, then I could >>>>>>> understand your reasoning. But we've already added a few new >>>>>>> incubating projects, we have subsystem teams such as documentation >>>>>>> and >>>>>>> infrastructure, and we all need a single location where we know we >>>>>>> can >>>>>>> reach *all* contributors to this project. >>>>>>> >>>>>>> If we try to force all that discussion on to engine-devel, not >>>>>>> everyone would be interested. There is enough on engine-devel that is >>>>>>> not general interest that it would become noise (as it has for me, so >>>>>>> I filter it) or people would drop it all together. >>>>>>> >>>>>>> Perhaps what we need to do is have the discipline to cross-post *all* >>>>>>> general interest discussions from the project mailing list back to >>>>>>> arch@? Enforce the rule that decisions that affect the whole project >>>>>>> have to be ratified on arch@ instead of whatever project list the >>>>>>> discussions started on? Strongly suggest that all contributors be on >>>>>>> arch@ and announce@ as a minimum? >>>>>> I find that anything that should go on arch would interest anyone on >>>>>> the devel lists (as it is about new features, design, etc) so I >>>>>> believe that arch should have at least everyone on engine-devel and >>>>>> vdsm-devel. >>>>>> However, right now this is not the case as is evident by number of >>>>>> subs to each list (e.g. I haven't compared to see if everyone on arch >>>>>> is on engine). >>>>>> So imo something needs to be done. >>>>>> I'm fine with keeping arch, but as you said, that means we need to >>>>>> enforce it to be *the* list for feature discussions and I'm not >>>>>> exactly sure how you'd go about doing that. >>>>> Maybe arch needs renamed to make it clear what if is for? >>>>> >>>>> Maybe something simple like ovirt-devel to make it clear it is for >>>>> generally ovirt development? >>>> >>>> we can simply make it arch include the other mailing lists, so sending >>>> to arch would be sending to all other mailing lists. >>> >>> What would happen if someone reply on the engine-list to a mail >>> originally sent to arch? >>> >>> wouldn't we end-up starting a thread on arch and then loosing it to one >>> of the other lists? >> >> reply-to is not set to reply-to-list, rather to original sender/cc list, >> so shouldn't be an issue >> > > ok so if reply to such mail de-facto I'll send a mail to the arch list - > shouldn't I be register to the arch list (or I need someone to approve > the mail)? you would be moderated the first time you reply to it, yes. same as for all other mailing lists - not an issue usually. > > >>> >>> >>>> wouldn't resolve the dupes, but will resolve need of everyone to >>>> subscribe to it as well. >>>> (for dupes i also use a mail filter to delete emails arriving from >>>> engine-devel and cc other mailing list, etc. >>>> _______________________________________________ >>>> Arch mailing list >>>> Arch at ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/arch >>> >>> >> >> > > From jhernand at redhat.com Mon Jul 16 18:44:40 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 16 Jul 2012 20:44:40 +0200 Subject: [Engine-devel] Proposed change in default port numbers Message-ID: <50046118.3020901@redhat.com> Hello all, In change http://gerrit.ovirt.org/6348 I am proposing to change the default port numbers used by the engine, in order to avoid conflicts with the default ports used by JBoss. Suggestions are welcome. 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 acathrow at redhat.com Mon Jul 16 19:21:51 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Mon, 16 Jul 2012 15:21:51 -0400 (EDT) Subject: [Engine-devel] Proposed change in default port numbers In-Reply-To: <50046118.3020901@redhat.com> Message-ID: ----- Original Message ----- > From: "Juan Hernandez" > To: engine-devel at ovirt.org > Sent: Monday, July 16, 2012 2:44:40 PM > Subject: [Engine-devel] Proposed change in default port numbers > > Hello all, > > In change http://gerrit.ovirt.org/6348 I am proposing to change the > default port numbers used by the engine, in order to avoid conflicts > with the default ports used by JBoss. To be clear though even if we moved to use port 6090 for http and 6091 for https we'd still have 80/443 available through the installer. > > Suggestions are welcome. > > 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. > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From jhernand at redhat.com Mon Jul 16 19:27:02 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 16 Jul 2012 21:27:02 +0200 Subject: [Engine-devel] Proposed change in default port numbers In-Reply-To: References: Message-ID: <50046B06.50705@redhat.com> On 07/16/2012 09:21 PM, Andrew Cathrow wrote: > > > ----- Original Message ----- >> From: "Juan Hernandez" >> To: engine-devel at ovirt.org >> Sent: Monday, July 16, 2012 2:44:40 PM >> Subject: [Engine-devel] Proposed change in default port numbers >> >> Hello all, >> >> In change http://gerrit.ovirt.org/6348 I am proposing to change the >> default port numbers used by the engine, in order to avoid conflicts >> with the default ports used by JBoss. > > To be clear though even if we moved to use port 6090 for http and 6091 for https we'd still have 80/443 available through the installer. Correct, 80 and 443 will continue to be the default ports when using Apache as proxy in front of JBoss: 80 -> 80 (no change) 443 -> 443 (no change) 8080 -> 6090 8443 -> 6091 8009 -> 6092 4447 -> 6093 4712 -> 6094 4713 -> 6095 -- 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 jhernand at redhat.com Mon Jul 16 20:13:21 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 16 Jul 2012 22:13:21 +0200 Subject: [Engine-devel] Change in the location of krb5.conf Message-ID: <500475E1.4000406@redhat.com> Hello all, The location of the krb5.conf file used to be indicated by the jboss.server.config.dir system property, but as part of the change to generate the JBoss configuration file from a template I had to change that. Now the location of the krb5.conf file has to be /etc/ovirt-engine. This was already the location for environments installed from RPMs, so if you are using RPMs you don't need to change anything. In development environments you will need to use the environment variable ENGINE_ETC: export ENGINE_ETC=$JBOSS_HOME/standalone/configuration I continue working on a solution better than this. Will keep you informed. 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 sgordon at redhat.com Tue Jul 17 18:19:01 2012 From: sgordon at redhat.com (Steve Gordon) Date: Tue, 17 Jul 2012 14:19:01 -0400 (EDT) Subject: [Engine-devel] Proposed change in default port numbers In-Reply-To: <50046B06.50705@redhat.com> Message-ID: ----- Original Message ----- > From: "Juan Hernandez" > To: "Andrew Cathrow" > Cc: engine-devel at ovirt.org > Sent: Monday, July 16, 2012 3:27:02 PM > Subject: Re: [Engine-devel] Proposed change in default port numbers > > On 07/16/2012 09:21 PM, Andrew Cathrow wrote: > > > > > > ----- Original Message ----- > >> From: "Juan Hernandez" > >> To: engine-devel at ovirt.org > >> Sent: Monday, July 16, 2012 2:44:40 PM > >> Subject: [Engine-devel] Proposed change in default port numbers > >> > >> Hello all, > >> > >> In change http://gerrit.ovirt.org/6348 I am proposing to change > >> the > >> default port numbers used by the engine, in order to avoid > >> conflicts > >> with the default ports used by JBoss. > > > > To be clear though even if we moved to use port 6090 for http and > > 6091 for https we'd still have 80/443 available through the > > installer. > > Correct, 80 and 443 will continue to be the default ports when using > Apache as proxy in front of JBoss: > > 80 -> 80 (no change) > 443 -> 443 (no change) > 8080 -> 6090 > 8443 -> 6091 This is probably a stupid question, but what are the following ports used for: > 8009 -> 6092 > 4447 -> 6093 > 4712 -> 6094 > 4713 -> 6095 As far as I know we don't have them listed anywhere in the documentation as requiring a firewall rule to allow them, should we? Steve From jhernand at redhat.com Tue Jul 17 18:27:44 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Tue, 17 Jul 2012 20:27:44 +0200 Subject: [Engine-devel] Proposed change in default port numbers In-Reply-To: References: Message-ID: <5005AEA0.4060600@redhat.com> On 07/17/2012 08:19 PM, Steve Gordon wrote: > ----- Original Message ----- >> From: "Juan Hernandez" >> To: "Andrew Cathrow" >> Cc: engine-devel at ovirt.org >> Sent: Monday, July 16, 2012 3:27:02 PM >> Subject: Re: [Engine-devel] Proposed change in default port numbers >> >> On 07/16/2012 09:21 PM, Andrew Cathrow wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Juan Hernandez" >>>> To: engine-devel at ovirt.org >>>> Sent: Monday, July 16, 2012 2:44:40 PM >>>> Subject: [Engine-devel] Proposed change in default port numbers >>>> >>>> Hello all, >>>> >>>> In change http://gerrit.ovirt.org/6348 I am proposing to change >>>> the >>>> default port numbers used by the engine, in order to avoid >>>> conflicts >>>> with the default ports used by JBoss. >>> >>> To be clear though even if we moved to use port 6090 for http and >>> 6091 for https we'd still have 80/443 available through the >>> installer. >> >> Correct, 80 and 443 will continue to be the default ports when using >> Apache as proxy in front of JBoss: >> >> 80 -> 80 (no change) >> 443 -> 443 (no change) >> 8080 -> 6090 >> 8443 -> 6091 > > This is probably a stupid question, but what are the following ports used for: > >> 8009 -> 6092 This port is used for the communication between the Apache web server and the JBoss application server using the AJP protocol. It doesn't need to be available outside of the machine. >> 4447 -> 6093 These port is used by the remoting capability of the application server: calling EJBs from external applications. We don't use it but it is required anyhow. It doesn't need to be available outside of the machine. >> 4712 -> 6094 >> 4713 -> 6095 These two ports are used by the transaction manager inside JBoss. They don't need to be available outside of the machine. So none of them needs a firewall rule to allow inbound traffic. I am proposing a different change to bind those ports to the loopback address so that they are not available even when the firewall is disabled: http://gerrit.ovirt.org/6349 I would disable them completely, but didn't find the way to do it yet. > As far as I know we don't have them listed anywhere in the documentation as requiring a firewall rule to allow them, should we? They don't require a firewall rule to allow incoming traffic. We could explain in the documentation that they are required, but only for communications internal to the machine. -- 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 dneary at redhat.com Tue Jul 17 15:28:32 2012 From: dneary at redhat.com (Dave Neary) Date: Tue, 17 Jul 2012 08:28:32 -0700 Subject: [Engine-devel] Getting rid of arch@ovirt.org? In-Reply-To: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> References: <266239e3-dcdc-4db5-b121-f37c42052ffc@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <500584A0.4050802@redhat.com> Hi, On 07/15/2012 01:53 AM, Ayal Baron wrote: > Sorry for cross-posting, but in this case I think it's relevant. > > The original idea was that every time we wish to discuss a new cross-component feature we should do it over arch list. However, it would appear that de-facto usually engine-devel and vdsm-devel are being used (cross posted). > Currently engine-devel has 211 subscribers, arch has 160 and vdsm-devel has 128 so from this perspective again, arch seems less relevant. > I propose we ditch arch and keep the other 2 mailing lists. > I'm not sure whether new cross-component features should be discussed solely on engine-devel or cross-posted (there are probably people who wouldn't care about engine side but would still like to know about such changes). > > Thoughts? It's a tricky problem, as Karsten said. In fact, one of the questions I had when joining the list is, where do all the developers hang out? And outside of arch@ there wasn't a good answer. I'm not on vdsm-devel, neither vdsm-devel or engine-devel are mentioned at all on http://www.ovirt.org/project/community/ and like Karsten I think there is a role for a list which allows everyone to talk about topics unrelated to a specific component, but also not related to "users" who are not contributing to the project. I agree, though, that the cross-posting is an issue. It seems like I need to cross-post every message to at least 2 or 3 lists to get everyone I'm interested in reaching - this suggests to me that we have too many communication channels, and need to consolidate a little. That, or we need to help people understand which forums they should be in for which types of communications, so that we don't constantly have the problem of cross-posting to be on the safe side. That's the solution I prefer. Cheers, Dave. -- Dave Neary Community Action and Impact Open Source and Standards Team, Red Hat Phone: +33 9 50 71 55 62 From sanjal at redhat.com Wed Jul 18 09:39:45 2012 From: sanjal at redhat.com (Shireesh Anjal) Date: Wed, 18 Jul 2012 15:09:45 +0530 Subject: [Engine-devel] Proposed change in default port numbers In-Reply-To: <5005AEA0.4060600@redhat.com> References: <5005AEA0.4060600@redhat.com> Message-ID: <50068461.7000908@redhat.com> On Tuesday 17 July 2012 11:57 PM, Juan Hernandez wrote: > On 07/17/2012 08:19 PM, Steve Gordon wrote: >> ----- Original Message ----- >>> From: "Juan Hernandez" >>> To: "Andrew Cathrow" >>> Cc: engine-devel at ovirt.org >>> Sent: Monday, July 16, 2012 3:27:02 PM >>> Subject: Re: [Engine-devel] Proposed change in default port numbers >>> >>> On 07/16/2012 09:21 PM, Andrew Cathrow wrote: >>>> >>>> ----- Original Message ----- >>>>> From: "Juan Hernandez" >>>>> To: engine-devel at ovirt.org >>>>> Sent: Monday, July 16, 2012 2:44:40 PM >>>>> Subject: [Engine-devel] Proposed change in default port numbers >>>>> >>>>> Hello all, >>>>> >>>>> In change http://gerrit.ovirt.org/6348 I am proposing to change >>>>> the >>>>> default port numbers used by the engine, in order to avoid >>>>> conflicts >>>>> with the default ports used by JBoss. >>>> To be clear though even if we moved to use port 6090 for http and >>>> 6091 for https we'd still have 80/443 available through the >>>> installer. >>> Correct, 80 and 443 will continue to be the default ports when using >>> Apache as proxy in front of JBoss: >>> >>> 80 -> 80 (no change) >>> 443 -> 443 (no change) >>> 8080 -> 6090 >>> 8443 -> 6091 >> This is probably a stupid question, but what are the following ports used for: >> >>> 8009 -> 6092 > This port is used for the communication between the Apache web server > and the JBoss application server using the AJP protocol. It doesn't need > to be available outside of the machine. The "Firewall Configuration" chapter of oVirt installation guide (http://wiki.ovirt.org/wiki/File:OVirt-3.0-Installation_Guide-en-US.pdf) says that ports 8006 through 8009 are required for network communication from "Administration Portal Clients" to "oVirt Engine". > >>> 4447 -> 6093 > These port is used by the remoting capability of the application server: > calling EJBs from external applications. We don't use it but it is > required anyhow. It doesn't need to be available outside of the machine. > >>> 4712 -> 6094 >>> 4713 -> 6095 > These two ports are used by the transaction manager inside JBoss. They > don't need to be available outside of the machine. > > So none of them needs a firewall rule to allow inbound traffic. I am > proposing a different change to bind those ports to the loopback address > so that they are not available even when the firewall is disabled: > > http://gerrit.ovirt.org/6349 > > I would disable them completely, but didn't find the way to do it yet. > >> As far as I know we don't have them listed anywhere in the documentation as requiring a firewall rule to allow them, should we? > They don't require a firewall rule to allow incoming traffic. We could > explain in the documentation that they are required, but only for > communications internal to the machine. > From jhernand at redhat.com Wed Jul 18 09:46:38 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 18 Jul 2012 11:46:38 +0200 Subject: [Engine-devel] Proposed change in default port numbers In-Reply-To: <50068461.7000908@redhat.com> References: <5005AEA0.4060600@redhat.com> <50068461.7000908@redhat.com> Message-ID: <500685FE.2090004@redhat.com> On 07/18/2012 11:39 AM, Shireesh Anjal wrote: > On Tuesday 17 July 2012 11:57 PM, Juan Hernandez wrote: >> On 07/17/2012 08:19 PM, Steve Gordon wrote: >>> ----- Original Message ----- >>>> From: "Juan Hernandez" >>>> To: "Andrew Cathrow" >>>> Cc: engine-devel at ovirt.org >>>> Sent: Monday, July 16, 2012 3:27:02 PM >>>> Subject: Re: [Engine-devel] Proposed change in default port numbers >>>> >>>> On 07/16/2012 09:21 PM, Andrew Cathrow wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Juan Hernandez" >>>>>> To: engine-devel at ovirt.org >>>>>> Sent: Monday, July 16, 2012 2:44:40 PM >>>>>> Subject: [Engine-devel] Proposed change in default port numbers >>>>>> >>>>>> Hello all, >>>>>> >>>>>> In change http://gerrit.ovirt.org/6348 I am proposing to change >>>>>> the >>>>>> default port numbers used by the engine, in order to avoid >>>>>> conflicts >>>>>> with the default ports used by JBoss. >>>>> To be clear though even if we moved to use port 6090 for http and >>>>> 6091 for https we'd still have 80/443 available through the >>>>> installer. >>>> Correct, 80 and 443 will continue to be the default ports when using >>>> Apache as proxy in front of JBoss: >>>> >>>> 80 -> 80 (no change) >>>> 443 -> 443 (no change) >>>> 8080 -> 6090 >>>> 8443 -> 6091 >>> This is probably a stupid question, but what are the following ports used for: >>> >>>> 8009 -> 6092 >> This port is used for the communication between the Apache web server >> and the JBoss application server using the AJP protocol. It doesn't need >> to be available outside of the machine. > > The "Firewall Configuration" chapter of oVirt installation guide > (http://wiki.ovirt.org/wiki/File:OVirt-3.0-Installation_Guide-en-US.pdf) > says that ports 8006 through 8009 are required for network communication > from "Administration Portal Clients" to "oVirt Engine". Sure this has roots in the past, but today we don't have any program listening in ports 8006, 8007 or 8008, and 8009 is only used for AJP, no one connects there from outside the machine. I proposed yet another change to remove the message about those ports from the setup tool: http://gerrit.ovirt.org/6386 I am not 100% sure, but if these ports are really not used then the documentation should also be updated. >>>> 4447 -> 6093 >> These port is used by the remoting capability of the application server: >> calling EJBs from external applications. We don't use it but it is >> required anyhow. It doesn't need to be available outside of the machine. >> >>>> 4712 -> 6094 >>>> 4713 -> 6095 >> These two ports are used by the transaction manager inside JBoss. They >> don't need to be available outside of the machine. >> >> So none of them needs a firewall rule to allow inbound traffic. I am >> proposing a different change to bind those ports to the loopback address >> so that they are not available even when the firewall is disabled: >> >> http://gerrit.ovirt.org/6349 >> >> I would disable them completely, but didn't find the way to do it yet. >> >>> As far as I know we don't have them listed anywhere in the documentation as requiring a firewall rule to allow them, should we? >> They don't require a firewall rule to allow incoming traffic. We could >> explain in the documentation that they are required, but only for >> communications internal to the machine. >> > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- 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 iheim at redhat.com Wed Jul 18 09:49:43 2012 From: iheim at redhat.com (Itamar Heim) Date: Wed, 18 Jul 2012 12:49:43 +0300 Subject: [Engine-devel] Proposed change in default port numbers In-Reply-To: <500685FE.2090004@redhat.com> References: <5005AEA0.4060600@redhat.com> <50068461.7000908@redhat.com> <500685FE.2090004@redhat.com> Message-ID: <500686B7.70201@redhat.com> On 07/18/2012 12:46 PM, Juan Hernandez wrote: > On 07/18/2012 11:39 AM, Shireesh Anjal wrote: >> On Tuesday 17 July 2012 11:57 PM, Juan Hernandez wrote: >>> On 07/17/2012 08:19 PM, Steve Gordon wrote: >>>> ----- Original Message ----- >>>>> From: "Juan Hernandez" >>>>> To: "Andrew Cathrow" >>>>> Cc: engine-devel at ovirt.org >>>>> Sent: Monday, July 16, 2012 3:27:02 PM >>>>> Subject: Re: [Engine-devel] Proposed change in default port numbers >>>>> >>>>> On 07/16/2012 09:21 PM, Andrew Cathrow wrote: >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Juan Hernandez" >>>>>>> To: engine-devel at ovirt.org >>>>>>> Sent: Monday, July 16, 2012 2:44:40 PM >>>>>>> Subject: [Engine-devel] Proposed change in default port numbers >>>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> In change http://gerrit.ovirt.org/6348 I am proposing to change >>>>>>> the >>>>>>> default port numbers used by the engine, in order to avoid >>>>>>> conflicts >>>>>>> with the default ports used by JBoss. >>>>>> To be clear though even if we moved to use port 6090 for http and >>>>>> 6091 for https we'd still have 80/443 available through the >>>>>> installer. >>>>> Correct, 80 and 443 will continue to be the default ports when using >>>>> Apache as proxy in front of JBoss: >>>>> >>>>> 80 -> 80 (no change) >>>>> 443 -> 443 (no change) >>>>> 8080 -> 6090 >>>>> 8443 -> 6091 >>>> This is probably a stupid question, but what are the following ports used for: >>>> >>>>> 8009 -> 6092 >>> This port is used for the communication between the Apache web server >>> and the JBoss application server using the AJP protocol. It doesn't need >>> to be available outside of the machine. >> >> The "Firewall Configuration" chapter of oVirt installation guide >> (http://wiki.ovirt.org/wiki/File:OVirt-3.0-Installation_Guide-en-US.pdf) >> says that ports 8006 through 8009 are required for network communication >> from "Administration Portal Clients" to "oVirt Engine". > > Sure this has roots in the past, but today we don't have any program > listening in ports 8006, 8007 or 8008, and 8009 is only used for AJP, no > one connects there from outside the machine. I proposed yet another > change to remove the message about those ports from the setup tool: > > http://gerrit.ovirt.org/6386 > > I am not 100% sure, but if these ports are really not used then the > documentation should also be updated. documentation should be updated. these are the ports used by WPF client to connect to the C# service in 2.2... > >>>>> 4447 -> 6093 >>> These port is used by the remoting capability of the application server: >>> calling EJBs from external applications. We don't use it but it is >>> required anyhow. It doesn't need to be available outside of the machine. >>> >>>>> 4712 -> 6094 >>>>> 4713 -> 6095 >>> These two ports are used by the transaction manager inside JBoss. They >>> don't need to be available outside of the machine. >>> >>> So none of them needs a firewall rule to allow inbound traffic. I am >>> proposing a different change to bind those ports to the loopback address >>> so that they are not available even when the firewall is disabled: >>> >>> http://gerrit.ovirt.org/6349 >>> >>> I would disable them completely, but didn't find the way to do it yet. >>> >>>> As far as I know we don't have them listed anywhere in the documentation as requiring a firewall rule to allow them, should we? >>> They don't require a firewall rule to allow incoming traffic. We could >>> explain in the documentation that they are required, but only for >>> communications internal to the machine. >>> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > From lhornyak at redhat.com Wed Jul 18 15:43:34 2012 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Wed, 18 Jul 2012 11:43:34 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <3dd3de8e-73da-4708-9b08-b0640aa9b534@zmail03.collab.prod.int.phx2.redhat.com> Message-ID: Hi, It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional? Laszlo From vszocs at redhat.com Wed Jul 18 16:33:42 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Wed, 18 Jul 2012 12:33:42 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: Message-ID: <7575ffd4-3f3e-4ebf-a2c1-12a10ec96d82@zmail16.collab.prod.int.phx2.redhat.com> In fact, for both backend and frontend, Maven effective POM contains: maven-compiler-plugin 1.6 1.6 Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). Vojtech ----- Original Message ----- From: "Laszlo Hornyak" To: "engine-devel" Cc: "Vojtech Szocs" Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more? Hi, It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional? Laszlo From jhernand at redhat.com Wed Jul 18 17:21:20 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Wed, 18 Jul 2012 19:21:20 +0200 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <7575ffd4-3f3e-4ebf-a2c1-12a10ec96d82@zmail16.collab.prod.int.phx2.redhat.com> References: <7575ffd4-3f3e-4ebf-a2c1-12a10ec96d82@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <5006F090.7090809@redhat.com> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: > In fact, for both backend and frontend, Maven effective POM contains: > > maven-compiler-plugin > > 1.6 > 1.6 > > > Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used. > The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. > > I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). > > Vojtech > > > ----- Original Message ----- > From: "Laszlo Hornyak" > To: "engine-devel" > Cc: "Vojtech Szocs" > Sent: Wednesday, July 18, 2012 5:43:34 PM > Subject: java 1.6 compatibility no more? > > Hi, > > It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. > Is this intentional? > > Laszlo > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- 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 iheim at redhat.com Wed Jul 18 22:26:37 2012 From: iheim at redhat.com (Itamar Heim) Date: Thu, 19 Jul 2012 01:26:37 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <5006F090.7090809@redhat.com> References: <7575ffd4-3f3e-4ebf-a2c1-12a10ec96d82@zmail16.collab.prod.int.phx2.redhat.com> <5006F090.7090809@redhat.com> Message-ID: <5007381D.7040402@redhat.com> On 07/18/2012 08:21 PM, Juan Hernandez wrote: > On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >> In fact, for both backend and frontend, Maven effective POM contains: >> >> maven-compiler-plugin >> >> 1.6 >> 1.6 >> >> >> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) > > These maven settings just tell the java compiler to accept Java 6 syntax > only and to generate a Java 6 compatible .class file format, but they > don't restrict the set of APIs that can be used. I think the question is if it makes any sense to keep/force java 6 compatibility for next version of ovirt, with java 6 EOL dates. a jenkins job compiling for java 6 compatibility is easy to create - question is if there is a reason to do it. > >> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >> >> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Laszlo Hornyak" >> To: "engine-devel" >> Cc: "Vojtech Szocs" >> Sent: Wednesday, July 18, 2012 5:43:34 PM >> Subject: java 1.6 compatibility no more? >> >> Hi, >> >> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >> Is this intentional? >> >> Laszlo >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > From yzaslavs at redhat.com Thu Jul 19 05:42:48 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 19 Jul 2012 08:42:48 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: References: Message-ID: <50079E58.4030305@redhat.com> On 07/18/2012 06:43 PM, Laszlo Hornyak wrote: > Hi, > > It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. > Is this intentional? > > Laszlo > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel Laszlo, I assumed (maybe wrong) that our subscribers on engine-devel are aware they should use jdk7. We recently had several issues (for example - some ldap/dns issue) with JDK6 , that were fixed on JDK7. From yzaslavs at redhat.com Thu Jul 19 05:59:45 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 19 Jul 2012 08:59:45 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <5006F090.7090809@redhat.com> References: <7575ffd4-3f3e-4ebf-a2c1-12a10ec96d82@zmail16.collab.prod.int.phx2.redhat.com> <5006F090.7090809@redhat.com> Message-ID: <5007A251.3050405@redhat.com> On 07/18/2012 08:21 PM, Juan Hernandez wrote: > On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >> In fact, for both backend and frontend, Maven effective POM contains: >> >> maven-compiler-plugin >> >> 1.6 >> 1.6 >> >> >> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) > > These maven settings just tell the java compiler to accept Java 6 syntax > only and to generate a Java 6 compatible .class file format, but they > don't restrict the set of APIs that can be used. > >> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >> >> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >> >> Vojtech As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes? >> >> >> ----- Original Message ----- >> From: "Laszlo Hornyak" >> To: "engine-devel" >> Cc: "Vojtech Szocs" >> Sent: Wednesday, July 18, 2012 5:43:34 PM >> Subject: java 1.6 compatibility no more? >> >> Hi, >> >> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >> Is this intentional? >> >> Laszlo >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel at ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > From vszocs at redhat.com Thu Jul 19 08:09:22 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 19 Jul 2012 04:09:22 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <5007A251.3050405@redhat.com> Message-ID: > As I previously emailed - JDK7 already fixed a known issue with ldap and > DNS ,and made one of my patches at gerrit redundant. > Why not enjoy the bug fixes? I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. Vojtech ----- Original Message ----- From: "Yair Zaslavsky" To: engine-devel at ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/18/2012 08:21 PM, Juan Hernandez wrote: > On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >> In fact, for both backend and frontend, Maven effective POM contains: >> >> maven-compiler-plugin >> >> 1.6 >> 1.6 >> >> >> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) > > These maven settings just tell the java compiler to accept Java 6 syntax > only and to generate a Java 6 compatible .class file format, but they > don't restrict the set of APIs that can be used. > >> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >> >> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >> >> Vojtech As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes? >> >> >> ----- Original Message ----- >> From: "Laszlo Hornyak" >> To: "engine-devel" >> Cc: "Vojtech Szocs" >> Sent: Wednesday, July 18, 2012 5:43:34 PM >> Subject: java 1.6 compatibility no more? >> >> Hi, >> >> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >> Is this intentional? >> >> Laszlo >> _______________________________________________ >> 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 lhornyak at redhat.com Thu Jul 19 08:10:18 2012 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 19 Jul 2012 04:10:18 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <50079E58.4030305@redhat.com> Message-ID: <1bcf31ff-3563-454d-877a-47d8b84cba7f@zmail03.collab.prod.int.phx2.redhat.com> Not against it, but then we have declare in the pom that java 1.6 is no longer working http://gerrit.ovirt.org/6447 Laszlo ----- Original Message ----- > From: "Yair Zaslavsky" > To: engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 7:42:48 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/18/2012 06:43 PM, Laszlo Hornyak wrote: > > Hi, > > > > It may be a historic moment, but for a few hours oVirt engine is no > > longer building on java 1.6. > > Is this intentional? > > > > Laszlo > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > Laszlo, > I assumed (maybe wrong) that our subscribers on engine-devel are > aware > they should use jdk7. > > We recently had several issues (for example - some ldap/dns issue) > with > JDK6 , that were fixed on JDK7. > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From yzaslavs at redhat.com Thu Jul 19 08:30:28 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 19 Jul 2012 11:30:28 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: References: Message-ID: <5007C5A4.9080500@redhat.com> On 07/19/2012 11:09 AM, Vojtech Szocs wrote: >> As I previously emailed - JDK7 already fixed a known issue with ldap and >> DNS ,and made one of my patches at gerrit redundant. >> Why not enjoy the bug fixes? > > I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? > > If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. > +1 here - whatever it takes ;) > Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. > > Vojtech > > > ----- Original Message ----- > From: "Yair Zaslavsky" > To: engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 7:59:45 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/18/2012 08:21 PM, Juan Hernandez wrote: >> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >>> In fact, for both backend and frontend, Maven effective POM contains: >>> >>> maven-compiler-plugin >>> >>> 1.6 >>> 1.6 >>> >>> >>> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) >> >> These maven settings just tell the java compiler to accept Java 6 syntax >> only and to generate a Java 6 compatible .class file format, but they >> don't restrict the set of APIs that can be used. >> >>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >>> >>> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >>> >>> Vojtech > > As I previously emailed - JDK7 already fixed a known issue with ldap and > DNS ,and made one of my patches at gerrit redundant. > Why not enjoy the bug fixes? > >>> >>> >>> ----- Original Message ----- >>> From: "Laszlo Hornyak" >>> To: "engine-devel" >>> Cc: "Vojtech Szocs" >>> Sent: Wednesday, July 18, 2012 5:43:34 PM >>> Subject: java 1.6 compatibility no more? >>> >>> Hi, >>> >>> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >>> Is this intentional? >>> >>> Laszlo >>> _______________________________________________ >>> 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 Thu Jul 19 09:01:00 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Thu, 19 Jul 2012 11:01:00 +0200 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: References: Message-ID: <5007CCCC.4090306@redhat.com> On 07/19/2012 10:09 AM, Vojtech Szocs wrote: >> As I previously emailed - JDK7 already fixed a known issue with ldap and >> DNS ,and made one of my patches at gerrit redundant. >> Why not enjoy the bug fixes? > > I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? > > If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. > > Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. Don't we need that (the source part) to avoid Java 7 syntax in GWT code? > ----- Original Message ----- > From: "Yair Zaslavsky" > To: engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 7:59:45 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/18/2012 08:21 PM, Juan Hernandez wrote: >> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >>> In fact, for both backend and frontend, Maven effective POM contains: >>> >>> maven-compiler-plugin >>> >>> 1.6 >>> 1.6 >>> >>> >>> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) >> >> These maven settings just tell the java compiler to accept Java 6 syntax >> only and to generate a Java 6 compatible .class file format, but they >> don't restrict the set of APIs that can be used. >> >>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >>> >>> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >>> >>> Vojtech > > As I previously emailed - JDK7 already fixed a known issue with ldap and > DNS ,and made one of my patches at gerrit redundant. > Why not enjoy the bug fixes? > >>> >>> >>> ----- Original Message ----- >>> From: "Laszlo Hornyak" >>> To: "engine-devel" >>> Cc: "Vojtech Szocs" >>> Sent: Wednesday, July 18, 2012 5:43:34 PM >>> Subject: java 1.6 compatibility no more? >>> >>> Hi, >>> >>> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >>> Is this intentional? >>> >>> Laszlo >>> _______________________________________________ >>> 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 > -- 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 vszocs at redhat.com Thu Jul 19 11:31:40 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Thu, 19 Jul 2012 07:31:40 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <5007CCCC.4090306@redhat.com> Message-ID: > Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech ----- Original Message ----- From: "Juan Hernandez" To: "Vojtech Szocs" Cc: "Yair Zaslavsky" , engine-devel at ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/19/2012 10:09 AM, Vojtech Szocs wrote: >> As I previously emailed - JDK7 already fixed a known issue with ldap and >> DNS ,and made one of my patches at gerrit redundant. >> Why not enjoy the bug fixes? > > I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? > > If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. > > Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. Don't we need that (the source part) to avoid Java 7 syntax in GWT code? > ----- Original Message ----- > From: "Yair Zaslavsky" > To: engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 7:59:45 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/18/2012 08:21 PM, Juan Hernandez wrote: >> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >>> In fact, for both backend and frontend, Maven effective POM contains: >>> >>> maven-compiler-plugin >>> >>> 1.6 >>> 1.6 >>> >>> >>> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) >> >> These maven settings just tell the java compiler to accept Java 6 syntax >> only and to generate a Java 6 compatible .class file format, but they >> don't restrict the set of APIs that can be used. >> >>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >>> >>> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >>> >>> Vojtech > > As I previously emailed - JDK7 already fixed a known issue with ldap and > DNS ,and made one of my patches at gerrit redundant. > Why not enjoy the bug fixes? > >>> >>> >>> ----- Original Message ----- >>> From: "Laszlo Hornyak" >>> To: "engine-devel" >>> Cc: "Vojtech Szocs" >>> Sent: Wednesday, July 18, 2012 5:43:34 PM >>> Subject: java 1.6 compatibility no more? >>> >>> Hi, >>> >>> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >>> Is this intentional? >>> >>> Laszlo >>> _______________________________________________ >>> 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 > -- 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 yzaslavs at redhat.com Thu Jul 19 11:39:27 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Thu, 19 Jul 2012 14:39:27 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: References: Message-ID: <5007F1EF.6080508@redhat.com> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >> Don't we need that (the source part) to avoid Java 7 syntax in GWT code? > > That's a very good point. > > In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. > > So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. > > We could do something like this: > > - let oVirt root POM declare source and target compliance to Java 7 > - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) > > (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) > > What do you think? > > Vojtech +1 - I really like this idea! > > > ----- Original Message ----- > From: "Juan Hernandez" > To: "Vojtech Szocs" > Cc: "Yair Zaslavsky" , engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 11:01:00 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/19/2012 10:09 AM, Vojtech Szocs wrote: >>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>> DNS ,and made one of my patches at gerrit redundant. >>> Why not enjoy the bug fixes? >> >> I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? >> >> If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. >> >> Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. > > Don't we need that (the source part) to avoid Java 7 syntax in GWT code? > >> ----- Original Message ----- >> From: "Yair Zaslavsky" >> To: engine-devel at ovirt.org >> Sent: Thursday, July 19, 2012 7:59:45 AM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 07/18/2012 08:21 PM, Juan Hernandez wrote: >>> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >>>> In fact, for both backend and frontend, Maven effective POM contains: >>>> >>>> maven-compiler-plugin >>>> >>>> 1.6 >>>> 1.6 >>>> >>>> >>>> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) >>> >>> These maven settings just tell the java compiler to accept Java 6 syntax >>> only and to generate a Java 6 compatible .class file format, but they >>> don't restrict the set of APIs that can be used. >>> >>>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >>>> >>>> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >>>> >>>> Vojtech >> >> As I previously emailed - JDK7 already fixed a known issue with ldap and >> DNS ,and made one of my patches at gerrit redundant. >> Why not enjoy the bug fixes? >> >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Laszlo Hornyak" >>>> To: "engine-devel" >>>> Cc: "Vojtech Szocs" >>>> Sent: Wednesday, July 18, 2012 5:43:34 PM >>>> Subject: java 1.6 compatibility no more? >>>> >>>> Hi, >>>> >>>> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >>>> Is this intentional? >>>> >>>> Laszlo >>>> _______________________________________________ >>>> 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 jhernand at redhat.com Thu Jul 19 11:41:26 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Thu, 19 Jul 2012 13:41:26 +0200 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <5007F1EF.6080508@redhat.com> References: <5007F1EF.6080508@redhat.com> Message-ID: <5007F266.50503@redhat.com> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>> Don't we need that (the source part) to avoid Java 7 syntax in GWT code? >> >> That's a very good point. >> >> In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. >> >> So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. >> >> We could do something like this: >> >> - let oVirt root POM declare source and target compliance to Java 7 >> - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) >> >> (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) >> >> What do you think? >> >> Vojtech > > +1 - I really like this idea! +1 from me as well. >> ----- Original Message ----- >> From: "Juan Hernandez" >> To: "Vojtech Szocs" >> Cc: "Yair Zaslavsky" , engine-devel at ovirt.org >> Sent: Thursday, July 19, 2012 11:01:00 AM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 07/19/2012 10:09 AM, Vojtech Szocs wrote: >>>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>>> DNS ,and made one of my patches at gerrit redundant. >>>> Why not enjoy the bug fixes? >>> >>> I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? >>> >>> If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. >>> >>> Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. >> >> Don't we need that (the source part) to avoid Java 7 syntax in GWT code? >> >>> ----- Original Message ----- >>> From: "Yair Zaslavsky" >>> To: engine-devel at ovirt.org >>> Sent: Thursday, July 19, 2012 7:59:45 AM >>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>> >>> On 07/18/2012 08:21 PM, Juan Hernandez wrote: >>>> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >>>>> In fact, for both backend and frontend, Maven effective POM contains: >>>>> >>>>> maven-compiler-plugin >>>>> >>>>> 1.6 >>>>> 1.6 >>>>> >>>>> >>>>> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) >>>> >>>> These maven settings just tell the java compiler to accept Java 6 syntax >>>> only and to generate a Java 6 compatible .class file format, but they >>>> don't restrict the set of APIs that can be used. >>>> >>>>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >>>>> >>>>> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >>>>> >>>>> Vojtech >>> >>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>> DNS ,and made one of my patches at gerrit redundant. >>> Why not enjoy the bug fixes? >>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "Laszlo Hornyak" >>>>> To: "engine-devel" >>>>> Cc: "Vojtech Szocs" >>>>> Sent: Wednesday, July 18, 2012 5:43:34 PM >>>>> Subject: java 1.6 compatibility no more? >>>>> >>>>> Hi, >>>>> >>>>> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >>>>> Is this intentional? >>>>> >>>>> Laszlo -- 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 lhornyak at redhat.com Thu Jul 19 12:04:17 2012 From: lhornyak at redhat.com (Laszlo Hornyak) Date: Thu, 19 Jul 2012 08:04:17 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <5007F266.50503@redhat.com> Message-ID: Hi, At the moment if you update the and settings of the compiler plugin to 1.7 in the root pom, the project will build fine, but some of the junit tests will fail. (some strange problem with bytecode manipulation see here http://code.google.com/p/powermock/issues/detail?id=355) Moving only the does not work, moving only the leaves the junit tests failing. So as you see I have rejected my own patch :-) http://gerrit.ovirt.org/6447/ Laszlo ----- Original Message ----- > From: "Juan Hernandez" > To: "Vojtech Szocs" > Cc: engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 1:41:26 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > > On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > >>> Don't we need that (the source part) to avoid Java 7 syntax in > >>> GWT code? > >> > >> That's a very good point. > >> > >> In general, GWT compiler supports Java 5 syntax (note that there > >> are no language changes between Java 5 and 6). For this reason, > >> our frontend code should be compliant with Java 5. If someone > >> uses new Java 7 language features in frontend code, GWT compiler > >> will throw an error and the build will fail. > >> > >> So the 'Java 5 only' limitation applies to frontend code and any > >> other code (e.g. shared modules) that is directly referenced by > >> frontend code. This shouldn't affect the backend, however. > >> > >> We could do something like this: > >> > >> - let oVirt root POM declare source and target compliance to Java > >> 7 > >> - let frontend modules POM (frontend/webadmin/modules/pom.xml) > >> declare source compliance to Java 5 (or 6) > >> > >> (note that target compliance can be left to Java 7 since frontend > >> compilation results in JavaScript code) > >> > >> What do you think? > >> > >> Vojtech > > > > +1 - I really like this idea! > > +1 from me as well. > > >> ----- Original Message ----- > >> From: "Juan Hernandez" > >> To: "Vojtech Szocs" > >> Cc: "Yair Zaslavsky" , engine-devel at ovirt.org > >> Sent: Thursday, July 19, 2012 11:01:00 AM > >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >> > >> On 07/19/2012 10:09 AM, Vojtech Szocs wrote: > >>>> As I previously emailed - JDK7 already fixed a known issue with > >>>> ldap and > >>>> DNS ,and made one of my patches at gerrit redundant. > >>>> Why not enjoy the bug fixes? > >>> > >>> I agree, but in that case, why not switch to '1.7' Java > >>> source/target compliance for oVirt Maven build as well? > >>> > >>> If JDK6 cannot be used for building oVirt (because of missing > >>> Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we > >>> should also update our Maven POM files. Currently, when I import > >>> oVirt projects into Eclipse (using Eclipse Maven plugin), I'm > >>> getting compile errors on 'bll' project. This is because our > >>> Maven POM files declare '1.6' Java source/target compliance. > >>> > >>> Juan - you are right, but for me, it sounds quite strange to have > >>> '1.6' Java source/target compliance for Maven build, and use > >>> JDK7 to do the build. > >> > >> Don't we need that (the source part) to avoid Java 7 syntax in GWT > >> code? > >> > >>> ----- Original Message ----- > >>> From: "Yair Zaslavsky" > >>> To: engine-devel at ovirt.org > >>> Sent: Thursday, July 19, 2012 7:59:45 AM > >>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>> > >>> On 07/18/2012 08:21 PM, Juan Hernandez wrote: > >>>> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: > >>>>> In fact, for both backend and frontend, Maven effective POM > >>>>> contains: > >>>>> > >>>>> maven-compiler-plugin > >>>>> > >>>>> 1.6 > >>>>> 1.6 > >>>>> > >>>>> > >>>>> Therefore, according to Maven POM files, oVirt should be > >>>>> build-able using Java 6, but it's not. (?) > >>>> > >>>> These maven settings just tell the java compiler to accept Java > >>>> 6 syntax > >>>> only and to generate a Java 6 compatible .class file format, but > >>>> they > >>>> don't restrict the set of APIs that can be used. > >>>> > >>>>> The problem is in backend/manager/modules/bll: > >>>>> StorageDomainCommandBase class uses new Java 7 Long.compare() > >>>>> static method. > >>>>> > >>>>> I think we should decide if we want to be compliant with Java > >>>>> 7, or submit a patch that uses Java 6 API (Long.compareTo > >>>>> instance method). > >>>>> > >>>>> Vojtech > >>> > >>> As I previously emailed - JDK7 already fixed a known issue with > >>> ldap and > >>> DNS ,and made one of my patches at gerrit redundant. > >>> Why not enjoy the bug fixes? > >>> > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>> From: "Laszlo Hornyak" > >>>>> To: "engine-devel" > >>>>> Cc: "Vojtech Szocs" > >>>>> Sent: Wednesday, July 18, 2012 5:43:34 PM > >>>>> Subject: java 1.6 compatibility no more? > >>>>> > >>>>> Hi, > >>>>> > >>>>> It may be a historic moment, but for a few hours oVirt engine > >>>>> is no longer building on java 1.6. > >>>>> Is this intentional? > >>>>> > >>>>> Laszlo > > > -- > 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. > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From lpeer at redhat.com Thu Jul 19 12:14:14 2012 From: lpeer at redhat.com (Livnat Peer) Date: Thu, 19 Jul 2012 15:14:14 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <5007F266.50503@redhat.com> References: <5007F1EF.6080508@redhat.com> <5007F266.50503@redhat.com> Message-ID: <5007FA16.7050407@redhat.com> On 19/07/12 14:41, Juan Hernandez wrote: > On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>> Don't we need that (the source part) to avoid Java 7 syntax in GWT code? >>> >>> That's a very good point. >>> >>> In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. >>> >>> So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. >>> >>> We could do something like this: >>> >>> - let oVirt root POM declare source and target compliance to Java 7 >>> - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) >>> >>> (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) >>> >>> What do you think? >>> >>> Vojtech >> >> +1 - I really like this idea! > > +1 from me as well. There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards) 1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago. 2. Are we using code syntax which is incompatible with JDK6? I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). There are two reason off the top of my head for that - If we find an issue it is easier to compare the issue on JDK6 vs. JDK7 if the code compiles on both. Open JDK7 is out for a year or so, It was packaged for fedora only in March 2012, I am not sure how ofter it is used in 'production' environment, I think we should at least keep ourself the option to roll-back in case we need it. Livnat > >>> ----- Original Message ----- >>> From: "Juan Hernandez" >>> To: "Vojtech Szocs" >>> Cc: "Yair Zaslavsky" , engine-devel at ovirt.org >>> Sent: Thursday, July 19, 2012 11:01:00 AM >>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>> >>> On 07/19/2012 10:09 AM, Vojtech Szocs wrote: >>>>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>>>> DNS ,and made one of my patches at gerrit redundant. >>>>> Why not enjoy the bug fixes? >>>> >>>> I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? >>>> >>>> If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. >>>> >>>> Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. >>> >>> Don't we need that (the source part) to avoid Java 7 syntax in GWT code? >>> >>>> ----- Original Message ----- >>>> From: "Yair Zaslavsky" >>>> To: engine-devel at ovirt.org >>>> Sent: Thursday, July 19, 2012 7:59:45 AM >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>> >>>> On 07/18/2012 08:21 PM, Juan Hernandez wrote: >>>>> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >>>>>> In fact, for both backend and frontend, Maven effective POM contains: >>>>>> >>>>>> maven-compiler-plugin >>>>>> >>>>>> 1.6 >>>>>> 1.6 >>>>>> >>>>>> >>>>>> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) >>>>> >>>>> These maven settings just tell the java compiler to accept Java 6 syntax >>>>> only and to generate a Java 6 compatible .class file format, but they >>>>> don't restrict the set of APIs that can be used. >>>>> >>>>>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >>>>>> >>>>>> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >>>>>> >>>>>> Vojtech >>>> >>>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>>> DNS ,and made one of my patches at gerrit redundant. >>>> Why not enjoy the bug fixes? >>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Laszlo Hornyak" >>>>>> To: "engine-devel" >>>>>> Cc: "Vojtech Szocs" >>>>>> Sent: Wednesday, July 18, 2012 5:43:34 PM >>>>>> Subject: java 1.6 compatibility no more? >>>>>> >>>>>> Hi, >>>>>> >>>>>> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >>>>>> Is this intentional? >>>>>> >>>>>> Laszlo > > From michal.skrivanek at redhat.com Thu Jul 19 12:19:06 2012 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Thu, 19 Jul 2012 14:19:06 +0200 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <5007FA16.7050407@redhat.com> References: <5007F1EF.6080508@redhat.com> <5007F266.50503@redhat.com> <5007FA16.7050407@redhat.com> Message-ID: On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > On 19/07/12 14:41, Juan Hernandez wrote: >> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>> Don't we need that (the source part) to avoid Java 7 syntax in GWT code? >>>> >>>> That's a very good point. >>>> >>>> In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. >>>> >>>> So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. >>>> >>>> We could do something like this: >>>> >>>> - let oVirt root POM declare source and target compliance to Java 7 >>>> - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) >>>> >>>> (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) >>>> >>>> What do you think? >>>> >>>> Vojtech >>> >>> +1 - I really like this idea! >> >> +1 from me as well. > > > There are two calls to make when it comes to JDK7 (regardless of GWT - > excuse me for taking this discussion some steps backwards) > > 1. Are we running with JRE 7? > The answer is yes we agreed on that a few months ago. > > 2. Are we using code syntax which is incompatible with JDK6? > > I think the answer to the above should be no (at least for now - maybe > until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them? > > There are two reason off the top of my head for that - > If we find an issue it is easier to compare the issue on JDK6 vs. JDK7 > if the code compiles on both. > > Open JDK7 is out for a year or so, It was packaged for fedora only in > March 2012, I am not sure how ofter it is used in 'production' > environment, I think we should at least keep ourself the option to > roll-back in case we need it. > > > Livnat > > > >> >>>> ----- Original Message ----- >>>> From: "Juan Hernandez" >>>> To: "Vojtech Szocs" >>>> Cc: "Yair Zaslavsky" , engine-devel at ovirt.org >>>> Sent: Thursday, July 19, 2012 11:01:00 AM >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>> >>>> On 07/19/2012 10:09 AM, Vojtech Szocs wrote: >>>>>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>>>>> DNS ,and made one of my patches at gerrit redundant. >>>>>> Why not enjoy the bug fixes? >>>>> >>>>> I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? >>>>> >>>>> If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. >>>>> >>>>> Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. >>>> >>>> Don't we need that (the source part) to avoid Java 7 syntax in GWT code? >>>> >>>>> ----- Original Message ----- >>>>> From: "Yair Zaslavsky" >>>>> To: engine-devel at ovirt.org >>>>> Sent: Thursday, July 19, 2012 7:59:45 AM >>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>>> >>>>> On 07/18/2012 08:21 PM, Juan Hernandez wrote: >>>>>> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >>>>>>> In fact, for both backend and frontend, Maven effective POM contains: >>>>>>> >>>>>>> maven-compiler-plugin >>>>>>> >>>>>>> 1.6 >>>>>>> 1.6 >>>>>>> >>>>>>> >>>>>>> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) >>>>>> >>>>>> These maven settings just tell the java compiler to accept Java 6 syntax >>>>>> only and to generate a Java 6 compatible .class file format, but they >>>>>> don't restrict the set of APIs that can be used. >>>>>> >>>>>>> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. >>>>>>> >>>>>>> I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). >>>>>>> >>>>>>> Vojtech >>>>> >>>>> As I previously emailed - JDK7 already fixed a known issue with ldap and >>>>> DNS ,and made one of my patches at gerrit redundant. >>>>> Why not enjoy the bug fixes? >>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Laszlo Hornyak" >>>>>>> To: "engine-devel" >>>>>>> Cc: "Vojtech Szocs" >>>>>>> Sent: Wednesday, July 18, 2012 5:43:34 PM >>>>>>> Subject: java 1.6 compatibility no more? >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. >>>>>>> Is this intentional? >>>>>>> >>>>>>> Laszlo >> >> > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From abaron at redhat.com Thu Jul 19 12:34:00 2012 From: abaron at redhat.com (Ayal Baron) Date: Thu, 19 Jul 2012 08:34:00 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: Message-ID: <517a5943-6b20-4b62-9a0f-559020764554@zmail13.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > > > On 19/07/12 14:41, Juan Hernandez wrote: > >> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > >>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > >>>>> Don't we need that (the source part) to avoid Java 7 syntax in > >>>>> GWT code? > >>>> > >>>> That's a very good point. > >>>> > >>>> In general, GWT compiler supports Java 5 syntax (note that there > >>>> are no language changes between Java 5 and 6). For this reason, > >>>> our frontend code should be compliant with Java 5. If someone > >>>> uses new Java 7 language features in frontend code, GWT > >>>> compiler will throw an error and the build will fail. > >>>> > >>>> So the 'Java 5 only' limitation applies to frontend code and any > >>>> other code (e.g. shared modules) that is directly referenced by > >>>> frontend code. This shouldn't affect the backend, however. > >>>> > >>>> We could do something like this: > >>>> > >>>> - let oVirt root POM declare source and target compliance to > >>>> Java 7 > >>>> - let frontend modules POM (frontend/webadmin/modules/pom.xml) > >>>> declare source compliance to Java 5 (or 6) > >>>> > >>>> (note that target compliance can be left to Java 7 since > >>>> frontend compilation results in JavaScript code) > >>>> > >>>> What do you think? > >>>> > >>>> Vojtech > >>> > >>> +1 - I really like this idea! > >> > >> +1 from me as well. > > > > > > There are two calls to make when it comes to JDK7 (regardless of > > GWT - > > excuse me for taking this discussion some steps backwards) > > > > 1. Are we running with JRE 7? > > The answer is yes we agreed on that a few months ago. > > > > 2. Are we using code syntax which is incompatible with JDK6? > > > > I think the answer to the above should be no (at least for now - > > maybe > > until the next ovirt release?). > +1 > exactly. Why starting with jdk6 incompatible constructs unless there > is a good (or at least any) reason for them? +1 > > > > > There are two reason off the top of my head for that - > > If we find an issue it is easier to compare the issue on JDK6 vs. > > JDK7 > > if the code compiles on both. > > > > Open JDK7 is out for a year or so, It was packaged for fedora only > > in > > March 2012, I am not sure how ofter it is used in 'production' > > environment, I think we should at least keep ourself the option to > > roll-back in case we need it. > > > > > > Livnat > > > > > > > >> > >>>> ----- Original Message ----- > >>>> From: "Juan Hernandez" > >>>> To: "Vojtech Szocs" > >>>> Cc: "Yair Zaslavsky" , > >>>> engine-devel at ovirt.org > >>>> Sent: Thursday, July 19, 2012 11:01:00 AM > >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>>> > >>>> On 07/19/2012 10:09 AM, Vojtech Szocs wrote: > >>>>>> As I previously emailed - JDK7 already fixed a known issue > >>>>>> with ldap and > >>>>>> DNS ,and made one of my patches at gerrit redundant. > >>>>>> Why not enjoy the bug fixes? > >>>>> > >>>>> I agree, but in that case, why not switch to '1.7' Java > >>>>> source/target compliance for oVirt Maven build as well? > >>>>> > >>>>> If JDK6 cannot be used for building oVirt (because of missing > >>>>> Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we > >>>>> should also update our Maven POM files. Currently, when I > >>>>> import oVirt projects into Eclipse (using Eclipse Maven > >>>>> plugin), I'm getting compile errors on 'bll' project. This is > >>>>> because our Maven POM files declare '1.6' Java source/target > >>>>> compliance. > >>>>> > >>>>> Juan - you are right, but for me, it sounds quite strange to > >>>>> have '1.6' Java source/target compliance for Maven build, and > >>>>> use JDK7 to do the build. > >>>> > >>>> Don't we need that (the source part) to avoid Java 7 syntax in > >>>> GWT code? > >>>> > >>>>> ----- Original Message ----- > >>>>> From: "Yair Zaslavsky" > >>>>> To: engine-devel at ovirt.org > >>>>> Sent: Thursday, July 19, 2012 7:59:45 AM > >>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>>>> > >>>>> On 07/18/2012 08:21 PM, Juan Hernandez wrote: > >>>>>> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: > >>>>>>> In fact, for both backend and frontend, Maven effective POM > >>>>>>> contains: > >>>>>>> > >>>>>>> maven-compiler-plugin > >>>>>>> > >>>>>>> 1.6 > >>>>>>> 1.6 > >>>>>>> > >>>>>>> > >>>>>>> Therefore, according to Maven POM files, oVirt should be > >>>>>>> build-able using Java 6, but it's not. (?) > >>>>>> > >>>>>> These maven settings just tell the java compiler to accept > >>>>>> Java 6 syntax > >>>>>> only and to generate a Java 6 compatible .class file format, > >>>>>> but they > >>>>>> don't restrict the set of APIs that can be used. > >>>>>> > >>>>>>> The problem is in backend/manager/modules/bll: > >>>>>>> StorageDomainCommandBase class uses new Java 7 > >>>>>>> Long.compare() static method. > >>>>>>> > >>>>>>> I think we should decide if we want to be compliant with Java > >>>>>>> 7, or submit a patch that uses Java 6 API (Long.compareTo > >>>>>>> instance method). > >>>>>>> > >>>>>>> Vojtech > >>>>> > >>>>> As I previously emailed - JDK7 already fixed a known issue with > >>>>> ldap and > >>>>> DNS ,and made one of my patches at gerrit redundant. > >>>>> Why not enjoy the bug fixes? > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>> From: "Laszlo Hornyak" > >>>>>>> To: "engine-devel" > >>>>>>> Cc: "Vojtech Szocs" > >>>>>>> Sent: Wednesday, July 18, 2012 5:43:34 PM > >>>>>>> Subject: java 1.6 compatibility no more? > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> It may be a historic moment, but for a few hours oVirt engine > >>>>>>> is no longer building on java 1.6. > >>>>>>> Is this intentional? > >>>>>>> > >>>>>>> Laszlo > >> > >> > > > > > > _______________________________________________ > > 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 vszocs at redhat.com Fri Jul 20 20:37:47 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 20 Jul 2012 16:37:47 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: Message-ID: <8ea8d76e-a6da-496c-808b-0ad1662ff0c9@zmail16.collab.prod.int.phx2.redhat.com> Hi guys, I've spent some time working on UI Plugins proof-of-concept (PoC) implementation, and thought I'd share my results with you. I've attached a patch that reflects the current progress. The actual PoC implementation takes some inspiration from oVirt UI Plugins wiki page, and simplifies/streamlines/improves its main concepts. The goal is to have simple-to-use, yet flexible and robust plugin infrastructure. Major changes to the original design are outlined below. Each UI plugin runs within the context of an iframe, and therefore requires a plugin source page that executes the actual plugin code. ? iframe is essentially the sandbox for each plugin. We can disable plugins by detaching their iframe elements from the main document during WebAdmin runtime. This also allows us to implement features such as plugin safe mode (no plugins loaded on WebAdmin startup). ? Plugin source pages and WebAdmin host page share the same origin (protocol, domain, port), with plugin source pages being served through EngineManager application server (JBoss AS). This is to avoid cross-domain window/iframe communication issues, when the actual plugin code running in an iframe tries to register itself into WebAdmin main document's pluginApi object. ? There's a servlet designed to render plugin source page for all plugins ( PluginSourcePageServlet ). For the given plugin, it detects its dependencies (3rd party JavaScript libraries) and configuration object (JSON data), reads the actual plugin code, and assembles everything into the resulting HTML page (to be evaluated by the plugin iframe). ? iframe isolates plugin dependencies (3rd party JavaScript libraries) from other plugins and the main WebAdmin document. In practice, this means that plugin A can use jQuery 1.7 and plugin B can use jQuery 1.6 without the fear of any clashes. ? Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear ), and point to GWT plugin application host page. The current PoC declares a simple plugin that gets loaded using hard-coded values in PluginSourcePageServlet . Actual plugin code registers the plugin into global pluginApi.plugins object, with one sample event handler function ( ActionButtonClick ). Just after that, the plugin reports in as ready by calling pluginApi.ready function. This essentially puts the plugin into use within WebAdmin. To simulate extension point (application event to be consumed by plugins), when the user clicks "New server" button on "Virtual Machines" main tab, ActionButtonClickEvent gets fired through WebAdmin event bus. PluginEventHandler receives this event and invokes ActionButtonClick event handler function on all plugins. (Note: for passing context objects from WebAdmin to plugin event handler functions, I'm planning to experiment with gwt-exporter project [1]. This would greatly simplify the way how WebAdmin exposes context-specific plugin API to event handler functions.) As for the next step, I suggest to have some meeting (conference) to discuss the PoC in detail, and outline tasks for the near future. Also, please let me know what you think of the PoC so far. Cheers, Vojtech [1] http://code.google.com/p/gwt-exporter/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WIP-UI-Plugins-PoC.patch Type: text/x-patch Size: 18528 bytes Desc: not available URL: From iheim at redhat.com Sat Jul 21 12:15:01 2012 From: iheim at redhat.com (Itamar Heim) Date: Sat, 21 Jul 2012 15:15:01 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <517a5943-6b20-4b62-9a0f-559020764554@zmail13.collab.prod.int.phx2.redhat.com> References: <517a5943-6b20-4b62-9a0f-559020764554@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <500A9D45.7020109@redhat.com> On 07/19/2012 03:34 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> >> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >> >>> On 19/07/12 14:41, Juan Hernandez wrote: >>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>> Don't we need that (the source part) to avoid Java 7 syntax in >>>>>>> GWT code? >>>>>> >>>>>> That's a very good point. >>>>>> >>>>>> In general, GWT compiler supports Java 5 syntax (note that there >>>>>> are no language changes between Java 5 and 6). For this reason, >>>>>> our frontend code should be compliant with Java 5. If someone >>>>>> uses new Java 7 language features in frontend code, GWT >>>>>> compiler will throw an error and the build will fail. >>>>>> >>>>>> So the 'Java 5 only' limitation applies to frontend code and any >>>>>> other code (e.g. shared modules) that is directly referenced by >>>>>> frontend code. This shouldn't affect the backend, however. >>>>>> >>>>>> We could do something like this: >>>>>> >>>>>> - let oVirt root POM declare source and target compliance to >>>>>> Java 7 >>>>>> - let frontend modules POM (frontend/webadmin/modules/pom.xml) >>>>>> declare source compliance to Java 5 (or 6) >>>>>> >>>>>> (note that target compliance can be left to Java 7 since >>>>>> frontend compilation results in JavaScript code) >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Vojtech >>>>> >>>>> +1 - I really like this idea! >>>> >>>> +1 from me as well. >>> >>> >>> There are two calls to make when it comes to JDK7 (regardless of >>> GWT - >>> excuse me for taking this discussion some steps backwards) >>> >>> 1. Are we running with JRE 7? >>> The answer is yes we agreed on that a few months ago. >>> >>> 2. Are we using code syntax which is incompatible with JDK6? >>> >>> I think the answer to the above should be no (at least for now - >>> maybe >>> until the next ovirt release?). >> +1 >> exactly. Why starting with jdk6 incompatible constructs unless there >> is a good (or at least any) reason for them? > > +1 +1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young. From lpeer at redhat.com Sun Jul 22 06:50:47 2012 From: lpeer at redhat.com (Livnat Peer) Date: Sun, 22 Jul 2012 09:50:47 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500A9D45.7020109@redhat.com> References: <517a5943-6b20-4b62-9a0f-559020764554@zmail13.collab.prod.int.phx2.redhat.com> <500A9D45.7020109@redhat.com> Message-ID: <500BA2C7.5080707@redhat.com> On 21/07/12 15:15, Itamar Heim wrote: > On 07/19/2012 03:34 PM, Ayal Baron wrote: >> >> >> ----- Original Message ----- >>> >>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>> >>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>> Don't we need that (the source part) to avoid Java 7 syntax in >>>>>>>> GWT code? >>>>>>> >>>>>>> That's a very good point. >>>>>>> >>>>>>> In general, GWT compiler supports Java 5 syntax (note that there >>>>>>> are no language changes between Java 5 and 6). For this reason, >>>>>>> our frontend code should be compliant with Java 5. If someone >>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>> compiler will throw an error and the build will fail. >>>>>>> >>>>>>> So the 'Java 5 only' limitation applies to frontend code and any >>>>>>> other code (e.g. shared modules) that is directly referenced by >>>>>>> frontend code. This shouldn't affect the backend, however. >>>>>>> >>>>>>> We could do something like this: >>>>>>> >>>>>>> - let oVirt root POM declare source and target compliance to >>>>>>> Java 7 >>>>>>> - let frontend modules POM (frontend/webadmin/modules/pom.xml) >>>>>>> declare source compliance to Java 5 (or 6) >>>>>>> >>>>>>> (note that target compliance can be left to Java 7 since >>>>>>> frontend compilation results in JavaScript code) >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Vojtech >>>>>> >>>>>> +1 - I really like this idea! >>>>> >>>>> +1 from me as well. >>>> >>>> >>>> There are two calls to make when it comes to JDK7 (regardless of >>>> GWT - >>>> excuse me for taking this discussion some steps backwards) >>>> >>>> 1. Are we running with JRE 7? >>>> The answer is yes we agreed on that a few months ago. >>>> >>>> 2. Are we using code syntax which is incompatible with JDK6? >>>> >>>> I think the answer to the above should be no (at least for now - >>>> maybe >>>> until the next ovirt release?). >>> +1 >>> exactly. Why starting with jdk6 incompatible constructs unless there >>> is a good (or at least any) reason for them? >> >> +1 > > +1 - there is merit keeping backward compatibility to allow comparing > behavior while java 7 is still young. Since no one objected, we'll go with JDK6 syntax compatibility for Now. Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase Thanks, Livnat > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From amureini at redhat.com Sun Jul 22 07:14:55 2012 From: amureini at redhat.com (Allon Mureinik) Date: Sun, 22 Jul 2012 03:14:55 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: Message-ID: <1765279660.322088.1342941295386.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Vojtech Szocs" > To: "Juan Hernandez" > Cc: engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 2:31:40 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > > Don't we need that (the source part) to avoid Java 7 syntax in GWT > > code? > > That's a very good point. > > In general, GWT compiler supports Java 5 syntax (note that there are > no language changes between Java 5 and 6). This may be nitpicking, but there is a difference: Java 6 allows the @Override annotation for implementing interfaces, while Java 5 restricts it to actual overrides. This is widely used throughout our code, at least in the backend side. > For this reason, our > frontend code should be compliant with Java 5. If someone uses new > Java 7 language features in frontend code, GWT compiler will throw > an error and the build will fail. > > So the 'Java 5 only' limitation applies to frontend code and any > other code (e.g. shared modules) that is directly referenced by > frontend code. This shouldn't affect the backend, however. > > We could do something like this: > > - let oVirt root POM declare source and target compliance to Java 7 > - let frontend modules POM (frontend/webadmin/modules/pom.xml) > declare source compliance to Java 5 (or 6) > > (note that target compliance can be left to Java 7 since frontend > compilation results in JavaScript code) > > What do you think? > > Vojtech > > > ----- Original Message ----- > From: "Juan Hernandez" > To: "Vojtech Szocs" > Cc: "Yair Zaslavsky" , engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 11:01:00 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/19/2012 10:09 AM, Vojtech Szocs wrote: > >> As I previously emailed - JDK7 already fixed a known issue with > >> ldap and > >> DNS ,and made one of my patches at gerrit redundant. > >> Why not enjoy the bug fixes? > > > > I agree, but in that case, why not switch to '1.7' Java > > source/target compliance for oVirt Maven build as well? > > > > If JDK6 cannot be used for building oVirt (because of missing Java > > 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also > > update our Maven POM files. Currently, when I import oVirt > > projects into Eclipse (using Eclipse Maven plugin), I'm getting > > compile errors on 'bll' project. This is because our Maven POM > > files declare '1.6' Java source/target compliance. > > > > Juan - you are right, but for me, it sounds quite strange to have > > '1.6' Java source/target compliance for Maven build, and use JDK7 > > to do the build. > > Don't we need that (the source part) to avoid Java 7 syntax in GWT > code? > > > ----- Original Message ----- > > From: "Yair Zaslavsky" > > To: engine-devel at ovirt.org > > Sent: Thursday, July 19, 2012 7:59:45 AM > > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > > > On 07/18/2012 08:21 PM, Juan Hernandez wrote: > >> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: > >>> In fact, for both backend and frontend, Maven effective POM > >>> contains: > >>> > >>> maven-compiler-plugin > >>> > >>> 1.6 > >>> 1.6 > >>> > >>> > >>> Therefore, according to Maven POM files, oVirt should be > >>> build-able using Java 6, but it's not. (?) > >> > >> These maven settings just tell the java compiler to accept Java 6 > >> syntax > >> only and to generate a Java 6 compatible .class file format, but > >> they > >> don't restrict the set of APIs that can be used. > >> > >>> The problem is in backend/manager/modules/bll: > >>> StorageDomainCommandBase class uses new Java 7 Long.compare() > >>> static method. > >>> > >>> I think we should decide if we want to be compliant with Java 7, > >>> or submit a patch that uses Java 6 API (Long.compareTo instance > >>> method). > >>> > >>> Vojtech > > > > As I previously emailed - JDK7 already fixed a known issue with > > ldap and > > DNS ,and made one of my patches at gerrit redundant. > > Why not enjoy the bug fixes? > > > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Laszlo Hornyak" > >>> To: "engine-devel" > >>> Cc: "Vojtech Szocs" > >>> Sent: Wednesday, July 18, 2012 5:43:34 PM > >>> Subject: java 1.6 compatibility no more? > >>> > >>> Hi, > >>> > >>> It may be a historic moment, but for a few hours oVirt engine is > >>> no longer building on java 1.6. > >>> Is this intentional? > >>> > >>> Laszlo > >>> _______________________________________________ > >>> 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 > > > > > -- > 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. > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From amureini at redhat.com Sun Jul 22 08:07:37 2012 From: amureini at redhat.com (Allon Mureinik) Date: Sun, 22 Jul 2012 04:07:37 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: Message-ID: <1828825011.333871.1342944457493.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Laszlo Hornyak" > To: "Juan Hernandez" > Cc: engine-devel at ovirt.org > Sent: Thursday, July 19, 2012 3:04:17 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > Hi, > > At the moment if you update the and settings of the > compiler plugin to 1.7 in the root pom, the project will build fine, > but some of the junit tests will fail. (some strange problem with > bytecode manipulation see here > http://code.google.com/p/powermock/issues/detail?id=355) The real solution for this is to stop using powermock, an effort we've been pursuing for the last couple of months. After merging a couple more patches that were already approved and just waiting for merge on the subject (http://gerrit.ovirt.org/#/c/6280/ && http://gerrit.ovirt.org/#/c/6392/ - if one of the maintainers can lend a hand), we remain with two failures which both originate from the same place: org.ovirt.engine.api.restapi.resource.BackendResourceDebugDetailTest org.ovirt.engine.api.restapi.resource.BackendResourceInfoDetailTest Both of these failures are due to powermocking in AbstractBackendResourceLoggingTest. Basically, this test is used for testing that the logging in BaseBackendResource.detail(Throwable) method is done properly. Not sure how useful this is (perhaps someone more familiar with REST-API can shed some insight?), but if this is the only thing preventing us from moving to jdk-7... well.. > Moving only the does not work, moving only the > leaves the junit tests failing. > > So as you see I have rejected my own patch :-) > http://gerrit.ovirt.org/6447/ > > Laszlo > > ----- Original Message ----- > > From: "Juan Hernandez" > > To: "Vojtech Szocs" > > Cc: engine-devel at ovirt.org > > Sent: Thursday, July 19, 2012 1:41:26 PM > > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > > > On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > > > On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > > >>> Don't we need that (the source part) to avoid Java 7 syntax in > > >>> GWT code? > > >> > > >> That's a very good point. > > >> > > >> In general, GWT compiler supports Java 5 syntax (note that there > > >> are no language changes between Java 5 and 6). For this reason, > > >> our frontend code should be compliant with Java 5. If someone > > >> uses new Java 7 language features in frontend code, GWT compiler > > >> will throw an error and the build will fail. > > >> > > >> So the 'Java 5 only' limitation applies to frontend code and any > > >> other code (e.g. shared modules) that is directly referenced by > > >> frontend code. This shouldn't affect the backend, however. > > >> > > >> We could do something like this: > > >> > > >> - let oVirt root POM declare source and target compliance to > > >> Java > > >> 7 > > >> - let frontend modules POM (frontend/webadmin/modules/pom.xml) > > >> declare source compliance to Java 5 (or 6) > > >> > > >> (note that target compliance can be left to Java 7 since > > >> frontend > > >> compilation results in JavaScript code) > > >> > > >> What do you think? > > >> > > >> Vojtech > > > > > > +1 - I really like this idea! > > > > +1 from me as well. > > > > >> ----- Original Message ----- > > >> From: "Juan Hernandez" > > >> To: "Vojtech Szocs" > > >> Cc: "Yair Zaslavsky" , > > >> engine-devel at ovirt.org > > >> Sent: Thursday, July 19, 2012 11:01:00 AM > > >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > >> > > >> On 07/19/2012 10:09 AM, Vojtech Szocs wrote: > > >>>> As I previously emailed - JDK7 already fixed a known issue > > >>>> with > > >>>> ldap and > > >>>> DNS ,and made one of my patches at gerrit redundant. > > >>>> Why not enjoy the bug fixes? > > >>> > > >>> I agree, but in that case, why not switch to '1.7' Java > > >>> source/target compliance for oVirt Maven build as well? > > >>> > > >>> If JDK6 cannot be used for building oVirt (because of missing > > >>> Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we > > >>> should also update our Maven POM files. Currently, when I > > >>> import > > >>> oVirt projects into Eclipse (using Eclipse Maven plugin), I'm > > >>> getting compile errors on 'bll' project. This is because our > > >>> Maven POM files declare '1.6' Java source/target compliance. > > >>> > > >>> Juan - you are right, but for me, it sounds quite strange to > > >>> have > > >>> '1.6' Java source/target compliance for Maven build, and use > > >>> JDK7 to do the build. > > >> > > >> Don't we need that (the source part) to avoid Java 7 syntax in > > >> GWT > > >> code? > > >> > > >>> ----- Original Message ----- > > >>> From: "Yair Zaslavsky" > > >>> To: engine-devel at ovirt.org > > >>> Sent: Thursday, July 19, 2012 7:59:45 AM > > >>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > >>> > > >>> On 07/18/2012 08:21 PM, Juan Hernandez wrote: > > >>>> On 07/18/2012 06:33 PM, Vojtech Szocs wrote: > > >>>>> In fact, for both backend and frontend, Maven effective POM > > >>>>> contains: > > >>>>> > > >>>>> maven-compiler-plugin > > >>>>> > > >>>>> 1.6 > > >>>>> 1.6 > > >>>>> > > >>>>> > > >>>>> Therefore, according to Maven POM files, oVirt should be > > >>>>> build-able using Java 6, but it's not. (?) > > >>>> > > >>>> These maven settings just tell the java compiler to accept > > >>>> Java > > >>>> 6 syntax > > >>>> only and to generate a Java 6 compatible .class file format, > > >>>> but > > >>>> they > > >>>> don't restrict the set of APIs that can be used. > > >>>> > > >>>>> The problem is in backend/manager/modules/bll: > > >>>>> StorageDomainCommandBase class uses new Java 7 Long.compare() > > >>>>> static method. > > >>>>> > > >>>>> I think we should decide if we want to be compliant with Java > > >>>>> 7, or submit a patch that uses Java 6 API (Long.compareTo > > >>>>> instance method). > > >>>>> > > >>>>> Vojtech > > >>> > > >>> As I previously emailed - JDK7 already fixed a known issue with > > >>> ldap and > > >>> DNS ,and made one of my patches at gerrit redundant. > > >>> Why not enjoy the bug fixes? > > >>> > > >>>>> > > >>>>> > > >>>>> ----- Original Message ----- > > >>>>> From: "Laszlo Hornyak" > > >>>>> To: "engine-devel" > > >>>>> Cc: "Vojtech Szocs" > > >>>>> Sent: Wednesday, July 18, 2012 5:43:34 PM > > >>>>> Subject: java 1.6 compatibility no more? > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> It may be a historic moment, but for a few hours oVirt engine > > >>>>> is no longer building on java 1.6. > > >>>>> Is this intentional? > > >>>>> > > >>>>> Laszlo > > > > > > -- > > 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. > > > > > > _______________________________________________ > > 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 amureini at redhat.com Sun Jul 22 16:38:19 2012 From: amureini at redhat.com (Allon Mureinik) Date: Sun, 22 Jul 2012 12:38:19 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500BA2C7.5080707@redhat.com> Message-ID: <1801643106.454424.1342975099196.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Livnat Peer" > To: "Itamar Heim" , "Michael Kublin" > Cc: "Juan Hernandez" , engine-devel at ovirt.org > Sent: Sunday, July 22, 2012 9:50:47 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 21/07/12 15:15, Itamar Heim wrote: > > On 07/19/2012 03:34 PM, Ayal Baron wrote: > >> > >> > >> ----- Original Message ----- > >>> > >>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > >>> > >>>> On 19/07/12 14:41, Juan Hernandez wrote: > >>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > >>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > >>>>>>>> Don't we need that (the source part) to avoid Java 7 syntax > >>>>>>>> in > >>>>>>>> GWT code? > >>>>>>> > >>>>>>> That's a very good point. > >>>>>>> > >>>>>>> In general, GWT compiler supports Java 5 syntax (note that > >>>>>>> there > >>>>>>> are no language changes between Java 5 and 6). For this > >>>>>>> reason, > >>>>>>> our frontend code should be compliant with Java 5. If someone > >>>>>>> uses new Java 7 language features in frontend code, GWT > >>>>>>> compiler will throw an error and the build will fail. > >>>>>>> > >>>>>>> So the 'Java 5 only' limitation applies to frontend code and > >>>>>>> any > >>>>>>> other code (e.g. shared modules) that is directly referenced > >>>>>>> by > >>>>>>> frontend code. This shouldn't affect the backend, however. > >>>>>>> > >>>>>>> We could do something like this: > >>>>>>> > >>>>>>> - let oVirt root POM declare source and target compliance to > >>>>>>> Java 7 > >>>>>>> - let frontend modules POM > >>>>>>> (frontend/webadmin/modules/pom.xml) > >>>>>>> declare source compliance to Java 5 (or 6) > >>>>>>> > >>>>>>> (note that target compliance can be left to Java 7 since > >>>>>>> frontend compilation results in JavaScript code) > >>>>>>> > >>>>>>> What do you think? > >>>>>>> > >>>>>>> Vojtech > >>>>>> > >>>>>> +1 - I really like this idea! > >>>>> > >>>>> +1 from me as well. > >>>> > >>>> > >>>> There are two calls to make when it comes to JDK7 (regardless of > >>>> GWT - > >>>> excuse me for taking this discussion some steps backwards) > >>>> > >>>> 1. Are we running with JRE 7? > >>>> The answer is yes we agreed on that a few months ago. > >>>> > >>>> 2. Are we using code syntax which is incompatible with JDK6? > >>>> > >>>> I think the answer to the above should be no (at least for now - > >>>> maybe > >>>> until the next ovirt release?). > >>> +1 > >>> exactly. Why starting with jdk6 incompatible constructs unless > >>> there > >>> is a good (or at least any) reason for them? > >> > >> +1 > > > > +1 - there is merit keeping backward compatibility to allow > > comparing > > behavior while java 7 is still young. > > Since no one objected, we'll go with JDK6 syntax compatibility for > Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things. Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523 comments welcome. > > Kublin - can you please send a patch to remove the usage of > Long.Compare > in StorageDomainCommandBase > > Thanks, Livnat > > > > _______________________________________________ > > 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 Sun Jul 22 16:41:00 2012 From: iheim at redhat.com (Itamar Heim) Date: Sun, 22 Jul 2012 19:41:00 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <1801643106.454424.1342975099196.JavaMail.root@redhat.com> References: <1801643106.454424.1342975099196.JavaMail.root@redhat.com> Message-ID: <500C2D1C.4090103@redhat.com> On 07/22/2012 07:38 PM, Allon Mureinik wrote: > > > ----- Original Message ----- >> From: "Livnat Peer" >> To: "Itamar Heim" , "Michael Kublin" >> Cc: "Juan Hernandez" , engine-devel at ovirt.org >> Sent: Sunday, July 22, 2012 9:50:47 AM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 21/07/12 15:15, Itamar Heim wrote: >>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> >>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>> >>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>> Don't we need that (the source part) to avoid Java 7 syntax >>>>>>>>>> in >>>>>>>>>> GWT code? >>>>>>>>> >>>>>>>>> That's a very good point. >>>>>>>>> >>>>>>>>> In general, GWT compiler supports Java 5 syntax (note that >>>>>>>>> there >>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>> reason, >>>>>>>>> our frontend code should be compliant with Java 5. If someone >>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>> >>>>>>>>> So the 'Java 5 only' limitation applies to frontend code and >>>>>>>>> any >>>>>>>>> other code (e.g. shared modules) that is directly referenced >>>>>>>>> by >>>>>>>>> frontend code. This shouldn't affect the backend, however. >>>>>>>>> >>>>>>>>> We could do something like this: >>>>>>>>> >>>>>>>>> - let oVirt root POM declare source and target compliance to >>>>>>>>> Java 7 >>>>>>>>> - let frontend modules POM >>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>> >>>>>>>>> (note that target compliance can be left to Java 7 since >>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Vojtech >>>>>>>> >>>>>>>> +1 - I really like this idea! >>>>>>> >>>>>>> +1 from me as well. >>>>>> >>>>>> >>>>>> There are two calls to make when it comes to JDK7 (regardless of >>>>>> GWT - >>>>>> excuse me for taking this discussion some steps backwards) >>>>>> >>>>>> 1. Are we running with JRE 7? >>>>>> The answer is yes we agreed on that a few months ago. >>>>>> >>>>>> 2. Are we using code syntax which is incompatible with JDK6? >>>>>> >>>>>> I think the answer to the above should be no (at least for now - >>>>>> maybe >>>>>> until the next ovirt release?). >>>>> +1 >>>>> exactly. Why starting with jdk6 incompatible constructs unless >>>>> there >>>>> is a good (or at least any) reason for them? >>>> >>>> +1 >>> >>> +1 - there is merit keeping backward compatibility to allow >>> comparing >>> behavior while java 7 is still young. >> >> Since no one objected, we'll go with JDK6 syntax compatibility for >> Now. > I'm a very small fan of enforcing policy by reviewers. > Not that the community reviews aren't great - but people miss things. > > Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: > http://gerrit.ovirt.org/#/c/6523 we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side. > > comments welcome. > >> >> Kublin - can you please send a patch to remove the usage of >> Long.Compare >> in StorageDomainCommandBase >> >> Thanks, Livnat >> >> >>> _______________________________________________ >>> 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 abaron at redhat.com Sun Jul 22 17:34:32 2012 From: abaron at redhat.com (Ayal Baron) Date: Sun, 22 Jul 2012 13:34:32 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500C2D1C.4090103@redhat.com> Message-ID: <649975356.116519.1342978472277.JavaMail.root@redhat.com> ----- Original Message ----- > On 07/22/2012 07:38 PM, Allon Mureinik wrote: > > > > > > ----- Original Message ----- > >> From: "Livnat Peer" > >> To: "Itamar Heim" , "Michael Kublin" > >> > >> Cc: "Juan Hernandez" , engine-devel at ovirt.org > >> Sent: Sunday, July 22, 2012 9:50:47 AM > >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >> > >> On 21/07/12 15:15, Itamar Heim wrote: > >>> On 07/19/2012 03:34 PM, Ayal Baron wrote: > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> > >>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > >>>>> > >>>>>> On 19/07/12 14:41, Juan Hernandez wrote: > >>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > >>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > >>>>>>>>>> Don't we need that (the source part) to avoid Java 7 > >>>>>>>>>> syntax > >>>>>>>>>> in > >>>>>>>>>> GWT code? > >>>>>>>>> > >>>>>>>>> That's a very good point. > >>>>>>>>> > >>>>>>>>> In general, GWT compiler supports Java 5 syntax (note that > >>>>>>>>> there > >>>>>>>>> are no language changes between Java 5 and 6). For this > >>>>>>>>> reason, > >>>>>>>>> our frontend code should be compliant with Java 5. If > >>>>>>>>> someone > >>>>>>>>> uses new Java 7 language features in frontend code, GWT > >>>>>>>>> compiler will throw an error and the build will fail. > >>>>>>>>> > >>>>>>>>> So the 'Java 5 only' limitation applies to frontend code > >>>>>>>>> and > >>>>>>>>> any > >>>>>>>>> other code (e.g. shared modules) that is directly > >>>>>>>>> referenced > >>>>>>>>> by > >>>>>>>>> frontend code. This shouldn't affect the backend, however. > >>>>>>>>> > >>>>>>>>> We could do something like this: > >>>>>>>>> > >>>>>>>>> - let oVirt root POM declare source and target compliance > >>>>>>>>> to > >>>>>>>>> Java 7 > >>>>>>>>> - let frontend modules POM > >>>>>>>>> (frontend/webadmin/modules/pom.xml) > >>>>>>>>> declare source compliance to Java 5 (or 6) > >>>>>>>>> > >>>>>>>>> (note that target compliance can be left to Java 7 since > >>>>>>>>> frontend compilation results in JavaScript code) > >>>>>>>>> > >>>>>>>>> What do you think? > >>>>>>>>> > >>>>>>>>> Vojtech > >>>>>>>> > >>>>>>>> +1 - I really like this idea! > >>>>>>> > >>>>>>> +1 from me as well. > >>>>>> > >>>>>> > >>>>>> There are two calls to make when it comes to JDK7 (regardless > >>>>>> of > >>>>>> GWT - > >>>>>> excuse me for taking this discussion some steps backwards) > >>>>>> > >>>>>> 1. Are we running with JRE 7? > >>>>>> The answer is yes we agreed on that a few months ago. > >>>>>> > >>>>>> 2. Are we using code syntax which is incompatible with JDK6? > >>>>>> > >>>>>> I think the answer to the above should be no (at least for now > >>>>>> - > >>>>>> maybe > >>>>>> until the next ovirt release?). > >>>>> +1 > >>>>> exactly. Why starting with jdk6 incompatible constructs unless > >>>>> there > >>>>> is a good (or at least any) reason for them? > >>>> > >>>> +1 > >>> > >>> +1 - there is merit keeping backward compatibility to allow > >>> comparing > >>> behavior while java 7 is still young. > >> > >> Since no one objected, we'll go with JDK6 syntax compatibility for > >> Now. > > I'm a very small fan of enforcing policy by reviewers. > > Not that the community reviews aren't great - but people miss > > things. > > > > Here's my take on Maven's enforcer plugin to actually verify we > > aren't compiling with JDK 7: > > http://gerrit.ovirt.org/#/c/6523 > > we don't want to enforce compilation or run with JDK 6, only to > preserve > backward compatibility. > I'm for jenkins to have a job to compile and run unitests with > openjdk 6 > to be on the safe side. > Instead of enforcing the compilation to be run with a specific jdk we can enforce that the code is java 6 compatible with: org.apache.maven.plugins maven-compiler-plugin 2.0.2 1.6 1.6 > > > > comments welcome. > > > >> > >> Kublin - can you please send a patch to remove the usage of > >> Long.Compare > >> in StorageDomainCommandBase > >> > >> Thanks, Livnat > >> > >> > >>> _______________________________________________ > >>> 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 amureini at redhat.com Mon Jul 23 05:21:36 2012 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 23 Jul 2012 01:21:36 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <649975356.116519.1342978472277.JavaMail.root@redhat.com> Message-ID: <1025511555.633126.1343020896922.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ayal Baron" > To: "Itamar Heim" > Cc: "Juan Hernandez" , engine-devel at ovirt.org, "Allon Mureinik" > Sent: Sunday, July 22, 2012 8:34:32 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > > > ----- Original Message ----- > > On 07/22/2012 07:38 PM, Allon Mureinik wrote: > > > > > > > > > ----- Original Message ----- > > >> From: "Livnat Peer" > > >> To: "Itamar Heim" , "Michael Kublin" > > >> > > >> Cc: "Juan Hernandez" , > > >> engine-devel at ovirt.org > > >> Sent: Sunday, July 22, 2012 9:50:47 AM > > >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > >> > > >> On 21/07/12 15:15, Itamar Heim wrote: > > >>> On 07/19/2012 03:34 PM, Ayal Baron wrote: > > >>>> > > >>>> > > >>>> ----- Original Message ----- > > >>>>> > > >>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > > >>>>> > > >>>>>> On 19/07/12 14:41, Juan Hernandez wrote: > > >>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > > >>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > > >>>>>>>>>> Don't we need that (the source part) to avoid Java 7 > > >>>>>>>>>> syntax > > >>>>>>>>>> in > > >>>>>>>>>> GWT code? > > >>>>>>>>> > > >>>>>>>>> That's a very good point. > > >>>>>>>>> > > >>>>>>>>> In general, GWT compiler supports Java 5 syntax (note > > >>>>>>>>> that > > >>>>>>>>> there > > >>>>>>>>> are no language changes between Java 5 and 6). For this > > >>>>>>>>> reason, > > >>>>>>>>> our frontend code should be compliant with Java 5. If > > >>>>>>>>> someone > > >>>>>>>>> uses new Java 7 language features in frontend code, GWT > > >>>>>>>>> compiler will throw an error and the build will fail. > > >>>>>>>>> > > >>>>>>>>> So the 'Java 5 only' limitation applies to frontend code > > >>>>>>>>> and > > >>>>>>>>> any > > >>>>>>>>> other code (e.g. shared modules) that is directly > > >>>>>>>>> referenced > > >>>>>>>>> by > > >>>>>>>>> frontend code. This shouldn't affect the backend, > > >>>>>>>>> however. > > >>>>>>>>> > > >>>>>>>>> We could do something like this: > > >>>>>>>>> > > >>>>>>>>> - let oVirt root POM declare source and target compliance > > >>>>>>>>> to > > >>>>>>>>> Java 7 > > >>>>>>>>> - let frontend modules POM > > >>>>>>>>> (frontend/webadmin/modules/pom.xml) > > >>>>>>>>> declare source compliance to Java 5 (or 6) > > >>>>>>>>> > > >>>>>>>>> (note that target compliance can be left to Java 7 since > > >>>>>>>>> frontend compilation results in JavaScript code) > > >>>>>>>>> > > >>>>>>>>> What do you think? > > >>>>>>>>> > > >>>>>>>>> Vojtech > > >>>>>>>> > > >>>>>>>> +1 - I really like this idea! > > >>>>>>> > > >>>>>>> +1 from me as well. > > >>>>>> > > >>>>>> > > >>>>>> There are two calls to make when it comes to JDK7 > > >>>>>> (regardless > > >>>>>> of > > >>>>>> GWT - > > >>>>>> excuse me for taking this discussion some steps backwards) > > >>>>>> > > >>>>>> 1. Are we running with JRE 7? > > >>>>>> The answer is yes we agreed on that a few months ago. > > >>>>>> > > >>>>>> 2. Are we using code syntax which is incompatible with JDK6? > > >>>>>> > > >>>>>> I think the answer to the above should be no (at least for > > >>>>>> now > > >>>>>> - > > >>>>>> maybe > > >>>>>> until the next ovirt release?). > > >>>>> +1 > > >>>>> exactly. Why starting with jdk6 incompatible constructs > > >>>>> unless > > >>>>> there > > >>>>> is a good (or at least any) reason for them? > > >>>> > > >>>> +1 > > >>> > > >>> +1 - there is merit keeping backward compatibility to allow > > >>> comparing > > >>> behavior while java 7 is still young. > > >> > > >> Since no one objected, we'll go with JDK6 syntax compatibility > > >> for > > >> Now. > > > I'm a very small fan of enforcing policy by reviewers. > > > Not that the community reviews aren't great - but people miss > > > things. > > > > > > Here's my take on Maven's enforcer plugin to actually verify we > > > aren't compiling with JDK 7: > > > http://gerrit.ovirt.org/#/c/6523 > > > > we don't want to enforce compilation or run with JDK 6, only to > > preserve > > backward compatibility. > > I'm for jenkins to have a job to compile and run unitests with > > openjdk 6 > > to be on the safe side. > > > > Instead of enforcing the compilation to be run with a specific jdk we > can enforce that the code is java 6 compatible with: > > > org.apache.maven.plugins > maven-compiler-plugin > 2.0.2 > > 1.6 > 1.6 > > No, this is not the issue we're discussing. The source and target configurations in the maven-compiler-plugin specify the language level compatibility (i.e., syntax) you're using. This setting only means you won't be able to use Java 7 new syntactic constructs like catching multiple exceptions with the pipe operator and shorthand generics. This has nothing to do with the JDK. The JDK is just a collection of jars, like any other jar, which just happen to contain some fundamental classes like Object, String and Long. Our case here is to force developers not use any methods/classes that aren't present in /JDK 6/. Just to prove the point - if you take a look at lines 367-368 of the master pom.xml, you'll notice we already have these settings, and have had them since oVirt's git repo was created. > > > > > > > > comments welcome. > > > > > >> > > >> Kublin - can you please send a patch to remove the usage of > > >> Long.Compare > > >> in StorageDomainCommandBase > > >> > > >> Thanks, Livnat > > >> > > >> > > >>> _______________________________________________ > > >>> 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 amureini at redhat.com Mon Jul 23 05:29:12 2012 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 23 Jul 2012 01:29:12 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500C2D1C.4090103@redhat.com> Message-ID: <982888567.633871.1343021352535.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Allon Mureinik" > Cc: "Livnat Peer" , "Juan Hernandez" , engine-devel at ovirt.org, "Michael > Kublin" > Sent: Sunday, July 22, 2012 7:41:00 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/22/2012 07:38 PM, Allon Mureinik wrote: > > > > > > ----- Original Message ----- > >> From: "Livnat Peer" > >> To: "Itamar Heim" , "Michael Kublin" > >> > >> Cc: "Juan Hernandez" , engine-devel at ovirt.org > >> Sent: Sunday, July 22, 2012 9:50:47 AM > >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >> > >> On 21/07/12 15:15, Itamar Heim wrote: > >>> On 07/19/2012 03:34 PM, Ayal Baron wrote: > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> > >>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > >>>>> > >>>>>> On 19/07/12 14:41, Juan Hernandez wrote: > >>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > >>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > >>>>>>>>>> Don't we need that (the source part) to avoid Java 7 > >>>>>>>>>> syntax > >>>>>>>>>> in > >>>>>>>>>> GWT code? > >>>>>>>>> > >>>>>>>>> That's a very good point. > >>>>>>>>> > >>>>>>>>> In general, GWT compiler supports Java 5 syntax (note that > >>>>>>>>> there > >>>>>>>>> are no language changes between Java 5 and 6). For this > >>>>>>>>> reason, > >>>>>>>>> our frontend code should be compliant with Java 5. If > >>>>>>>>> someone > >>>>>>>>> uses new Java 7 language features in frontend code, GWT > >>>>>>>>> compiler will throw an error and the build will fail. > >>>>>>>>> > >>>>>>>>> So the 'Java 5 only' limitation applies to frontend code > >>>>>>>>> and > >>>>>>>>> any > >>>>>>>>> other code (e.g. shared modules) that is directly > >>>>>>>>> referenced > >>>>>>>>> by > >>>>>>>>> frontend code. This shouldn't affect the backend, however. > >>>>>>>>> > >>>>>>>>> We could do something like this: > >>>>>>>>> > >>>>>>>>> - let oVirt root POM declare source and target compliance > >>>>>>>>> to > >>>>>>>>> Java 7 > >>>>>>>>> - let frontend modules POM > >>>>>>>>> (frontend/webadmin/modules/pom.xml) > >>>>>>>>> declare source compliance to Java 5 (or 6) > >>>>>>>>> > >>>>>>>>> (note that target compliance can be left to Java 7 since > >>>>>>>>> frontend compilation results in JavaScript code) > >>>>>>>>> > >>>>>>>>> What do you think? > >>>>>>>>> > >>>>>>>>> Vojtech > >>>>>>>> > >>>>>>>> +1 - I really like this idea! > >>>>>>> > >>>>>>> +1 from me as well. > >>>>>> > >>>>>> > >>>>>> There are two calls to make when it comes to JDK7 (regardless > >>>>>> of > >>>>>> GWT - > >>>>>> excuse me for taking this discussion some steps backwards) > >>>>>> > >>>>>> 1. Are we running with JRE 7? > >>>>>> The answer is yes we agreed on that a few months ago. > >>>>>> > >>>>>> 2. Are we using code syntax which is incompatible with JDK6? > >>>>>> > >>>>>> I think the answer to the above should be no (at least for now > >>>>>> - > >>>>>> maybe > >>>>>> until the next ovirt release?). > >>>>> +1 > >>>>> exactly. Why starting with jdk6 incompatible constructs unless > >>>>> there > >>>>> is a good (or at least any) reason for them? > >>>> > >>>> +1 > >>> > >>> +1 - there is merit keeping backward compatibility to allow > >>> comparing > >>> behavior while java 7 is still young. > >> > >> Since no one objected, we'll go with JDK6 syntax compatibility for > >> Now. > > I'm a very small fan of enforcing policy by reviewers. > > Not that the community reviews aren't great - but people miss > > things. > > > > Here's my take on Maven's enforcer plugin to actually verify we > > aren't compiling with JDK 7: > > http://gerrit.ovirt.org/#/c/6523 > > we don't want to enforce compilation or run with JDK 6, only to > preserve > backward compatibility. > I'm for jenkins to have a job to compile and run unitests with > openjdk 6 > to be on the safe side. I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it. To me, this sounds a lot like enforcing JDK 6 compatibility. /today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided. > > > > > comments welcome. > > > >> > >> Kublin - can you please send a patch to remove the usage of > >> Long.Compare > >> in StorageDomainCommandBase > >> > >> Thanks, Livnat > >> > >> > >>> _______________________________________________ > >>> 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 Jul 23 05:43:02 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 23 Jul 2012 08:43:02 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <982888567.633871.1343021352535.JavaMail.root@redhat.com> References: <982888567.633871.1343021352535.JavaMail.root@redhat.com> Message-ID: <500CE466.9030809@redhat.com> On 07/23/2012 08:29 AM, Allon Mureinik wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Allon Mureinik" >> Cc: "Livnat Peer" , "Juan Hernandez" , engine-devel at ovirt.org, "Michael >> Kublin" >> Sent: Sunday, July 22, 2012 7:41:00 PM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 07/22/2012 07:38 PM, Allon Mureinik wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Livnat Peer" >>>> To: "Itamar Heim" , "Michael Kublin" >>>> >>>> Cc: "Juan Hernandez" , engine-devel at ovirt.org >>>> Sent: Sunday, July 22, 2012 9:50:47 AM >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>> >>>> On 21/07/12 15:15, Itamar Heim wrote: >>>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> >>>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>>>> >>>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>>>> syntax >>>>>>>>>>>> in >>>>>>>>>>>> GWT code? >>>>>>>>>>> >>>>>>>>>>> That's a very good point. >>>>>>>>>>> >>>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note that >>>>>>>>>>> there >>>>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>>>> reason, >>>>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>>>> someone >>>>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>>>> >>>>>>>>>>> So the 'Java 5 only' limitation applies to frontend code >>>>>>>>>>> and >>>>>>>>>>> any >>>>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>>>> referenced >>>>>>>>>>> by >>>>>>>>>>> frontend code. This shouldn't affect the backend, however. >>>>>>>>>>> >>>>>>>>>>> We could do something like this: >>>>>>>>>>> >>>>>>>>>>> - let oVirt root POM declare source and target compliance >>>>>>>>>>> to >>>>>>>>>>> Java 7 >>>>>>>>>>> - let frontend modules POM >>>>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>>>> >>>>>>>>>>> (note that target compliance can be left to Java 7 since >>>>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Vojtech >>>>>>>>>> >>>>>>>>>> +1 - I really like this idea! >>>>>>>>> >>>>>>>>> +1 from me as well. >>>>>>>> >>>>>>>> >>>>>>>> There are two calls to make when it comes to JDK7 (regardless >>>>>>>> of >>>>>>>> GWT - >>>>>>>> excuse me for taking this discussion some steps backwards) >>>>>>>> >>>>>>>> 1. Are we running with JRE 7? >>>>>>>> The answer is yes we agreed on that a few months ago. >>>>>>>> >>>>>>>> 2. Are we using code syntax which is incompatible with JDK6? >>>>>>>> >>>>>>>> I think the answer to the above should be no (at least for now >>>>>>>> - >>>>>>>> maybe >>>>>>>> until the next ovirt release?). >>>>>>> +1 >>>>>>> exactly. Why starting with jdk6 incompatible constructs unless >>>>>>> there >>>>>>> is a good (or at least any) reason for them? >>>>>> >>>>>> +1 >>>>> >>>>> +1 - there is merit keeping backward compatibility to allow >>>>> comparing >>>>> behavior while java 7 is still young. >>>> >>>> Since no one objected, we'll go with JDK6 syntax compatibility for >>>> Now. >>> I'm a very small fan of enforcing policy by reviewers. >>> Not that the community reviews aren't great - but people miss >>> things. >>> >>> Here's my take on Maven's enforcer plugin to actually verify we >>> aren't compiling with JDK 7: >>> http://gerrit.ovirt.org/#/c/6523 >> >> we don't want to enforce compilation or run with JDK 6, only to >> preserve >> backward compatibility. >> I'm for jenkins to have a job to compile and run unitests with >> openjdk 6 >> to be on the safe side. > > I don't understand this suggestion. > What you're saying is that you can compile with whatever JDK you want, but: > - it won't compile with JDKs prior to 6, since we're using 6's features. > - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it. > > To me, this sounds a lot like enforcing JDK 6 compatibility. > its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. > /today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. > I fear this suggestion will just add to this "noise", and could easily be avoided. jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only. > >> >>> >>> comments welcome. >>> >>>> >>>> Kublin - can you please send a patch to remove the usage of >>>> Long.Compare >>>> in StorageDomainCommandBase >>>> >>>> Thanks, Livnat >>>> >>>> >>>>> _______________________________________________ >>>>> 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 Jul 23 07:10:07 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 23 Jul 2012 10:10:07 +0300 Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <8ea8d76e-a6da-496c-808b-0ad1662ff0c9@zmail16.collab.prod.int.phx2.redhat.com> References: <8ea8d76e-a6da-496c-808b-0ad1662ff0c9@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <500CF8CF.60500@redhat.com> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: > Last but not least, writing plugins in Google Web Toolkit (GWT) should > be as easy as providing your own plugin source page. Just deploy your > GWT plugin application on JBoss AS (next to engine.ear), and point to > GWT plugin application host page. this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins). From amureini at redhat.com Mon Jul 23 07:12:46 2012 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 23 Jul 2012 03:12:46 -0400 (EDT) Subject: [Engine-devel] No more forking in bll tests Message-ID: <1216037160.691964.1343027566004.JavaMail.root@redhat.com> Hi guys, This morning a couple of patches were merged to remove Gluster's dependency on PowerMock (Shireesh and Selvasundaram - thanks for your commitment and involvement!). Consequentially, there is no more need to fork bll's tests, so that too was removed. Currently, bll's full build runs in just under 3 minutes (on my machine), and just under a minute for the test suite alone, without re-compiling the entire module. Let's keep it this way - It is /NOT/ ok to add new usages of PowerMock. The few leftoveres that are still there are being examined, and the PowerMock dependency will be removed once they are also gone. Here's to speedy builds and agile development, Allon P.S. A mega-huge thanks to everyone that was involved in this effort - Laszlo, Mike, Omer, Shireesh, Selvasundaram, and anyone else I may have forgotten by mistake. From vszocs at redhat.com Mon Jul 23 09:40:15 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 23 Jul 2012 05:40:15 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <500CF8CF.60500@redhat.com> Message-ID: <615476766.2213173.1343036415685.JavaMail.root@redhat.com> > this implies server side code running on the engine, Actually, yes and no :) let me explain: - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" > which has additional implications on compatibility vs. ui plugins as discussed I don't think we need to worry about this :) If a GWT UI plugin web application needs to use Engine functionality, it can: - use REST API from within UI plugin (JavaScript) code [1] - use REST API from within its server-side (Java) code [2] [1] - will be supported by UI plugin infrastructure [2] - not supported by UI plugin infrastructure Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Vojtech Szocs" Cc: "engine-devel" , "Einav Cohen" Sent: Monday, July 23, 2012 9:10:07 AM Subject: Re: oVirt UI Plugins: Update on current progress On 07/20/2012 11:37 PM, Vojtech Szocs wrote: > Last but not least, writing plugins in Google Web Toolkit (GWT) should > be as easy as providing your own plugin source page. Just deploy your > GWT plugin application on JBoss AS (next to engine.ear), and point to > GWT plugin application host page. this implies server side code running on the engine, which has additional implications on compatibility vs. ui plugins as discussed so far which would be java script (I'm not against using GWT for them if the resulting java script can be packaged for use as a UI plugin, but sever side code i prefer to be isolated from engine until we'll define engine plugins). From amureini at redhat.com Mon Jul 23 09:46:30 2012 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 23 Jul 2012 05:46:30 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500CE466.9030809@redhat.com> Message-ID: <1818927661.888071.1343036790818.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Allon Mureinik" > Cc: "Livnat Peer" , "Juan Hernandez" , engine-devel at ovirt.org, "Michael > Kublin" > Sent: Monday, July 23, 2012 8:43:02 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/23/2012 08:29 AM, Allon Mureinik wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Allon Mureinik" > >> Cc: "Livnat Peer" , "Juan Hernandez" > >> , engine-devel at ovirt.org, "Michael > >> Kublin" > >> Sent: Sunday, July 22, 2012 7:41:00 PM > >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >> > >> On 07/22/2012 07:38 PM, Allon Mureinik wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Livnat Peer" > >>>> To: "Itamar Heim" , "Michael Kublin" > >>>> > >>>> Cc: "Juan Hernandez" , > >>>> engine-devel at ovirt.org > >>>> Sent: Sunday, July 22, 2012 9:50:47 AM > >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>>> > >>>> On 21/07/12 15:15, Itamar Heim wrote: > >>>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> > >>>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > >>>>>>> > >>>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: > >>>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > >>>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > >>>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 > >>>>>>>>>>>> syntax > >>>>>>>>>>>> in > >>>>>>>>>>>> GWT code? > >>>>>>>>>>> > >>>>>>>>>>> That's a very good point. > >>>>>>>>>>> > >>>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note > >>>>>>>>>>> that > >>>>>>>>>>> there > >>>>>>>>>>> are no language changes between Java 5 and 6). For this > >>>>>>>>>>> reason, > >>>>>>>>>>> our frontend code should be compliant with Java 5. If > >>>>>>>>>>> someone > >>>>>>>>>>> uses new Java 7 language features in frontend code, GWT > >>>>>>>>>>> compiler will throw an error and the build will fail. > >>>>>>>>>>> > >>>>>>>>>>> So the 'Java 5 only' limitation applies to frontend code > >>>>>>>>>>> and > >>>>>>>>>>> any > >>>>>>>>>>> other code (e.g. shared modules) that is directly > >>>>>>>>>>> referenced > >>>>>>>>>>> by > >>>>>>>>>>> frontend code. This shouldn't affect the backend, > >>>>>>>>>>> however. > >>>>>>>>>>> > >>>>>>>>>>> We could do something like this: > >>>>>>>>>>> > >>>>>>>>>>> - let oVirt root POM declare source and target compliance > >>>>>>>>>>> to > >>>>>>>>>>> Java 7 > >>>>>>>>>>> - let frontend modules POM > >>>>>>>>>>> (frontend/webadmin/modules/pom.xml) > >>>>>>>>>>> declare source compliance to Java 5 (or 6) > >>>>>>>>>>> > >>>>>>>>>>> (note that target compliance can be left to Java 7 since > >>>>>>>>>>> frontend compilation results in JavaScript code) > >>>>>>>>>>> > >>>>>>>>>>> What do you think? > >>>>>>>>>>> > >>>>>>>>>>> Vojtech > >>>>>>>>>> > >>>>>>>>>> +1 - I really like this idea! > >>>>>>>>> > >>>>>>>>> +1 from me as well. > >>>>>>>> > >>>>>>>> > >>>>>>>> There are two calls to make when it comes to JDK7 > >>>>>>>> (regardless > >>>>>>>> of > >>>>>>>> GWT - > >>>>>>>> excuse me for taking this discussion some steps backwards) > >>>>>>>> > >>>>>>>> 1. Are we running with JRE 7? > >>>>>>>> The answer is yes we agreed on that a few months ago. > >>>>>>>> > >>>>>>>> 2. Are we using code syntax which is incompatible with JDK6? > >>>>>>>> > >>>>>>>> I think the answer to the above should be no (at least for > >>>>>>>> now > >>>>>>>> - > >>>>>>>> maybe > >>>>>>>> until the next ovirt release?). > >>>>>>> +1 > >>>>>>> exactly. Why starting with jdk6 incompatible constructs > >>>>>>> unless > >>>>>>> there > >>>>>>> is a good (or at least any) reason for them? > >>>>>> > >>>>>> +1 > >>>>> > >>>>> +1 - there is merit keeping backward compatibility to allow > >>>>> comparing > >>>>> behavior while java 7 is still young. > >>>> > >>>> Since no one objected, we'll go with JDK6 syntax compatibility > >>>> for > >>>> Now. > >>> I'm a very small fan of enforcing policy by reviewers. > >>> Not that the community reviews aren't great - but people miss > >>> things. > >>> > >>> Here's my take on Maven's enforcer plugin to actually verify we > >>> aren't compiling with JDK 7: > >>> http://gerrit.ovirt.org/#/c/6523 > >> > >> we don't want to enforce compilation or run with JDK 6, only to > >> preserve > >> backward compatibility. > >> I'm for jenkins to have a job to compile and run unitests with > >> openjdk 6 > >> to be on the safe side. > > > > I don't understand this suggestion. > > What you're saying is that you can compile with whatever JDK you > > want, but: > > - it won't compile with JDKs prior to 6, since we're using 6's > > features. > > - you aren't allowed to use JDK 7 features, and if you do, you'll > > get an email from jenkins that you broke something and must fix > > it. > > > > To me, this sounds a lot like enforcing JDK 6 compatibility. > > > > its preserving jdk 6 compatibility for a few more months, not > enforcing > to use jdk 6 compiler. Fair enough. > > > /today/ if have way too many (i.e., >0) jenkins breaks, a lot of > > which could be avoided by not running with -DskipTetst or making > > sure to run with -Penable-dao-tests. > > I fear this suggestion will just add to this "noise", and could > > easily be avoided. > > jenkins breaks should be visible at patch level prior to commit, > something we are trying to resolve by adding more hardware to allow > running the various tests at patch level rather than post commit > only. I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540 Again, comments welcome. > > > > >> > >>> > >>> comments welcome. > >>> > >>>> > >>>> Kublin - can you please send a patch to remove the usage of > >>>> Long.Compare > >>>> in StorageDomainCommandBase > >>>> > >>>> Thanks, Livnat > >>>> > >>>> > >>>>> _______________________________________________ > >>>>> 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 Jul 23 09:54:14 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 23 Jul 2012 12:54:14 +0300 Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <615476766.2213173.1343036415685.JavaMail.root@redhat.com> References: <615476766.2213173.1343036415685.JavaMail.root@redhat.com> Message-ID: <500D1F46.3060005@redhat.com> On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >> this implies server side code running on the engine, > > Actually, yes and no :) let me explain: > > - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt. > - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" > - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API. > >> which has additional implications on compatibility vs. ui plugins as discussed > > I don't think we need to worry about this :) > > If a GWT UI plugin web application needs to use Engine functionality, it can: > > - use REST API from within UI plugin (JavaScript) code [1] > - use REST API from within its server-side (Java) code [2] again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two. > > [1] - will be supported by UI plugin infrastructure > [2] - not supported by UI plugin infrastructure > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > Sent: Monday, July 23, 2012 9:10:07 AM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >> Last but not least, writing plugins in Google Web Toolkit (GWT) should >> be as easy as providing your own plugin source page. Just deploy your >> GWT plugin application on JBoss AS (next to engine.ear), and point to >> GWT plugin application host page. > > this implies server side code running on the engine, which has > additional implications on compatibility vs. ui plugins as discussed so > far which would be java script > (I'm not against using GWT for them if the resulting java script can be > packaged for use as a UI plugin, but sever side code i prefer to be > isolated from engine until we'll define engine plugins). > > From vszocs at redhat.com Mon Jul 23 10:10:08 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 23 Jul 2012 06:10:08 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <500D1F46.3060005@redhat.com> Message-ID: <933160830.2268381.1343038208402.JavaMail.root@redhat.com> > it is not supposed to be next to engine.jar, it is supposed to be > somewhere else entirely, served to clients like any static content via a > servelt. If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? > that's not the scope we discussed so far. > we discussed a 'static' plugin, which can use an external service or the > REST API. This was actually option [1] as described in my email below. >From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Vojtech Szocs" Cc: "engine-devel" , "Einav Cohen" Sent: Monday, July 23, 2012 11:54:14 AM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >> this implies server side code running on the engine, > > Actually, yes and no :) let me explain: > > - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served it is not supposed to be next to engine.jar, it is supposed to be somewhere else entirely, served to clients like any static content via a servelt. > - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" > - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" that's not the scope we discussed so far. we discussed a 'static' plugin, which can use an external service or the REST API. > >> which has additional implications on compatibility vs. ui plugins as discussed > > I don't think we need to worry about this :) > > If a GWT UI plugin web application needs to use Engine functionality, it can: > > - use REST API from within UI plugin (JavaScript) code [1] > - use REST API from within its server-side (Java) code [2] again, if we want to discuss an approach to making ui plugins which need server side cooperation not in a separate container of their own choice, different server, etc. - we can, but lets separate the discussion on the two. > > [1] - will be supported by UI plugin infrastructure > [2] - not supported by UI plugin infrastructure > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > Sent: Monday, July 23, 2012 9:10:07 AM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >> Last but not least, writing plugins in Google Web Toolkit (GWT) should >> be as easy as providing your own plugin source page. Just deploy your >> GWT plugin application on JBoss AS (next to engine.ear), and point to >> GWT plugin application host page. > > this implies server side code running on the engine, which has > additional implications on compatibility vs. ui plugins as discussed so > far which would be java script > (I'm not against using GWT for them if the resulting java script can be > packaged for use as a UI plugin, but sever side code i prefer to be > isolated from engine until we'll define engine plugins). > > From iheim at redhat.com Mon Jul 23 10:16:04 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 23 Jul 2012 13:16:04 +0300 Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <933160830.2268381.1343038208402.JavaMail.root@redhat.com> References: <933160830.2268381.1343038208402.JavaMail.root@redhat.com> Message-ID: <500D2464.1010307@redhat.com> On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >> it is not supposed to be next to engine.jar, it is supposed to be >> somewhere else entirely, served to clients like any static content via a >> servelt. > > If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. we'll need to solve these in any case for plugins which do have an existing external service. > > In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework. > >> that's not the scope we discussed so far. >> we discussed a 'static' plugin, which can use an external service or the >> REST API. > > This was actually option [1] as described in my email below. > > From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > Sent: Monday, July 23, 2012 11:54:14 AM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>> this implies server side code running on the engine, >> >> Actually, yes and no :) let me explain: >> >> - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served > > it is not supposed to be next to engine.jar, it is supposed to be > somewhere else entirely, served to clients like any static content via a > servelt. > >> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" >> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" > > that's not the scope we discussed so far. > we discussed a 'static' plugin, which can use an external service or the > REST API. > >> >>> which has additional implications on compatibility vs. ui plugins as discussed >> >> I don't think we need to worry about this :) >> >> If a GWT UI plugin web application needs to use Engine functionality, it can: >> >> - use REST API from within UI plugin (JavaScript) code [1] >> - use REST API from within its server-side (Java) code [2] > > again, if we want to discuss an approach to making ui plugins which need > server side cooperation not in a separate container of their own choice, > different server, etc. - we can, but lets separate the discussion on the > two. > >> >> [1] - will be supported by UI plugin infrastructure >> [2] - not supported by UI plugin infrastructure >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" >> Sent: Monday, July 23, 2012 9:10:07 AM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>> Last but not least, writing plugins in Google Web Toolkit (GWT) should >>> be as easy as providing your own plugin source page. Just deploy your >>> GWT plugin application on JBoss AS (next to engine.ear), and point to >>> GWT plugin application host page. >> >> this implies server side code running on the engine, which has >> additional implications on compatibility vs. ui plugins as discussed so >> far which would be java script >> (I'm not against using GWT for them if the resulting java script can be >> packaged for use as a UI plugin, but sever side code i prefer to be >> isolated from engine until we'll define engine plugins). >> >> > > From jhernand at redhat.com Mon Jul 23 10:22:37 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 23 Jul 2012 12:22:37 +0200 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <1818927661.888071.1343036790818.JavaMail.root@redhat.com> References: <1818927661.888071.1343036790818.JavaMail.root@redhat.com> Message-ID: <500D25ED.4080204@redhat.com> On 07/23/2012 11:46 AM, Allon Mureinik wrote: > > > ----- Original Message ----- >> From: "Itamar Heim" >> To: "Allon Mureinik" >> Cc: "Livnat Peer" , "Juan Hernandez" , engine-devel at ovirt.org, "Michael >> Kublin" >> Sent: Monday, July 23, 2012 8:43:02 AM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 07/23/2012 08:29 AM, Allon Mureinik wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Allon Mureinik" >>>> Cc: "Livnat Peer" , "Juan Hernandez" >>>> , engine-devel at ovirt.org, "Michael >>>> Kublin" >>>> Sent: Sunday, July 22, 2012 7:41:00 PM >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>> >>>> On 07/22/2012 07:38 PM, Allon Mureinik wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Livnat Peer" >>>>>> To: "Itamar Heim" , "Michael Kublin" >>>>>> >>>>>> Cc: "Juan Hernandez" , >>>>>> engine-devel at ovirt.org >>>>>> Sent: Sunday, July 22, 2012 9:50:47 AM >>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>>>> >>>>>> On 21/07/12 15:15, Itamar Heim wrote: >>>>>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> >>>>>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>>>>>> >>>>>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>>>>>> syntax >>>>>>>>>>>>>> in >>>>>>>>>>>>>> GWT code? >>>>>>>>>>>>> >>>>>>>>>>>>> That's a very good point. >>>>>>>>>>>>> >>>>>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>>>>>>> that >>>>>>>>>>>>> there >>>>>>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>>>>>> reason, >>>>>>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>>>>>> someone >>>>>>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>>>>>> >>>>>>>>>>>>> So the 'Java 5 only' limitation applies to frontend code >>>>>>>>>>>>> and >>>>>>>>>>>>> any >>>>>>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>>>>>> referenced >>>>>>>>>>>>> by >>>>>>>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>>>>>>> however. >>>>>>>>>>>>> >>>>>>>>>>>>> We could do something like this: >>>>>>>>>>>>> >>>>>>>>>>>>> - let oVirt root POM declare source and target compliance >>>>>>>>>>>>> to >>>>>>>>>>>>> Java 7 >>>>>>>>>>>>> - let frontend modules POM >>>>>>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>>>>>> >>>>>>>>>>>>> (note that target compliance can be left to Java 7 since >>>>>>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>>>>>> >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Vojtech >>>>>>>>>>>> >>>>>>>>>>>> +1 - I really like this idea! >>>>>>>>>>> >>>>>>>>>>> +1 from me as well. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There are two calls to make when it comes to JDK7 >>>>>>>>>> (regardless >>>>>>>>>> of >>>>>>>>>> GWT - >>>>>>>>>> excuse me for taking this discussion some steps backwards) >>>>>>>>>> >>>>>>>>>> 1. Are we running with JRE 7? >>>>>>>>>> The answer is yes we agreed on that a few months ago. >>>>>>>>>> >>>>>>>>>> 2. Are we using code syntax which is incompatible with JDK6? >>>>>>>>>> >>>>>>>>>> I think the answer to the above should be no (at least for >>>>>>>>>> now >>>>>>>>>> - >>>>>>>>>> maybe >>>>>>>>>> until the next ovirt release?). >>>>>>>>> +1 >>>>>>>>> exactly. Why starting with jdk6 incompatible constructs >>>>>>>>> unless >>>>>>>>> there >>>>>>>>> is a good (or at least any) reason for them? >>>>>>>> >>>>>>>> +1 >>>>>>> >>>>>>> +1 - there is merit keeping backward compatibility to allow >>>>>>> comparing >>>>>>> behavior while java 7 is still young. >>>>>> >>>>>> Since no one objected, we'll go with JDK6 syntax compatibility >>>>>> for >>>>>> Now. >>>>> I'm a very small fan of enforcing policy by reviewers. >>>>> Not that the community reviews aren't great - but people miss >>>>> things. >>>>> >>>>> Here's my take on Maven's enforcer plugin to actually verify we >>>>> aren't compiling with JDK 7: >>>>> http://gerrit.ovirt.org/#/c/6523 >>>> >>>> we don't want to enforce compilation or run with JDK 6, only to >>>> preserve >>>> backward compatibility. >>>> I'm for jenkins to have a job to compile and run unitests with >>>> openjdk 6 >>>> to be on the safe side. >>> >>> I don't understand this suggestion. >>> What you're saying is that you can compile with whatever JDK you >>> want, but: >>> - it won't compile with JDKs prior to 6, since we're using 6's >>> features. >>> - you aren't allowed to use JDK 7 features, and if you do, you'll >>> get an email from jenkins that you broke something and must fix >>> it. >>> >>> To me, this sounds a lot like enforcing JDK 6 compatibility. >>> >> >> its preserving jdk 6 compatibility for a few more months, not >> enforcing >> to use jdk 6 compiler. > Fair enough. > >> >>> /today/ if have way too many (i.e., >0) jenkins breaks, a lot of >>> which could be avoided by not running with -DskipTetst or making >>> sure to run with -Penable-dao-tests. >>> I fear this suggestion will just add to this "noise", and could >>> easily be avoided. >> >> jenkins breaks should be visible at patch level prior to commit, >> something we are trying to resolve by adding more hardware to allow >> running the various tests at patch level rather than post commit >> only. > I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. > I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. > Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): > http://gerrit.ovirt.org/#/c/6540 > > Again, comments welcome. Before going ahead I would check that using it doesn't increase the already long compilation time to an unacceptable level. Also need to make sure that the new dependency is available in the build environments we use. I am specially concerned about the Fedora build system, where we have the plugin but not the signatures for the JDKs. This means that we will need to ignore the plugin or build the signatures ourselves. Also take into account that every new maven plugin we add to the POMs introduces new potential problems with the maven eclipse support. I think we can leave the decision to each developer, maybe providing an script that calls "mvn animal-sniffer:check ..." with the right parameters, maybe with git pre-commit hook, to make it more automatic. This combined with the Jenkins checks can be a good compromise. -- 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 iheim at redhat.com Mon Jul 23 10:24:25 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 23 Jul 2012 13:24:25 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500D25ED.4080204@redhat.com> References: <1818927661.888071.1343036790818.JavaMail.root@redhat.com> <500D25ED.4080204@redhat.com> Message-ID: <500D2659.1080408@redhat.com> On 07/23/2012 01:22 PM, Juan Hernandez wrote: > On 07/23/2012 11:46 AM, Allon Mureinik wrote: >> >> >> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Allon Mureinik" >>> Cc: "Livnat Peer" , "Juan Hernandez" , engine-devel at ovirt.org, "Michael >>> Kublin" >>> Sent: Monday, July 23, 2012 8:43:02 AM >>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>> >>> On 07/23/2012 08:29 AM, Allon Mureinik wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Itamar Heim" >>>>> To: "Allon Mureinik" >>>>> Cc: "Livnat Peer" , "Juan Hernandez" >>>>> , engine-devel at ovirt.org, "Michael >>>>> Kublin" >>>>> Sent: Sunday, July 22, 2012 7:41:00 PM >>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>>> >>>>> On 07/22/2012 07:38 PM, Allon Mureinik wrote: >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Livnat Peer" >>>>>>> To: "Itamar Heim" , "Michael Kublin" >>>>>>> >>>>>>> Cc: "Juan Hernandez" , >>>>>>> engine-devel at ovirt.org >>>>>>> Sent: Sunday, July 22, 2012 9:50:47 AM >>>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>>>>> >>>>>>> On 21/07/12 15:15, Itamar Heim wrote: >>>>>>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> >>>>>>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>>>>>>> >>>>>>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>>>>>>> syntax >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> GWT code? >>>>>>>>>>>>>> >>>>>>>>>>>>>> That's a very good point. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>>>>>>>> that >>>>>>>>>>>>>> there >>>>>>>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>>>>>>> reason, >>>>>>>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>>>>>>> someone >>>>>>>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So the 'Java 5 only' limitation applies to frontend code >>>>>>>>>>>>>> and >>>>>>>>>>>>>> any >>>>>>>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>>>>>>> referenced >>>>>>>>>>>>>> by >>>>>>>>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>>>>>>>> however. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We could do something like this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - let oVirt root POM declare source and target compliance >>>>>>>>>>>>>> to >>>>>>>>>>>>>> Java 7 >>>>>>>>>>>>>> - let frontend modules POM >>>>>>>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>>>>>>> >>>>>>>>>>>>>> (note that target compliance can be left to Java 7 since >>>>>>>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>>>>>>> >>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Vojtech >>>>>>>>>>>>> >>>>>>>>>>>>> +1 - I really like this idea! >>>>>>>>>>>> >>>>>>>>>>>> +1 from me as well. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There are two calls to make when it comes to JDK7 >>>>>>>>>>> (regardless >>>>>>>>>>> of >>>>>>>>>>> GWT - >>>>>>>>>>> excuse me for taking this discussion some steps backwards) >>>>>>>>>>> >>>>>>>>>>> 1. Are we running with JRE 7? >>>>>>>>>>> The answer is yes we agreed on that a few months ago. >>>>>>>>>>> >>>>>>>>>>> 2. Are we using code syntax which is incompatible with JDK6? >>>>>>>>>>> >>>>>>>>>>> I think the answer to the above should be no (at least for >>>>>>>>>>> now >>>>>>>>>>> - >>>>>>>>>>> maybe >>>>>>>>>>> until the next ovirt release?). >>>>>>>>>> +1 >>>>>>>>>> exactly. Why starting with jdk6 incompatible constructs >>>>>>>>>> unless >>>>>>>>>> there >>>>>>>>>> is a good (or at least any) reason for them? >>>>>>>>> >>>>>>>>> +1 >>>>>>>> >>>>>>>> +1 - there is merit keeping backward compatibility to allow >>>>>>>> comparing >>>>>>>> behavior while java 7 is still young. >>>>>>> >>>>>>> Since no one objected, we'll go with JDK6 syntax compatibility >>>>>>> for >>>>>>> Now. >>>>>> I'm a very small fan of enforcing policy by reviewers. >>>>>> Not that the community reviews aren't great - but people miss >>>>>> things. >>>>>> >>>>>> Here's my take on Maven's enforcer plugin to actually verify we >>>>>> aren't compiling with JDK 7: >>>>>> http://gerrit.ovirt.org/#/c/6523 >>>>> >>>>> we don't want to enforce compilation or run with JDK 6, only to >>>>> preserve >>>>> backward compatibility. >>>>> I'm for jenkins to have a job to compile and run unitests with >>>>> openjdk 6 >>>>> to be on the safe side. >>>> >>>> I don't understand this suggestion. >>>> What you're saying is that you can compile with whatever JDK you >>>> want, but: >>>> - it won't compile with JDKs prior to 6, since we're using 6's >>>> features. >>>> - you aren't allowed to use JDK 7 features, and if you do, you'll >>>> get an email from jenkins that you broke something and must fix >>>> it. >>>> >>>> To me, this sounds a lot like enforcing JDK 6 compatibility. >>>> >>> >>> its preserving jdk 6 compatibility for a few more months, not >>> enforcing >>> to use jdk 6 compiler. >> Fair enough. >> >>> >>>> /today/ if have way too many (i.e., >0) jenkins breaks, a lot of >>>> which could be avoided by not running with -DskipTetst or making >>>> sure to run with -Penable-dao-tests. >>>> I fear this suggestion will just add to this "noise", and could >>>> easily be avoided. >>> >>> jenkins breaks should be visible at patch level prior to commit, >>> something we are trying to resolve by adding more hardware to allow >>> running the various tests at patch level rather than post commit >>> only. >> I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. >> I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. >> Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): >> http://gerrit.ovirt.org/#/c/6540 >> >> Again, comments welcome. > > Before going ahead I would check that using it doesn't increase the > already long compilation time to an unacceptable level. > > Also need to make sure that the new dependency is available in the build > environments we use. I am specially concerned about the Fedora build > system, where we have the plugin but not the signatures for the JDKs. > This means that we will need to ignore the plugin or build the > signatures ourselves. > > Also take into account that every new maven plugin we add to the POMs > introduces new potential problems with the maven eclipse support. > > I think we can leave the decision to each developer, maybe providing an > script that calls "mvn animal-sniffer:check ..." with the right > parameters, maybe with git pre-commit hook, to make it more automatic. > This combined with the Jenkins checks can be a good compromise. > we really need the jenkins checks on patches... I'll try to push this some more. From amureini at redhat.com Mon Jul 23 11:02:15 2012 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 23 Jul 2012 07:02:15 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500D25ED.4080204@redhat.com> Message-ID: <151416783.1077106.1343041335077.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Juan Hernandez" > To: "Allon Mureinik" > Cc: "Itamar Heim" , engine-devel at ovirt.org > Sent: Monday, July 23, 2012 1:22:37 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/23/2012 11:46 AM, Allon Mureinik wrote: > > > > > > ----- Original Message ----- > >> From: "Itamar Heim" > >> To: "Allon Mureinik" > >> Cc: "Livnat Peer" , "Juan Hernandez" > >> , engine-devel at ovirt.org, "Michael > >> Kublin" > >> Sent: Monday, July 23, 2012 8:43:02 AM > >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >> > >> On 07/23/2012 08:29 AM, Allon Mureinik wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Itamar Heim" > >>>> To: "Allon Mureinik" > >>>> Cc: "Livnat Peer" , "Juan Hernandez" > >>>> , engine-devel at ovirt.org, "Michael > >>>> Kublin" > >>>> Sent: Sunday, July 22, 2012 7:41:00 PM > >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>>> > >>>> On 07/22/2012 07:38 PM, Allon Mureinik wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Livnat Peer" > >>>>>> To: "Itamar Heim" , "Michael Kublin" > >>>>>> > >>>>>> Cc: "Juan Hernandez" , > >>>>>> engine-devel at ovirt.org > >>>>>> Sent: Sunday, July 22, 2012 9:50:47 AM > >>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>>>>> > >>>>>> On 21/07/12 15:15, Itamar Heim wrote: > >>>>>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> > >>>>>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > >>>>>>>>> > >>>>>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: > >>>>>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > >>>>>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > >>>>>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 > >>>>>>>>>>>>>> syntax > >>>>>>>>>>>>>> in > >>>>>>>>>>>>>> GWT code? > >>>>>>>>>>>>> > >>>>>>>>>>>>> That's a very good point. > >>>>>>>>>>>>> > >>>>>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note > >>>>>>>>>>>>> that > >>>>>>>>>>>>> there > >>>>>>>>>>>>> are no language changes between Java 5 and 6). For this > >>>>>>>>>>>>> reason, > >>>>>>>>>>>>> our frontend code should be compliant with Java 5. If > >>>>>>>>>>>>> someone > >>>>>>>>>>>>> uses new Java 7 language features in frontend code, GWT > >>>>>>>>>>>>> compiler will throw an error and the build will fail. > >>>>>>>>>>>>> > >>>>>>>>>>>>> So the 'Java 5 only' limitation applies to frontend > >>>>>>>>>>>>> code > >>>>>>>>>>>>> and > >>>>>>>>>>>>> any > >>>>>>>>>>>>> other code (e.g. shared modules) that is directly > >>>>>>>>>>>>> referenced > >>>>>>>>>>>>> by > >>>>>>>>>>>>> frontend code. This shouldn't affect the backend, > >>>>>>>>>>>>> however. > >>>>>>>>>>>>> > >>>>>>>>>>>>> We could do something like this: > >>>>>>>>>>>>> > >>>>>>>>>>>>> - let oVirt root POM declare source and target > >>>>>>>>>>>>> compliance > >>>>>>>>>>>>> to > >>>>>>>>>>>>> Java 7 > >>>>>>>>>>>>> - let frontend modules POM > >>>>>>>>>>>>> (frontend/webadmin/modules/pom.xml) > >>>>>>>>>>>>> declare source compliance to Java 5 (or 6) > >>>>>>>>>>>>> > >>>>>>>>>>>>> (note that target compliance can be left to Java 7 > >>>>>>>>>>>>> since > >>>>>>>>>>>>> frontend compilation results in JavaScript code) > >>>>>>>>>>>>> > >>>>>>>>>>>>> What do you think? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Vojtech > >>>>>>>>>>>> > >>>>>>>>>>>> +1 - I really like this idea! > >>>>>>>>>>> > >>>>>>>>>>> +1 from me as well. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> There are two calls to make when it comes to JDK7 > >>>>>>>>>> (regardless > >>>>>>>>>> of > >>>>>>>>>> GWT - > >>>>>>>>>> excuse me for taking this discussion some steps backwards) > >>>>>>>>>> > >>>>>>>>>> 1. Are we running with JRE 7? > >>>>>>>>>> The answer is yes we agreed on that a few months ago. > >>>>>>>>>> > >>>>>>>>>> 2. Are we using code syntax which is incompatible with > >>>>>>>>>> JDK6? > >>>>>>>>>> > >>>>>>>>>> I think the answer to the above should be no (at least for > >>>>>>>>>> now > >>>>>>>>>> - > >>>>>>>>>> maybe > >>>>>>>>>> until the next ovirt release?). > >>>>>>>>> +1 > >>>>>>>>> exactly. Why starting with jdk6 incompatible constructs > >>>>>>>>> unless > >>>>>>>>> there > >>>>>>>>> is a good (or at least any) reason for them? > >>>>>>>> > >>>>>>>> +1 > >>>>>>> > >>>>>>> +1 - there is merit keeping backward compatibility to allow > >>>>>>> comparing > >>>>>>> behavior while java 7 is still young. > >>>>>> > >>>>>> Since no one objected, we'll go with JDK6 syntax compatibility > >>>>>> for > >>>>>> Now. > >>>>> I'm a very small fan of enforcing policy by reviewers. > >>>>> Not that the community reviews aren't great - but people miss > >>>>> things. > >>>>> > >>>>> Here's my take on Maven's enforcer plugin to actually verify we > >>>>> aren't compiling with JDK 7: > >>>>> http://gerrit.ovirt.org/#/c/6523 > >>>> > >>>> we don't want to enforce compilation or run with JDK 6, only to > >>>> preserve > >>>> backward compatibility. > >>>> I'm for jenkins to have a job to compile and run unitests with > >>>> openjdk 6 > >>>> to be on the safe side. > >>> > >>> I don't understand this suggestion. > >>> What you're saying is that you can compile with whatever JDK you > >>> want, but: > >>> - it won't compile with JDKs prior to 6, since we're using 6's > >>> features. > >>> - you aren't allowed to use JDK 7 features, and if you do, you'll > >>> get an email from jenkins that you broke something and must fix > >>> it. > >>> > >>> To me, this sounds a lot like enforcing JDK 6 compatibility. > >>> > >> > >> its preserving jdk 6 compatibility for a few more months, not > >> enforcing > >> to use jdk 6 compiler. > > Fair enough. > > > >> > >>> /today/ if have way too many (i.e., >0) jenkins breaks, a lot of > >>> which could be avoided by not running with -DskipTetst or making > >>> sure to run with -Penable-dao-tests. > >>> I fear this suggestion will just add to this "noise", and could > >>> easily be avoided. > >> > >> jenkins breaks should be visible at patch level prior to commit, > >> something we are trying to resolve by adding more hardware to > >> allow > >> running the various tests at patch level rather than post commit > >> only. > > I agree that this is an excellent goal, but I maintain that this is > > an uncomfortable way to work. > > I would still like a way to check, on my own machine, as part of my > > compilation process, that I'm not doing anything I shouldn't. > > Here's my second take on the issue, using Animal Sniffer > > (http://mojo.codehaus.org/animal-sniffer/): > > http://gerrit.ovirt.org/#/c/6540 > > > > Again, comments welcome. > > Before going ahead I would check that using it doesn't increase the > already long compilation time to an unacceptable level. mvn clean install on my machine took just over 5 minutes - not too bad considering that up till a month ago or so it took 15-20 minutes to run the test suite. > > Also need to make sure that the new dependency is available in the > build > environments we use. Built it against brew's repo, seemed to work fine. If you have any more suggestions on how to check it, please advise. > I am specially concerned about the Fedora build > system, where we have the plugin but not the signatures for the JDKs. The signatures are provided as part of the plugin - they are not taken directly from the JDK. Or am I missing something in your point? > This means that we will need to ignore the plugin or build the > signatures ourselves. Not so - see above. > > Also take into account that every new maven plugin we add to the POMs > introduces new potential problems with the maven eclipse support. True. IMHO, it's a small price to pay, but I guess that's why we discuss things upstream - to get different opinions ;-) > > I think we can leave the decision to each developer, maybe providing > an > script that calls "mvn animal-sniffer:check ..." with the right > parameters, maybe with git pre-commit hook, to make it more > automatic. I really don't like this approach, but again - difference of opinions :-) Let's gather somemore feedback before deciding either way? > This combined with the Jenkins checks can be a good compromise. > > -- > 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 yzaslavs at redhat.com Mon Jul 23 11:34:28 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Mon, 23 Jul 2012 14:34:28 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <151416783.1077106.1343041335077.JavaMail.root@redhat.com> References: <151416783.1077106.1343041335077.JavaMail.root@redhat.com> Message-ID: <500D36C4.6080003@redhat.com> On 07/23/2012 02:02 PM, Allon Mureinik wrote: > > > ----- Original Message ----- >> From: "Juan Hernandez" >> To: "Allon Mureinik" >> Cc: "Itamar Heim", engine-devel at ovirt.org >> Sent: Monday, July 23, 2012 1:22:37 PM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 07/23/2012 11:46 AM, Allon Mureinik wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Allon Mureinik" >>>> Cc: "Livnat Peer", "Juan Hernandez" >>>> , engine-devel at ovirt.org, "Michael >>>> Kublin" >>>> Sent: Monday, July 23, 2012 8:43:02 AM >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>> >>>> On 07/23/2012 08:29 AM, Allon Mureinik wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Itamar Heim" >>>>>> To: "Allon Mureinik" >>>>>> Cc: "Livnat Peer", "Juan Hernandez" >>>>>> , engine-devel at ovirt.org, "Michael >>>>>> Kublin" >>>>>> Sent: Sunday, July 22, 2012 7:41:00 PM >>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>>>> >>>>>> On 07/22/2012 07:38 PM, Allon Mureinik wrote: >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Livnat Peer" >>>>>>>> To: "Itamar Heim", "Michael Kublin" >>>>>>>> >>>>>>>> Cc: "Juan Hernandez", >>>>>>>> engine-devel at ovirt.org >>>>>>>> Sent: Sunday, July 22, 2012 9:50:47 AM >>>>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>>>>>> >>>>>>>> On 21/07/12 15:15, Itamar Heim wrote: >>>>>>>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> >>>>>>>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>>>>>>>> >>>>>>>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>>>>>>>> syntax >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> GWT code? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That's a very good point. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> there >>>>>>>>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>>>>>>>> reason, >>>>>>>>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>>>>>>>> someone >>>>>>>>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So the 'Java 5 only' limitation applies to frontend >>>>>>>>>>>>>>> code >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> any >>>>>>>>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>>>>>>>> referenced >>>>>>>>>>>>>>> by >>>>>>>>>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>>>>>>>>> however. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We could do something like this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - let oVirt root POM declare source and target >>>>>>>>>>>>>>> compliance >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> Java 7 >>>>>>>>>>>>>>> - let frontend modules POM >>>>>>>>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (note that target compliance can be left to Java 7 >>>>>>>>>>>>>>> since >>>>>>>>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Vojtech >>>>>>>>>>>>>> >>>>>>>>>>>>>> +1 - I really like this idea! >>>>>>>>>>>>> >>>>>>>>>>>>> +1 from me as well. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There are two calls to make when it comes to JDK7 >>>>>>>>>>>> (regardless >>>>>>>>>>>> of >>>>>>>>>>>> GWT - >>>>>>>>>>>> excuse me for taking this discussion some steps backwards) >>>>>>>>>>>> >>>>>>>>>>>> 1. Are we running with JRE 7? >>>>>>>>>>>> The answer is yes we agreed on that a few months ago. >>>>>>>>>>>> >>>>>>>>>>>> 2. Are we using code syntax which is incompatible with >>>>>>>>>>>> JDK6? >>>>>>>>>>>> >>>>>>>>>>>> I think the answer to the above should be no (at least for >>>>>>>>>>>> now >>>>>>>>>>>> - >>>>>>>>>>>> maybe >>>>>>>>>>>> until the next ovirt release?). >>>>>>>>>>> +1 >>>>>>>>>>> exactly. Why starting with jdk6 incompatible constructs >>>>>>>>>>> unless >>>>>>>>>>> there >>>>>>>>>>> is a good (or at least any) reason for them? >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>> >>>>>>>>> +1 - there is merit keeping backward compatibility to allow >>>>>>>>> comparing >>>>>>>>> behavior while java 7 is still young. >>>>>>>> >>>>>>>> Since no one objected, we'll go with JDK6 syntax compatibility >>>>>>>> for >>>>>>>> Now. >>>>>>> I'm a very small fan of enforcing policy by reviewers. >>>>>>> Not that the community reviews aren't great - but people miss >>>>>>> things. >>>>>>> >>>>>>> Here's my take on Maven's enforcer plugin to actually verify we >>>>>>> aren't compiling with JDK 7: >>>>>>> http://gerrit.ovirt.org/#/c/6523 >>>>>> >>>>>> we don't want to enforce compilation or run with JDK 6, only to >>>>>> preserve >>>>>> backward compatibility. >>>>>> I'm for jenkins to have a job to compile and run unitests with >>>>>> openjdk 6 >>>>>> to be on the safe side. >>>>> >>>>> I don't understand this suggestion. >>>>> What you're saying is that you can compile with whatever JDK you >>>>> want, but: >>>>> - it won't compile with JDKs prior to 6, since we're using 6's >>>>> features. >>>>> - you aren't allowed to use JDK 7 features, and if you do, you'll >>>>> get an email from jenkins that you broke something and must fix >>>>> it. >>>>> >>>>> To me, this sounds a lot like enforcing JDK 6 compatibility. >>>>> >>>> >>>> its preserving jdk 6 compatibility for a few more months, not >>>> enforcing >>>> to use jdk 6 compiler. >>> Fair enough. >>> >>>> >>>>> /today/ if have way too many (i.e.,>0) jenkins breaks, a lot of >>>>> which could be avoided by not running with -DskipTetst or making >>>>> sure to run with -Penable-dao-tests. >>>>> I fear this suggestion will just add to this "noise", and could >>>>> easily be avoided. >>>> >>>> jenkins breaks should be visible at patch level prior to commit, >>>> something we are trying to resolve by adding more hardware to >>>> allow >>>> running the various tests at patch level rather than post commit >>>> only. >>> I agree that this is an excellent goal, but I maintain that this is >>> an uncomfortable way to work. >>> I would still like a way to check, on my own machine, as part of my >>> compilation process, that I'm not doing anything I shouldn't. >>> Here's my second take on the issue, using Animal Sniffer >>> (http://mojo.codehaus.org/animal-sniffer/): >>> http://gerrit.ovirt.org/#/c/6540 >>> >>> Again, comments welcome. >> >> Before going ahead I would check that using it doesn't increase the >> already long compilation time to an unacceptable level. > mvn clean install on my machine took just over 5 minutes - not too bad considering that up till a month ago or so it took 15-20 minutes to run the test suite. > >> >> Also need to make sure that the new dependency is available in the >> build >> environments we use. > Built it against brew's repo, seemed to work fine. > If you have any more suggestions on how to check it, please advise. > >> I am specially concerned about the Fedora build >> system, where we have the plugin but not the signatures for the JDKs. > The signatures are provided as part of the plugin - they are not taken directly from the JDK. > Or am I missing something in your point? > >> This means that we will need to ignore the plugin or build the >> signatures ourselves. > Not so - see above. > >> >> Also take into account that every new maven plugin we add to the POMs >> introduces new potential problems with the maven eclipse support. > True. > IMHO, it's a small price to pay, but I guess that's why we discuss things upstream - to get different opinions ;-) > >> >> I think we can leave the decision to each developer, maybe providing >> an >> script that calls "mvn animal-sniffer:check ..." with the right >> parameters, maybe with git pre-commit hook, to make it more >> automatic. > I really don't like this approach, but again - difference of opinions :-) > Let's gather somemore feedback before deciding either way? I am in favor of having this more automatic (maybe via Jenkins job that will fail patches not compiling against JDK6, maybe some other way) rather than trusting the developers. Not that I don't trust oVirt developers, but we're all human and can make sometimes mistakes. > >> This combined with the Jenkins checks can be a good compromise. +1 on jenkins, as I Expressed before >> >> -- >> 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. >> >> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From jhernand at redhat.com Mon Jul 23 11:31:24 2012 From: jhernand at redhat.com (Juan Hernandez) Date: Mon, 23 Jul 2012 13:31:24 +0200 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <151416783.1077106.1343041335077.JavaMail.root@redhat.com> References: <151416783.1077106.1343041335077.JavaMail.root@redhat.com> Message-ID: <500D360C.3090000@redhat.com> On 07/23/2012 01:02 PM, Allon Mureinik wrote: > > > ----- Original Message ----- >> From: "Juan Hernandez" >> To: "Allon Mureinik" >> Cc: "Itamar Heim" , engine-devel at ovirt.org >> Sent: Monday, July 23, 2012 1:22:37 PM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 07/23/2012 11:46 AM, Allon Mureinik wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Allon Mureinik" >>>> Cc: "Livnat Peer" , "Juan Hernandez" >>>> , engine-devel at ovirt.org, "Michael >>>> Kublin" >>>> Sent: Monday, July 23, 2012 8:43:02 AM >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>> >>>> On 07/23/2012 08:29 AM, Allon Mureinik wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Itamar Heim" >>>>>> To: "Allon Mureinik" >>>>>> Cc: "Livnat Peer" , "Juan Hernandez" >>>>>> , engine-devel at ovirt.org, "Michael >>>>>> Kublin" >>>>>> Sent: Sunday, July 22, 2012 7:41:00 PM >>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>>>> >>>>>> On 07/22/2012 07:38 PM, Allon Mureinik wrote: >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Livnat Peer" >>>>>>>> To: "Itamar Heim" , "Michael Kublin" >>>>>>>> >>>>>>>> Cc: "Juan Hernandez" , >>>>>>>> engine-devel at ovirt.org >>>>>>>> Sent: Sunday, July 22, 2012 9:50:47 AM >>>>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>>>>>>> >>>>>>>> On 21/07/12 15:15, Itamar Heim wrote: >>>>>>>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> >>>>>>>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>>>>>>>> >>>>>>>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>>>>>>>> syntax >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>> GWT code? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That's a very good point. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> there >>>>>>>>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>>>>>>>> reason, >>>>>>>>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>>>>>>>> someone >>>>>>>>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So the 'Java 5 only' limitation applies to frontend >>>>>>>>>>>>>>> code >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> any >>>>>>>>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>>>>>>>> referenced >>>>>>>>>>>>>>> by >>>>>>>>>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>>>>>>>>> however. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We could do something like this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - let oVirt root POM declare source and target >>>>>>>>>>>>>>> compliance >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> Java 7 >>>>>>>>>>>>>>> - let frontend modules POM >>>>>>>>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (note that target compliance can be left to Java 7 >>>>>>>>>>>>>>> since >>>>>>>>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Vojtech >>>>>>>>>>>>>> >>>>>>>>>>>>>> +1 - I really like this idea! >>>>>>>>>>>>> >>>>>>>>>>>>> +1 from me as well. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> There are two calls to make when it comes to JDK7 >>>>>>>>>>>> (regardless >>>>>>>>>>>> of >>>>>>>>>>>> GWT - >>>>>>>>>>>> excuse me for taking this discussion some steps backwards) >>>>>>>>>>>> >>>>>>>>>>>> 1. Are we running with JRE 7? >>>>>>>>>>>> The answer is yes we agreed on that a few months ago. >>>>>>>>>>>> >>>>>>>>>>>> 2. Are we using code syntax which is incompatible with >>>>>>>>>>>> JDK6? >>>>>>>>>>>> >>>>>>>>>>>> I think the answer to the above should be no (at least for >>>>>>>>>>>> now >>>>>>>>>>>> - >>>>>>>>>>>> maybe >>>>>>>>>>>> until the next ovirt release?). >>>>>>>>>>> +1 >>>>>>>>>>> exactly. Why starting with jdk6 incompatible constructs >>>>>>>>>>> unless >>>>>>>>>>> there >>>>>>>>>>> is a good (or at least any) reason for them? >>>>>>>>>> >>>>>>>>>> +1 >>>>>>>>> >>>>>>>>> +1 - there is merit keeping backward compatibility to allow >>>>>>>>> comparing >>>>>>>>> behavior while java 7 is still young. >>>>>>>> >>>>>>>> Since no one objected, we'll go with JDK6 syntax compatibility >>>>>>>> for >>>>>>>> Now. >>>>>>> I'm a very small fan of enforcing policy by reviewers. >>>>>>> Not that the community reviews aren't great - but people miss >>>>>>> things. >>>>>>> >>>>>>> Here's my take on Maven's enforcer plugin to actually verify we >>>>>>> aren't compiling with JDK 7: >>>>>>> http://gerrit.ovirt.org/#/c/6523 >>>>>> >>>>>> we don't want to enforce compilation or run with JDK 6, only to >>>>>> preserve >>>>>> backward compatibility. >>>>>> I'm for jenkins to have a job to compile and run unitests with >>>>>> openjdk 6 >>>>>> to be on the safe side. >>>>> >>>>> I don't understand this suggestion. >>>>> What you're saying is that you can compile with whatever JDK you >>>>> want, but: >>>>> - it won't compile with JDKs prior to 6, since we're using 6's >>>>> features. >>>>> - you aren't allowed to use JDK 7 features, and if you do, you'll >>>>> get an email from jenkins that you broke something and must fix >>>>> it. >>>>> >>>>> To me, this sounds a lot like enforcing JDK 6 compatibility. >>>>> >>>> >>>> its preserving jdk 6 compatibility for a few more months, not >>>> enforcing >>>> to use jdk 6 compiler. >>> Fair enough. >>> >>>> >>>>> /today/ if have way too many (i.e., >0) jenkins breaks, a lot of >>>>> which could be avoided by not running with -DskipTetst or making >>>>> sure to run with -Penable-dao-tests. >>>>> I fear this suggestion will just add to this "noise", and could >>>>> easily be avoided. >>>> >>>> jenkins breaks should be visible at patch level prior to commit, >>>> something we are trying to resolve by adding more hardware to >>>> allow >>>> running the various tests at patch level rather than post commit >>>> only. >>> I agree that this is an excellent goal, but I maintain that this is >>> an uncomfortable way to work. >>> I would still like a way to check, on my own machine, as part of my >>> compilation process, that I'm not doing anything I shouldn't. >>> Here's my second take on the issue, using Animal Sniffer >>> (http://mojo.codehaus.org/animal-sniffer/): >>> http://gerrit.ovirt.org/#/c/6540 >>> >>> Again, comments welcome. >> >> Before going ahead I would check that using it doesn't increase the >> already long compilation time to an unacceptable level. > mvn clean install on my machine took just over 5 minutes - not too bad considering that up till a month ago or so it took 15-20 minutes to run the test suite. Can you compare the build with and without animal-sniffer? Just to have an idea of what is the difference. Anyhow five minutes seems acceptable to me. >> Also need to make sure that the new dependency is available in the >> build >> environments we use. > Built it against brew's repo, seemed to work fine. > If you have any more suggestions on how to check it, please advise. That is very good. Actually building there would be even better. >> I am specially concerned about the Fedora build >> system, where we have the plugin but not the signatures for the JDKs. > The signatures are provided as part of the plugin - they are not taken directly from the JDK. > Or am I missing something in your point? I don't know very well this plugin, but it is my understanding that the signatures are additional dependencies that need to be downloaded from the maven repository. In your patch you are using the following: org.jvnet.animal-sniffer java1.6 1.0 This org.jvnet.animal-sniffer:java1.6:1.0 artifact is what I can't find in the Fedora build system. Not a big problem, this can be patched out while building the package, just a minor inconvenience. >> This means that we will need to ignore the plugin or build the >> signatures ourselves. > Not so - see above. > >> >> Also take into account that every new maven plugin we add to the POMs >> introduces new potential problems with the maven eclipse support. > True. > IMHO, it's a small price to pay, but I guess that's why we discuss things upstream - to get different opinions ;-) Well, for me personally the price is actually zero, as I don't use the Eclipse maven support ;-) . But I know that many people hates when they try to import the projects and they get errors because of plugins that Eclipse doesn't understand. Let's see what they think. >> I think we can leave the decision to each developer, maybe providing >> an >> script that calls "mvn animal-sniffer:check ..." with the right >> parameters, maybe with git pre-commit hook, to make it more >> automatic. > I really don't like this approach, but again - difference of opinions :-) > Let's gather somemore feedback before deciding either way? Yes, of course. In my opinion adding this check is a good idea, and you already cleared most of the objections. >> This combined with the Jenkins checks can be a good compromise. -- 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 iheim at redhat.com Mon Jul 23 11:44:02 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 23 Jul 2012 14:44:02 +0300 Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500D360C.3090000@redhat.com> References: <151416783.1077106.1343041335077.JavaMail.root@redhat.com> <500D360C.3090000@redhat.com> Message-ID: <500D3902.40402@redhat.com> On 07/23/2012 02:31 PM, Juan Hernandez wrote: > Well, for me personally the price is actually zero, as I don't use the > Eclipse maven support ;-) . But I know that many people hates when they > try to import the projects and they get errors because of plugins that > Eclipse doesn't understand. Let's see what they think. ovirt should load in eclipse without any error, and we are working on cleaning this up as it currently requires manual work to clean up the errors to work in eclipse (which i find less than friendly to new community members) From vszocs at redhat.com Mon Jul 23 12:26:50 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 23 Jul 2012 08:26:50 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <500D2464.1010307@redhat.com> Message-ID: <620218042.2539482.1343046410933.JavaMail.root@redhat.com> I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Vojtech Szocs" Cc: "engine-devel" , "Einav Cohen" Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >> it is not supposed to be next to engine.jar, it is supposed to be >> somewhere else entirely, served to clients like any static content via a >> servelt. > > If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. we'll need to solve these in any case for plugins which do have an existing external service. > > In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework. > >> that's not the scope we discussed so far. >> we discussed a 'static' plugin, which can use an external service or the >> REST API. > > This was actually option [1] as described in my email below. > > From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > Sent: Monday, July 23, 2012 11:54:14 AM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>> this implies server side code running on the engine, >> >> Actually, yes and no :) let me explain: >> >> - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served > > it is not supposed to be next to engine.jar, it is supposed to be > somewhere else entirely, served to clients like any static content via a > servelt. > >> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" >> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" > > that's not the scope we discussed so far. > we discussed a 'static' plugin, which can use an external service or the > REST API. > >> >>> which has additional implications on compatibility vs. ui plugins as discussed >> >> I don't think we need to worry about this :) >> >> If a GWT UI plugin web application needs to use Engine functionality, it can: >> >> - use REST API from within UI plugin (JavaScript) code [1] >> - use REST API from within its server-side (Java) code [2] > > again, if we want to discuss an approach to making ui plugins which need > server side cooperation not in a separate container of their own choice, > different server, etc. - we can, but lets separate the discussion on the > two. > >> >> [1] - will be supported by UI plugin infrastructure >> [2] - not supported by UI plugin infrastructure >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" >> Sent: Monday, July 23, 2012 9:10:07 AM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>> Last but not least, writing plugins in Google Web Toolkit (GWT) should >>> be as easy as providing your own plugin source page. Just deploy your >>> GWT plugin application on JBoss AS (next to engine.ear), and point to >>> GWT plugin application host page. >> >> this implies server side code running on the engine, which has >> additional implications on compatibility vs. ui plugins as discussed so >> far which would be java script >> (I'm not against using GWT for them if the resulting java script can be >> packaged for use as a UI plugin, but sever side code i prefer to be >> isolated from engine until we'll define engine plugins). >> >> > > From iheim at redhat.com Mon Jul 23 12:27:56 2012 From: iheim at redhat.com (Itamar Heim) Date: Mon, 23 Jul 2012 15:27:56 +0300 Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <620218042.2539482.1343046410933.JavaMail.root@redhat.com> References: <620218042.2539482.1343046410933.JavaMail.root@redhat.com> Message-ID: <500D434C.3040509@redhat.com> On 07/23/2012 03:26 PM, Vojtech Szocs wrote: > I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. > > As for cross-origin iframe communication issues, there are several ways how to address them: > - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss > - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) > > For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). what do you mean by a servlet here? > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > Sent: Monday, July 23, 2012 12:16:04 PM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >>> it is not supposed to be next to engine.jar, it is supposed to be >>> somewhere else entirely, served to clients like any static content via a >>> servelt. >> >> If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. > > we'll need to solve these in any case for plugins which do have an > existing external service. > >> >> In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? > > because once we tell people it is ok, it makes it our responsibility to > make sure they don't break during upgrades for example (or worse, not > fail the entire engine post an upgrade). > I'm not saying these are not solvable, but i'd rather not try to handle > them on the first cut of this framework. > >> >>> that's not the scope we discussed so far. >>> we discussed a 'static' plugin, which can use an external service or the >>> REST API. >> >> This was actually option [1] as described in my email below. >> >> From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" >> Sent: Monday, July 23, 2012 11:54:14 AM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>>> this implies server side code running on the engine, >>> >>> Actually, yes and no :) let me explain: >>> >>> - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served >> >> it is not supposed to be next to engine.jar, it is supposed to be >> somewhere else entirely, served to clients like any static content via a >> servelt. >> >>> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" >>> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" >> >> that's not the scope we discussed so far. >> we discussed a 'static' plugin, which can use an external service or the >> REST API. >> >>> >>>> which has additional implications on compatibility vs. ui plugins as discussed >>> >>> I don't think we need to worry about this :) >>> >>> If a GWT UI plugin web application needs to use Engine functionality, it can: >>> >>> - use REST API from within UI plugin (JavaScript) code [1] >>> - use REST API from within its server-side (Java) code [2] >> >> again, if we want to discuss an approach to making ui plugins which need >> server side cooperation not in a separate container of their own choice, >> different server, etc. - we can, but lets separate the discussion on the >> two. >> >>> >>> [1] - will be supported by UI plugin infrastructure >>> [2] - not supported by UI plugin infrastructure >>> >>> Vojtech >>> >>> >>> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Vojtech Szocs" >>> Cc: "engine-devel" , "Einav Cohen" >>> Sent: Monday, July 23, 2012 9:10:07 AM >>> Subject: Re: oVirt UI Plugins: Update on current progress >>> >>> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>>> Last but not least, writing plugins in Google Web Toolkit (GWT) should >>>> be as easy as providing your own plugin source page. Just deploy your >>>> GWT plugin application on JBoss AS (next to engine.ear), and point to >>>> GWT plugin application host page. >>> >>> this implies server side code running on the engine, which has >>> additional implications on compatibility vs. ui plugins as discussed so >>> far which would be java script >>> (I'm not against using GWT for them if the resulting java script can be >>> packaged for use as a UI plugin, but sever side code i prefer to be >>> isolated from engine until we'll define engine plugins). >>> >>> >> >> > > From George.Costea at netapp.com Mon Jul 23 13:33:12 2012 From: George.Costea at netapp.com (Costea, George) Date: Mon, 23 Jul 2012 13:33:12 +0000 Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <620218042.2539482.1343046410933.JavaMail.root@redhat.com> References: <500D2464.1010307@redhat.com> <620218042.2539482.1343046410933.JavaMail.root@redhat.com> Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A4801265B5F@SACEXCMBX04-PRD.hq.netapp.com> It appears to me that the cross-origin issue is caused because the plugin definition is embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires that all plugins also exist within the same origin. Rather than extending the WebAdmin page with javascript, would it be possible to instead have an API that modifies that page with extensions? For example, the API tells it to add a new menu item that when launched would invoke the url registered with the extension. The new page is now rendered in a distinct window (much like early versions of GWT hosted mode created an embedded browser window). -George -----Original Message----- From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Vojtech Szocs Sent: Monday, July 23, 2012 8:27 AM To: Itamar Heim Cc: engine-devel Subject: Re: [Engine-devel] oVirt UI Plugins: Update on current progress I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Vojtech Szocs" Cc: "engine-devel" , "Einav Cohen" Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >> it is not supposed to be next to engine.jar, it is supposed to be >> somewhere else entirely, served to clients like any static content >> via a servelt. > > If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. we'll need to solve these in any case for plugins which do have an existing external service. > > In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework. > >> that's not the scope we discussed so far. >> we discussed a 'static' plugin, which can use an external service or >> the REST API. > > This was actually option [1] as described in my email below. > > From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > > Sent: Monday, July 23, 2012 11:54:14 AM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>> this implies server side code running on the engine, >> >> Actually, yes and no :) let me explain: >> >> - UI plugins developed in GWT need some context (plugin web >> application deployed next to engine.ear) from which their code will >> be served > > it is not supposed to be next to engine.jar, it is supposed to be > somewhere else entirely, served to clients like any static content via > a servelt. > >> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" >> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" > > that's not the scope we discussed so far. > we discussed a 'static' plugin, which can use an external service or > the REST API. > >> >>> which has additional implications on compatibility vs. ui plugins as >>> discussed >> >> I don't think we need to worry about this :) >> >> If a GWT UI plugin web application needs to use Engine functionality, it can: >> >> - use REST API from within UI plugin (JavaScript) code [1] >> - use REST API from within its server-side (Java) code [2] > > again, if we want to discuss an approach to making ui plugins which > need server side cooperation not in a separate container of their own > choice, different server, etc. - we can, but lets separate the > discussion on the two. > >> >> [1] - will be supported by UI plugin infrastructure [2] - not >> supported by UI plugin infrastructure >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" >> >> Sent: Monday, July 23, 2012 9:10:07 AM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>> Last but not least, writing plugins in Google Web Toolkit (GWT) >>> should be as easy as providing your own plugin source page. Just >>> deploy your GWT plugin application on JBoss AS (next to engine.ear), >>> and point to GWT plugin application host page. >> >> this implies server side code running on the engine, which has >> additional implications on compatibility vs. ui plugins as discussed >> so far which would be java script (I'm not against using GWT for them >> if the resulting java script can be packaged for use as a UI plugin, >> but sever side code i prefer to be isolated from engine until we'll >> define engine plugins). >> >> > > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From sgordon at redhat.com Mon Jul 23 15:30:56 2012 From: sgordon at redhat.com (Steve Gordon) Date: Mon, 23 Jul 2012 11:30:56 -0400 (EDT) Subject: [Engine-devel] Is ovirt-engine-cli expected for 3.1? Message-ID: <1083173245.880443.1343057456033.JavaMail.root@redhat.com> Hi guys, On the release notes draft [1] one of the items is "New Python CLI, packaged as ??? (CLI).". The CLI page on the wiki says the package is ovirt-engine-cli, but this package doesn't exist in the beta repo. Is the CLI actually being delivered? Thanks, Steve [1] http://wiki.ovirt.org/wiki/Release_Notes_Draft [2] http://wiki.ovirt.org/wiki/CLI From amureini at redhat.com Mon Jul 23 16:33:16 2012 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 23 Jul 2012 12:33:16 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500D360C.3090000@redhat.com> Message-ID: <849700837.1929277.1343061196376.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Juan Hernandez" > To: "Allon Mureinik" > Cc: engine-devel at ovirt.org > Sent: Monday, July 23, 2012 2:31:24 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/23/2012 01:02 PM, Allon Mureinik wrote: > > > > > > ----- Original Message ----- > >> From: "Juan Hernandez" > >> To: "Allon Mureinik" > >> Cc: "Itamar Heim" , engine-devel at ovirt.org > >> Sent: Monday, July 23, 2012 1:22:37 PM > >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >> > >> On 07/23/2012 11:46 AM, Allon Mureinik wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Itamar Heim" > >>>> To: "Allon Mureinik" > >>>> Cc: "Livnat Peer" , "Juan Hernandez" > >>>> , engine-devel at ovirt.org, "Michael > >>>> Kublin" > >>>> Sent: Monday, July 23, 2012 8:43:02 AM > >>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>>> > >>>> On 07/23/2012 08:29 AM, Allon Mureinik wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Itamar Heim" > >>>>>> To: "Allon Mureinik" > >>>>>> Cc: "Livnat Peer" , "Juan Hernandez" > >>>>>> , engine-devel at ovirt.org, "Michael > >>>>>> Kublin" > >>>>>> Sent: Sunday, July 22, 2012 7:41:00 PM > >>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>>>>> > >>>>>> On 07/22/2012 07:38 PM, Allon Mureinik wrote: > >>>>>>> > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Livnat Peer" > >>>>>>>> To: "Itamar Heim" , "Michael Kublin" > >>>>>>>> > >>>>>>>> Cc: "Juan Hernandez" , > >>>>>>>> engine-devel at ovirt.org > >>>>>>>> Sent: Sunday, July 22, 2012 9:50:47 AM > >>>>>>>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? > >>>>>>>> > >>>>>>>> On 21/07/12 15:15, Itamar Heim wrote: > >>>>>>>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>> > >>>>>>>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: > >>>>>>>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > >>>>>>>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: > >>>>>>>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 > >>>>>>>>>>>>>>>> syntax > >>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> GWT code? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> That's a very good point. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note > >>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>> there > >>>>>>>>>>>>>>> are no language changes between Java 5 and 6). For > >>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>> reason, > >>>>>>>>>>>>>>> our frontend code should be compliant with Java 5. If > >>>>>>>>>>>>>>> someone > >>>>>>>>>>>>>>> uses new Java 7 language features in frontend code, > >>>>>>>>>>>>>>> GWT > >>>>>>>>>>>>>>> compiler will throw an error and the build will fail. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> So the 'Java 5 only' limitation applies to frontend > >>>>>>>>>>>>>>> code > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>> any > >>>>>>>>>>>>>>> other code (e.g. shared modules) that is directly > >>>>>>>>>>>>>>> referenced > >>>>>>>>>>>>>>> by > >>>>>>>>>>>>>>> frontend code. This shouldn't affect the backend, > >>>>>>>>>>>>>>> however. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> We could do something like this: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - let oVirt root POM declare source and target > >>>>>>>>>>>>>>> compliance > >>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>> Java 7 > >>>>>>>>>>>>>>> - let frontend modules POM > >>>>>>>>>>>>>>> (frontend/webadmin/modules/pom.xml) > >>>>>>>>>>>>>>> declare source compliance to Java 5 (or 6) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> (note that target compliance can be left to Java 7 > >>>>>>>>>>>>>>> since > >>>>>>>>>>>>>>> frontend compilation results in JavaScript code) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> What do you think? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Vojtech > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> +1 - I really like this idea! > >>>>>>>>>>>>> > >>>>>>>>>>>>> +1 from me as well. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> There are two calls to make when it comes to JDK7 > >>>>>>>>>>>> (regardless > >>>>>>>>>>>> of > >>>>>>>>>>>> GWT - > >>>>>>>>>>>> excuse me for taking this discussion some steps > >>>>>>>>>>>> backwards) > >>>>>>>>>>>> > >>>>>>>>>>>> 1. Are we running with JRE 7? > >>>>>>>>>>>> The answer is yes we agreed on that a few months ago. > >>>>>>>>>>>> > >>>>>>>>>>>> 2. Are we using code syntax which is incompatible with > >>>>>>>>>>>> JDK6? > >>>>>>>>>>>> > >>>>>>>>>>>> I think the answer to the above should be no (at least > >>>>>>>>>>>> for > >>>>>>>>>>>> now > >>>>>>>>>>>> - > >>>>>>>>>>>> maybe > >>>>>>>>>>>> until the next ovirt release?). > >>>>>>>>>>> +1 > >>>>>>>>>>> exactly. Why starting with jdk6 incompatible constructs > >>>>>>>>>>> unless > >>>>>>>>>>> there > >>>>>>>>>>> is a good (or at least any) reason for them? > >>>>>>>>>> > >>>>>>>>>> +1 > >>>>>>>>> > >>>>>>>>> +1 - there is merit keeping backward compatibility to allow > >>>>>>>>> comparing > >>>>>>>>> behavior while java 7 is still young. > >>>>>>>> > >>>>>>>> Since no one objected, we'll go with JDK6 syntax > >>>>>>>> compatibility > >>>>>>>> for > >>>>>>>> Now. > >>>>>>> I'm a very small fan of enforcing policy by reviewers. > >>>>>>> Not that the community reviews aren't great - but people miss > >>>>>>> things. > >>>>>>> > >>>>>>> Here's my take on Maven's enforcer plugin to actually verify > >>>>>>> we > >>>>>>> aren't compiling with JDK 7: > >>>>>>> http://gerrit.ovirt.org/#/c/6523 > >>>>>> > >>>>>> we don't want to enforce compilation or run with JDK 6, only > >>>>>> to > >>>>>> preserve > >>>>>> backward compatibility. > >>>>>> I'm for jenkins to have a job to compile and run unitests with > >>>>>> openjdk 6 > >>>>>> to be on the safe side. > >>>>> > >>>>> I don't understand this suggestion. > >>>>> What you're saying is that you can compile with whatever JDK > >>>>> you > >>>>> want, but: > >>>>> - it won't compile with JDKs prior to 6, since we're using 6's > >>>>> features. > >>>>> - you aren't allowed to use JDK 7 features, and if you do, > >>>>> you'll > >>>>> get an email from jenkins that you broke something and must fix > >>>>> it. > >>>>> > >>>>> To me, this sounds a lot like enforcing JDK 6 compatibility. > >>>>> > >>>> > >>>> its preserving jdk 6 compatibility for a few more months, not > >>>> enforcing > >>>> to use jdk 6 compiler. > >>> Fair enough. > >>> > >>>> > >>>>> /today/ if have way too many (i.e., >0) jenkins breaks, a lot > >>>>> of > >>>>> which could be avoided by not running with -DskipTetst or > >>>>> making > >>>>> sure to run with -Penable-dao-tests. > >>>>> I fear this suggestion will just add to this "noise", and could > >>>>> easily be avoided. > >>>> > >>>> jenkins breaks should be visible at patch level prior to commit, > >>>> something we are trying to resolve by adding more hardware to > >>>> allow > >>>> running the various tests at patch level rather than post commit > >>>> only. > >>> I agree that this is an excellent goal, but I maintain that this > >>> is > >>> an uncomfortable way to work. > >>> I would still like a way to check, on my own machine, as part of > >>> my > >>> compilation process, that I'm not doing anything I shouldn't. > >>> Here's my second take on the issue, using Animal Sniffer > >>> (http://mojo.codehaus.org/animal-sniffer/): > >>> http://gerrit.ovirt.org/#/c/6540 > >>> > >>> Again, comments welcome. > >> > >> Before going ahead I would check that using it doesn't increase > >> the > >> already long compilation time to an unacceptable level. > > mvn clean install on my machine took just over 5 minutes - not too > > bad considering that up till a month ago or so it took 15-20 > > minutes to run the test suite. > > Can you compare the build with and without animal-sniffer? Just to > have > an idea of what is the difference. Anyhow five minutes seems > acceptable > to me. The overhead is roughly 50 seconds: using [merged] commit hash 5845c732560dc325132661e1d1260de0a096c6b7 and the animal-sniffer patch rebased on top of it: mvn clean install -DskipTests: 2:55.76 minutes mvn clean install: 4:49.28 minutes using [merged] commit hash 5845c732560dc325132661e1d1260de0a096c6b7: mvn clean install -DskipTests: 2:05:40 minutes mvn clean install: 3:57.68 minutes [Note: this is done on my personal machine, with everything closed except the terminal running mvn, but this is still hardly a strict benchmark] > > >> Also need to make sure that the new dependency is available in the > >> build > >> environments we use. > > Built it against brew's repo, seemed to work fine. > > If you have any more suggestions on how to check it, please advise. > > That is very good. Actually building there would be even better. > > >> I am specially concerned about the Fedora build > >> system, where we have the plugin but not the signatures for the > >> JDKs. > > The signatures are provided as part of the plugin - they are not > > taken directly from the JDK. > > Or am I missing something in your point? > > I don't know very well this plugin, but it is my understanding that > the > signatures are additional dependencies that need to be downloaded > from > the maven repository. In your patch you are using the following: > > > org.jvnet.animal-sniffer > java1.6 > 1.0 > > > This org.jvnet.animal-sniffer:java1.6:1.0 artifact is what I can't > find > in the Fedora build system. Not a big problem, this can be patched > out > while building the package, just a minor inconvenience. Now I get your drift. Odd indeed, and I think this actually may spell a NACK for this patch - we don't want to add more inconveniences to the build process. Perhaps we should add this check as an optional step in maven, like you originally suggested? That way developers have a decent tool for performing this check, without having to necessarily interfere with the build system. > > >> This means that we will need to ignore the plugin or build the > >> signatures ourselves. > > Not so - see above. > > > >> > >> Also take into account that every new maven plugin we add to the > >> POMs > >> introduces new potential problems with the maven eclipse support. > > True. > > IMHO, it's a small price to pay, but I guess that's why we discuss > > things upstream - to get different opinions ;-) > > Well, for me personally the price is actually zero, as I don't use > the > Eclipse maven support ;-) . But I know that many people hates when > they > try to import the projects and they get errors because of plugins > that > Eclipse doesn't understand. Let's see what they think. > > >> I think we can leave the decision to each developer, maybe > >> providing > >> an > >> script that calls "mvn animal-sniffer:check ..." with the right > >> parameters, maybe with git pre-commit hook, to make it more > >> automatic. > > I really don't like this approach, but again - difference of > > opinions :-) > > Let's gather somemore feedback before deciding either way? > > Yes, of course. In my opinion adding this check is a good idea, and > you > already cleared most of the objections. > > >> This combined with the Jenkins checks can be a good compromise. > > -- > 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 amureini at redhat.com Mon Jul 23 16:35:22 2012 From: amureini at redhat.com (Allon Mureinik) Date: Mon, 23 Jul 2012 12:35:22 -0400 (EDT) Subject: [Engine-devel] java 1.6 compatibility no more? In-Reply-To: <500D3902.40402@redhat.com> Message-ID: <1911983177.1929967.1343061322786.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Juan Hernandez" > Cc: "Allon Mureinik" , engine-devel at ovirt.org > Sent: Monday, July 23, 2012 2:44:02 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/23/2012 02:31 PM, Juan Hernandez wrote: > > Well, for me personally the price is actually zero, as I don't use > > the > > Eclipse maven support ;-) . But I know that many people hates when > > they > > try to import the projects and they get errors because of plugins > > that > > Eclipse doesn't understand. Let's see what they think. > > ovirt should load in eclipse without any error, and we are working on > cleaning this up as it currently requires manual work to clean up the > errors to work in eclipse (which i find less than friendly to new > community members) > Agreed. I didn't notice any problems in working in Eclipse (I use Juno) + Maven + this plugin, but if anyone did, I'd appreciate the feedback. From ItzikB at mellanox.com Tue Jul 24 07:39:05 2012 From: ItzikB at mellanox.com (Itzik Brown) Date: Tue, 24 Jul 2012 07:39:05 +0000 Subject: [Engine-devel] Migration status of a VM Message-ID: <4488206DC085244C886DBC9E7038B6892AA3F795@MTRDAG01.mtl.com> Hi, Is it possible to know the status of a VM through the API - whether it's in a migration process and if it is , what are the source and destination? Thanks, Itzik -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpeer at redhat.com Tue Jul 24 08:12:54 2012 From: lpeer at redhat.com (Livnat Peer) Date: Tue, 24 Jul 2012 11:12:54 +0300 Subject: [Engine-devel] Migration status of a VM In-Reply-To: <4488206DC085244C886DBC9E7038B6892AA3F795@MTRDAG01.mtl.com> References: <4488206DC085244C886DBC9E7038B6892AA3F795@MTRDAG01.mtl.com> Message-ID: <500E5906.7010109@redhat.com> On 24/07/12 10:39, Itzik Brown wrote: > Hi, > > > > Is it possible to know the status of a VM through the API ? whether it's > in a migration process and if it is , what are the source and destination? > > > > Thanks, > > Itzik > Hi Itzik, The status is part of the VM in the API, when the VM is migrating the VM status changes to migrating The source host is available in the VM in property named host (it is mapped to run_on_vds in the backend) The destination - well it seems to not be mapped in the api, in the backend we hold it in VmDynamic migrating_to_vds Ori - do you know why we don't have it in the VM in the API? Anyway it looks like an easy fix and maybe you can open a BZ for it. Livnat > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From simon at redhat.com Tue Jul 24 08:16:15 2012 From: simon at redhat.com (Simon Grinberg) Date: Tue, 24 Jul 2012 04:16:15 -0400 (EDT) Subject: [Engine-devel] Is ovirt-engine-cli expected for 3.1? In-Reply-To: <1083173245.880443.1343057456033.JavaMail.root@redhat.com> Message-ID: <621172820.2163798.1343117775439.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Steve Gordon" > To: engine-devel at ovirt.org > Sent: Monday, July 23, 2012 6:30:56 PM > Subject: [Engine-devel] Is ovirt-engine-cli expected for 3.1? > > Hi guys, > > On the release notes draft [1] one of the items is "New Python CLI, > packaged as ??? (CLI).". The CLI page on the wiki says the package > is ovirt-engine-cli, but this package doesn't exist in the beta > repo. Is the CLI actually being delivered? Hopefully. You guys are already writing the book :) > > Thanks, > > Steve > > [1] http://wiki.ovirt.org/wiki/Release_Notes_Draft > [2] http://wiki.ovirt.org/wiki/CLI > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From oschreib at redhat.com Tue Jul 24 09:27:33 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Tue, 24 Jul 2012 05:27:33 -0400 (EDT) Subject: [Engine-devel] Is ovirt-engine-cli expected for 3.1? In-Reply-To: <1083173245.880443.1343057456033.JavaMail.root@redhat.com> Message-ID: <753315416.1759679.1343122053929.JavaMail.root@redhat.com> ----- Original Message ----- > Hi guys, > > On the release notes draft [1] one of the items is "New Python CLI, > packaged as ??? (CLI).". The CLI page on the wiki says the package > is ovirt-engine-cli, but this package doesn't exist in the beta > repo. Is the CLI actually being delivered? Yes, it should be delivered. I added both cli and SDK to the beta repo. we had some issues regenerating the repo last week, and probably forgot it. > > Thanks, > > Steve > > [1] http://wiki.ovirt.org/wiki/Release_Notes_Draft > [2] http://wiki.ovirt.org/wiki/CLI > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From dfediuck at redhat.com Wed Jul 25 14:45:25 2012 From: dfediuck at redhat.com (Doron Fediuck) Date: Wed, 25 Jul 2012 17:45:25 +0300 Subject: [Engine-devel] Additional info on patch reviewers Message-ID: <5975707.jI6rkkT3Cm@doronf-laptop> Hi, This may prove to be useful sometime... It is possible to ask gerrit to show a reviewer name, along the verify or code review columns. In order to set it, go to the settings link (up-right corner), and choose Preferences. Check the line "Display Person Name In Review Category". See the attached for sample and what to set. -- /d "This message will self destruct in the future. Or not." -------------- next part -------------- A non-text attachment was scrubbed... Name: gerrit-v-r-columns.png Type: image/png Size: 12036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gerrit-settings-fixed.png Type: image/png Size: 22501 bytes Desc: not available URL: From George.Costea at netapp.com Wed Jul 25 15:25:17 2012 From: George.Costea at netapp.com (Costea, George) Date: Wed, 25 Jul 2012 15:25:17 +0000 Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <8ea8d76e-a6da-496c-808b-0ad1662ff0c9@zmail16.collab.prod.int.phx2.redhat.com> References: <8ea8d76e-a6da-496c-808b-0ad1662ff0c9@zmail16.collab.prod.int.phx2.redhat.com> Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A480126A6B7@SACEXCMBX04-PRD.hq.netapp.com> Hi Vojtech, I just had a chance to try the patch today and it works great. When I click the ?New Server? button on the ?Virtual Machines? tab I see the alert. What do I do to add a new button beside of the ?New Server? button or at the end after the ?Guide Me? button? I would like to add my own button there and then invoke my own UI built with GWT. Thanks, George From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Vojtech Szocs Sent: Friday, July 20, 2012 4:38 PM To: engine-devel Subject: [Engine-devel] oVirt UI Plugins: Update on current progress Hi guys, I've spent some time working on UI Plugins proof-of-concept (PoC) implementation, and thought I'd share my results with you. I've attached a patch that reflects the current progress. The actual PoC implementation takes some inspiration from oVirt UI Plugins wiki page, and simplifies/streamlines/improves its main concepts. The goal is to have simple-to-use, yet flexible and robust plugin infrastructure. Major changes to the original design are outlined below. Each UI plugin runs within the context of an iframe, and therefore requires a plugin source page that executes the actual plugin code. * iframe is essentially the sandbox for each plugin. We can disable plugins by detaching their iframe elements from the main document during WebAdmin runtime. This also allows us to implement features such as plugin safe mode (no plugins loaded on WebAdmin startup). * Plugin source pages and WebAdmin host page share the same origin (protocol, domain, port), with plugin source pages being served through EngineManager application server (JBoss AS). This is to avoid cross-domain window/iframe communication issues, when the actual plugin code running in an iframe tries to register itself into WebAdmin main document's pluginApi object. * There's a servlet designed to render plugin source page for all plugins (PluginSourcePageServlet). For the given plugin, it detects its dependencies (3rd party JavaScript libraries) and configuration object (JSON data), reads the actual plugin code, and assembles everything into the resulting HTML page (to be evaluated by the plugin iframe). * iframe isolates plugin dependencies (3rd party JavaScript libraries) from other plugins and the main WebAdmin document. In practice, this means that plugin A can use jQuery 1.7 and plugin B can use jQuery 1.6 without the fear of any clashes. * Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear), and point to GWT plugin application host page. The current PoC declares a simple plugin that gets loaded using hard-coded values in PluginSourcePageServlet. Actual plugin code registers the plugin into global pluginApi.plugins object, with one sample event handler function (ActionButtonClick). Just after that, the plugin reports in as ready by calling pluginApi.ready function. This essentially puts the plugin into use within WebAdmin. To simulate extension point (application event to be consumed by plugins), when the user clicks "New server" button on "Virtual Machines" main tab, ActionButtonClickEvent gets fired through WebAdmin event bus. PluginEventHandler receives this event and invokes ActionButtonClick event handler function on all plugins. (Note: for passing context objects from WebAdmin to plugin event handler functions, I'm planning to experiment with gwt-exporter project [1]. This would greatly simplify the way how WebAdmin exposes context-specific plugin API to event handler functions.) As for the next step, I suggest to have some meeting (conference) to discuss the PoC in detail, and outline tasks for the near future. Also, please let me know what you think of the PoC so far. Cheers, Vojtech [1] http://code.google.com/p/gwt-exporter/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From snmishra at linux.vnet.ibm.com Thu Jul 26 14:36:43 2012 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Thu, 26 Jul 2012 07:36:43 -0700 Subject: [Engine-devel] Adding VNC support Message-ID: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> Hi, I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments? Thanks Sharad Mishra IBM From acathrow at redhat.com Thu Jul 26 14:46:35 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 26 Jul 2012 10:46:35 -0400 (EDT) Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> Message-ID: ----- Original Message ----- > From: snmishra at linux.vnet.ibm.com > To: engine-devel at ovirt.org > Sent: Thursday, July 26, 2012 10:36:43 AM > Subject: [Engine-devel] Adding VNC support > > > Hi, > > I am looking at adding VNC support in ovirt. What does the > community think? Ideas, suggestions, comments? We've spoken about adding NoVNC which I think makes the most sense, otherwise we have to worry about handling multiple types of VNC client, xpis, ActiveX, Mac support etc .... > > Thanks > Sharad Mishra > IBM > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ewoud+ovirt at kohlvanwijngaarden.nl Thu Jul 26 14:51:43 2012 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Thu, 26 Jul 2012 16:51:43 +0200 Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> Message-ID: <20120726145143.GA23545@bogey.xentower.nl> On Thu, Jul 26, 2012 at 07:36:43AM -0700, snmishra at linux.vnet.ibm.com wrote: > I am looking at adding VNC support in ovirt. What does the community > think? Ideas, suggestions, comments? By that I think you mean adding VNC support to the java-based web interface. In that case +1. I can recommend noVNC[1], but you do need a websockets proxy. I can recommend VNCAuthProxy[2] as a programmable proxy with a JSON control channel. On the plus side all dependencies are in fedora/epel. Downside is no IPv6 support. Maybe you can also write a pure java implementation integrate this into the engine itself? [1]: http://kanaka.github.com/noVNC/ [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/ From simon at redhat.com Thu Jul 26 14:57:23 2012 From: simon at redhat.com (Simon Grinberg) Date: Thu, 26 Jul 2012 10:57:23 -0400 (EDT) Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> Message-ID: <961310393.3777565.1343314643843.JavaMail.root@redhat.com> ----- Original Message ----- > From: snmishra at linux.vnet.ibm.com > To: engine-devel at ovirt.org > Sent: Thursday, July 26, 2012 5:36:43 PM > Subject: [Engine-devel] Adding VNC support > > > Hi, > > I am looking at adding VNC support in ovirt. What does the > community think? Ideas, suggestions, comments? If you can, I think it will be welcomed. The problem (as I recall, and I may be wrong) is that there is no VNC xpi available, thus connection is not possible directly through the portal. If you want to use VNC it is possible today, you'll have to set the ticket/password via the API and the connect with VNC viewer. With that said, my personal opinion is that it's not necessary except for those who really like VNC. SPICE has an available XPI, and when you don't use the Spice Drivers the default mode is in par with VNC. So why to bother? > > Thanks > Sharad Mishra > IBM > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From acathrow at redhat.com Thu Jul 26 15:07:08 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Thu, 26 Jul 2012 11:07:08 -0400 (EDT) Subject: [Engine-devel] Adding VNC support In-Reply-To: <961310393.3777565.1343314643843.JavaMail.root@redhat.com> Message-ID: <5e5e949a-f968-43c1-9364-b601d7b9ecc2@zmail20.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Simon Grinberg" > To: snmishra at linux.vnet.ibm.com > Cc: engine-devel at ovirt.org > Sent: Thursday, July 26, 2012 10:57:23 AM > Subject: Re: [Engine-devel] Adding VNC support > > > > ----- Original Message ----- > > From: snmishra at linux.vnet.ibm.com > > To: engine-devel at ovirt.org > > Sent: Thursday, July 26, 2012 5:36:43 PM > > Subject: [Engine-devel] Adding VNC support > > > > > > Hi, > > > > I am looking at adding VNC support in ovirt. What does the > > community think? Ideas, suggestions, comments? > > If you can, I think it will be welcomed. > > The problem (as I recall, and I may be wrong) is that there is no VNC > xpi available, thus connection is not possible directly through the > portal. If you want to use VNC it is possible today, you'll have to > set the ticket/password via the API and the connect with VNC viewer. > > With that said, my personal opinion is that it's not necessary except > for those who really like VNC. SPICE has an available XPI, and when > you don't use the Spice Drivers the default mode is in par with VNC. > So why to bother? if you don't have a spice client installed, if you have really bad bandwidth, if you're on a Mac, iOS, etc........ > > > > > > Thanks > > Sharad Mishra > > IBM > > > > _______________________________________________ > > 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 George.Costea at netapp.com Thu Jul 26 20:33:04 2012 From: George.Costea at netapp.com (Costea, George) Date: Thu, 26 Jul 2012 20:33:04 +0000 Subject: [Engine-devel] Building ovirt engine instructions Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A480126CBF9@SACEXCMBX04-PRD.hq.netapp.com> I think the wiki page (http://wiki.ovirt.org/wiki/Building_Ovirt_Engine) to build the ovirt engine is outdated. When I reach the deploy section, it always fails. Is there an update to get the ear file deployed? The Eclipse instructions (http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE) also seem to be out of date. When I follow the steps to change project settings, I get an error stating that "A cycle was detected in the build path of the project..." Could we get an update on this too? Thanks, George -------------- next part -------------- An HTML attachment was scrubbed... URL: From ovedo at redhat.com Thu Jul 26 21:34:24 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Thu, 26 Jul 2012 17:34:24 -0400 (EDT) Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A480126CBF9@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: ----- Original Message ----- > From: "George Costea" > To: engine-devel at ovirt.org > Sent: Thursday, July 26, 2012 11:33:04 PM > Subject: [Engine-devel] Building ovirt engine instructions > > > > > > I think the wiki page ( > http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the > ovirt engine is outdated. When I reach the deploy section, it always > fails. Is there an update to get the ear file deployed? > > Can you elaborate more on the issue? What's the exact failure/error you see when deploying? > > The Eclipse instructions ( > http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem to > be out of date. When I follow the steps to change project settings, > I get an error stating that ?A cycle was detected in the build path > of the project...? Could we get an update on this too? > > > > Thanks, > > George > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From George.Costea at netapp.com Thu Jul 26 21:58:18 2012 From: George.Costea at netapp.com (Costea, George) Date: Thu, 26 Jul 2012 21:58:18 +0000 Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: References: <6C8AC8C50E170C4E9B44D47B39B24A480126CBF9@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A480126CD6E@SACEXCMBX04-PRD.hq.netapp.com> It works fine from the CLI (I was running out of memory). I'm still getting an issue with Eclipse though about a cycle being detected from the build path. -----Original Message----- From: Oved Ourfalli [mailto:ovedo at redhat.com] Sent: Thursday, July 26, 2012 5:34 PM To: Costea, George Cc: engine-devel at ovirt.org Subject: Re: [Engine-devel] Building ovirt engine instructions ----- Original Message ----- > From: "George Costea" > To: engine-devel at ovirt.org > Sent: Thursday, July 26, 2012 11:33:04 PM > Subject: [Engine-devel] Building ovirt engine instructions > > > > > > I think the wiki page ( > http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the ovirt > engine is outdated. When I reach the deploy section, it always fails. > Is there an update to get the ear file deployed? > > Can you elaborate more on the issue? What's the exact failure/error you see when deploying? > > The Eclipse instructions ( > http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem to be > out of date. When I follow the steps to change project settings, I get > an error stating that ?A cycle was detected in the build path of the > project...? Could we get an update on this too? > > > > Thanks, > > George > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From yzaslavs at redhat.com Fri Jul 27 05:12:49 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Fri, 27 Jul 2012 08:12:49 +0300 Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A480126CD6E@SACEXCMBX04-PRD.hq.netapp.com> References: <6C8AC8C50E170C4E9B44D47B39B24A480126CBF9@SACEXCMBX04-PRD.hq.netapp.com> <6C8AC8C50E170C4E9B44D47B39B24A480126CD6E@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: <50122351.7080802@redhat.com> On 07/27/2012 12:58 AM, Costea, George wrote: > It works fine from the CLI (I was running out of memory). I'm still getting an issue with Eclipse though about a cycle being detected from the build path. Please elaborate on this cyclic dependency (I guess this is the issue, right?) What matters the most is that you can build from CLI. Some of the oVirt engine mantainers do not build from Eclipse (I personally find the maven plugin to be too buggy) , but it's a matter of personal preference. We will try to help you regardlessly Yair > > -----Original Message----- > From: Oved Ourfalli [mailto:ovedo at redhat.com] > Sent: Thursday, July 26, 2012 5:34 PM > To: Costea, George > Cc: engine-devel at ovirt.org > Subject: Re: [Engine-devel] Building ovirt engine instructions > > > > ----- Original Message ----- >> From: "George Costea" >> To: engine-devel at ovirt.org >> Sent: Thursday, July 26, 2012 11:33:04 PM >> Subject: [Engine-devel] Building ovirt engine instructions >> >> >> >> >> >> I think the wiki page ( >> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the ovirt >> engine is outdated. When I reach the deploy section, it always fails. >> Is there an update to get the ear file deployed? >> >> > Can you elaborate more on the issue? What's the exact failure/error you see when deploying? > >> >> The Eclipse instructions ( >> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem to be >> out of date. When I follow the steps to change project settings, I get >> an error stating that ?A cycle was detected in the build path of the >> project...? Could we get an update on this too? >> >> >> >> Thanks, >> >> George >> >> >> _______________________________________________ >> 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 Fri Jul 27 05:20:56 2012 From: iheim at redhat.com (Itamar Heim) Date: Fri, 27 Jul 2012 08:20:56 +0300 Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: <50122351.7080802@redhat.com> References: <6C8AC8C50E170C4E9B44D47B39B24A480126CBF9@SACEXCMBX04-PRD.hq.netapp.com> <6C8AC8C50E170C4E9B44D47B39B24A480126CD6E@SACEXCMBX04-PRD.hq.netapp.com> <50122351.7080802@redhat.com> Message-ID: <50122538.3080503@redhat.com> On 07/27/2012 08:12 AM, Yair Zaslavsky wrote: > On 07/27/2012 12:58 AM, Costea, George wrote: >> It works fine from the CLI (I was running out of memory). I'm still >> getting an issue with Eclipse though about a cycle being detected from >> the build path. > > Please elaborate on this cyclic dependency (I guess this is the issue, > right?) > > What matters the most is that you can build from CLI. > Some of the oVirt engine mantainers do not build from Eclipse (I > personally find the maven plugin to be too buggy) , but it's a matter of > personal preference. We will try to help you regardlessly we must get eclipse to work easily and without errors. i noticed Allon just published this to disable m2plugin for eclipse, could be relevant (since not applied yet, you would need to apply locally) http://gerrit.ovirt.org/#/c/6669/ > > Yair > >> >> -----Original Message----- >> From: Oved Ourfalli [mailto:ovedo at redhat.com] >> Sent: Thursday, July 26, 2012 5:34 PM >> To: Costea, George >> Cc: engine-devel at ovirt.org >> Subject: Re: [Engine-devel] Building ovirt engine instructions >> >> >> >> ----- Original Message ----- >>> From: "George Costea" >>> To: engine-devel at ovirt.org >>> Sent: Thursday, July 26, 2012 11:33:04 PM >>> Subject: [Engine-devel] Building ovirt engine instructions >>> >>> >>> >>> >>> >>> I think the wiki page ( >>> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the ovirt >>> engine is outdated. When I reach the deploy section, it always fails. >>> Is there an update to get the ear file deployed? >>> >>> >> Can you elaborate more on the issue? What's the exact failure/error >> you see when deploying? >> >>> >>> The Eclipse instructions ( >>> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem to be >>> out of date. When I follow the steps to change project settings, I get >>> an error stating that ?A cycle was detected in the build path of the >>> project...? Could we get an update on this too? >>> >>> >>> >>> Thanks, >>> >>> George >>> >>> >>> _______________________________________________ >>> 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 alonbl at redhat.com Thu Jul 26 14:55:36 2012 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 26 Jul 2012 17:55:36 +0300 Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120726145143.GA23545@bogey.xentower.nl> References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> <20120726145143.GA23545@bogey.xentower.nl> Message-ID: On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden wrote: > On Thu, Jul 26, 2012 at 07:36:43AM -0700, snmishra at linux.vnet.ibm.com wrote: >> I am looking at adding VNC support in ovirt. What does the community >> think? Ideas, suggestions, comments? > By that I think you mean adding VNC support to the java-based web > interface. In that case +1. I can recommend noVNC[1], but you do need a > websockets proxy. I can recommend VNCAuthProxy[2] as a programmable > proxy with a JSON control channel. On the plus side all dependencies are > in fedora/epel. Downside is no IPv6 support. Maybe you can also write a > pure java implementation integrate this into the engine itself? > > [1]: http://kanaka.github.com/noVNC/ > [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/ Or launch client program via MIME bindings[1] both for Vnc and Spice. Not as neat as "noVnc" but will work in most scenarios, without having to maintain the actual console implementation. Regards, Alon. [1] https://bugzilla.redhat.com/show_bug.cgi?id=843410 From iheim at redhat.com Fri Jul 27 08:55:56 2012 From: iheim at redhat.com (Itamar Heim) Date: Fri, 27 Jul 2012 11:55:56 +0300 Subject: [Engine-devel] Adding VNC support In-Reply-To: References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> <20120726145143.GA23545@bogey.xentower.nl> Message-ID: <5012579C.5000702@redhat.com> On 07/26/2012 05:55 PM, Alon Bar-Lev wrote: > On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden > wrote: >> On Thu, Jul 26, 2012 at 07:36:43AM -0700, snmishra at linux.vnet.ibm.com wrote: >>> I am looking at adding VNC support in ovirt. What does the community >>> think? Ideas, suggestions, comments? >> By that I think you mean adding VNC support to the java-based web >> interface. In that case +1. I can recommend noVNC[1], but you do need a >> websockets proxy. I can recommend VNCAuthProxy[2] as a programmable >> proxy with a JSON control channel. On the plus side all dependencies are >> in fedora/epel. Downside is no IPv6 support. Maybe you can also write a >> pure java implementation integrate this into the engine itself? >> >> [1]: http://kanaka.github.com/noVNC/ >> [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/ > > Or launch client program via MIME bindings[1] both for Vnc and Spice. > Not as neat as "noVnc" but will work in most scenarios, without having > to maintain the actual console implementation. what would users need to do at client side to configure the mime bindings? From michal.skrivanek at redhat.com Fri Jul 27 09:01:32 2012 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Fri, 27 Jul 2012 11:01:32 +0200 Subject: [Engine-devel] Adding VNC support In-Reply-To: References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> <20120726145143.GA23545@bogey.xentower.nl> Message-ID: <0E5BF7E2-EFCF-43A1-88B6-AB36399C2C3C@redhat.com> On Jul 26, 2012, at 16:55 , Alon Bar-Lev wrote: > On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden > wrote: >> On Thu, Jul 26, 2012 at 07:36:43AM -0700, snmishra at linux.vnet.ibm.com wrote: >>> I am looking at adding VNC support in ovirt. What does the community >>> think? Ideas, suggestions, comments? >> By that I think you mean adding VNC support to the java-based web >> interface. In that case +1. I can recommend noVNC[1], but you do need a >> websockets proxy. I can recommend VNCAuthProxy[2] as a programmable >> proxy with a JSON control channel. On the plus side all dependencies are >> in fedora/epel. Downside is no IPv6 support. Maybe you can also write a >> pure java implementation integrate this into the engine itself? >> >> [1]: http://kanaka.github.com/noVNC/ >> [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/ > > Or launch client program via MIME bindings[1] both for Vnc and Spice. > Not as neat as "noVnc" but will work in most scenarios, without having > to maintain the actual console implementation. I would think there are many people out there who are not able to use current spice client, or not willing to(hate switching from chrome to firefox:-) Sure they can set up things manually but it would be way more convenient to allow a simple external launch of their VNC client of choice > > Regards, > Alon. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=843410 > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From George.Costea at netapp.com Fri Jul 27 11:03:14 2012 From: George.Costea at netapp.com (Costea, George) Date: Fri, 27 Jul 2012 11:03:14 +0000 Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: <50122351.7080802@redhat.com> References: <6C8AC8C50E170C4E9B44D47B39B24A480126CBF9@SACEXCMBX04-PRD.hq.netapp.com> <6C8AC8C50E170C4E9B44D47B39B24A480126CD6E@SACEXCMBX04-PRD.hq.netapp.com> <50122351.7080802@redhat.com> Message-ID: <6C8AC8C50E170C4E9B44D47B39B24A480126D751@SACEXCMBX04-PRD.hq.netapp.com> I get to the step that reads, "Change project settings to Resolve compilation errors." After completing the first 3 steps below: restapi-definition -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/xjc webadmin -> project -> properties -> java build path -> source -> add source folder-> target/generated-sources/{annotations,gwt,test-annotations} frontend -> project -> properties -> java build path -> source -> add source folder-> target/generated-sources/gwt I am left with 181 Errors. I then try the 4th step: frontend -> project -> properties -> Projects -> Add -> webadmin This introduces 5 errors stating, "A cycle was detected in the build path of project 'frontend'/'gwt-common'/'uicommonweb'/'userportal'/'webadmin'. The cycle consists of projects {frontend, webadmin, uicommonweb, gwt-common, userportal}" I then try the 5th step: sharedgwt -> project -> properties -> Projects -> Add -> common But there is no sharedgwt project. Does this provide enough detail? -----Original Message----- From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Yair Zaslavsky Sent: Friday, July 27, 2012 1:13 AM To: engine-devel at ovirt.org Subject: Re: [Engine-devel] Building ovirt engine instructions On 07/27/2012 12:58 AM, Costea, George wrote: > It works fine from the CLI (I was running out of memory). I'm still getting an issue with Eclipse though about a cycle being detected from the build path. Please elaborate on this cyclic dependency (I guess this is the issue, right?) What matters the most is that you can build from CLI. Some of the oVirt engine mantainers do not build from Eclipse (I personally find the maven plugin to be too buggy) , but it's a matter of personal preference. We will try to help you regardlessly Yair > > -----Original Message----- > From: Oved Ourfalli [mailto:ovedo at redhat.com] > Sent: Thursday, July 26, 2012 5:34 PM > To: Costea, George > Cc: engine-devel at ovirt.org > Subject: Re: [Engine-devel] Building ovirt engine instructions > > > > ----- Original Message ----- >> From: "George Costea" >> To: engine-devel at ovirt.org >> Sent: Thursday, July 26, 2012 11:33:04 PM >> Subject: [Engine-devel] Building ovirt engine instructions >> >> >> >> >> >> I think the wiki page ( >> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the ovirt >> engine is outdated. When I reach the deploy section, it always fails. >> Is there an update to get the ear file deployed? >> >> > Can you elaborate more on the issue? What's the exact failure/error you see when deploying? > >> >> The Eclipse instructions ( >> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem to >> be out of date. When I follow the steps to change project settings, I >> get an error stating that ?A cycle was detected in the build path of >> the project...? Could we get an update on this too? >> >> >> >> Thanks, >> >> George >> >> >> _______________________________________________ >> 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 vszocs at redhat.com Fri Jul 27 12:26:12 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 27 Jul 2012 08:26:12 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <500D434C.3040509@redhat.com> Message-ID: <1262673107.13240627.1343391972101.JavaMail.root@redhat.com> > what do you mean by a servlet here? I mean a dedicated servlet for rendering HTML page used to load the given plugin. Such servlet (PluginSourcePageServlet in PoC patch) would assemble following information into a single HTML page that represents the plugin: - plugin dependencies - plugin configuration - actual plugin code On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary. Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Vojtech Szocs" Cc: "engine-devel" , "Einav Cohen" Sent: Monday, July 23, 2012 2:27:56 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 03:26 PM, Vojtech Szocs wrote: > I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. > > As for cross-origin iframe communication issues, there are several ways how to address them: > - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss > - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) > > For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). what do you mean by a servlet here? > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > Sent: Monday, July 23, 2012 12:16:04 PM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >>> it is not supposed to be next to engine.jar, it is supposed to be >>> somewhere else entirely, served to clients like any static content via a >>> servelt. >> >> If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. > > we'll need to solve these in any case for plugins which do have an > existing external service. > >> >> In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? > > because once we tell people it is ok, it makes it our responsibility to > make sure they don't break during upgrades for example (or worse, not > fail the entire engine post an upgrade). > I'm not saying these are not solvable, but i'd rather not try to handle > them on the first cut of this framework. > >> >>> that's not the scope we discussed so far. >>> we discussed a 'static' plugin, which can use an external service or the >>> REST API. >> >> This was actually option [1] as described in my email below. >> >> From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" >> Sent: Monday, July 23, 2012 11:54:14 AM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>>> this implies server side code running on the engine, >>> >>> Actually, yes and no :) let me explain: >>> >>> - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served >> >> it is not supposed to be next to engine.jar, it is supposed to be >> somewhere else entirely, served to clients like any static content via a >> servelt. >> >>> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" >>> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" >> >> that's not the scope we discussed so far. >> we discussed a 'static' plugin, which can use an external service or the >> REST API. >> >>> >>>> which has additional implications on compatibility vs. ui plugins as discussed >>> >>> I don't think we need to worry about this :) >>> >>> If a GWT UI plugin web application needs to use Engine functionality, it can: >>> >>> - use REST API from within UI plugin (JavaScript) code [1] >>> - use REST API from within its server-side (Java) code [2] >> >> again, if we want to discuss an approach to making ui plugins which need >> server side cooperation not in a separate container of their own choice, >> different server, etc. - we can, but lets separate the discussion on the >> two. >> >>> >>> [1] - will be supported by UI plugin infrastructure >>> [2] - not supported by UI plugin infrastructure >>> >>> Vojtech >>> >>> >>> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Vojtech Szocs" >>> Cc: "engine-devel" , "Einav Cohen" >>> Sent: Monday, July 23, 2012 9:10:07 AM >>> Subject: Re: oVirt UI Plugins: Update on current progress >>> >>> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>>> Last but not least, writing plugins in Google Web Toolkit (GWT) should >>>> be as easy as providing your own plugin source page. Just deploy your >>>> GWT plugin application on JBoss AS (next to engine.ear), and point to >>>> GWT plugin application host page. >>> >>> this implies server side code running on the engine, which has >>> additional implications on compatibility vs. ui plugins as discussed so >>> far which would be java script >>> (I'm not against using GWT for them if the resulting java script can be >>> packaged for use as a UI plugin, but sever side code i prefer to be >>> isolated from engine until we'll define engine plugins). >>> >>> >> >> > > From iheim at redhat.com Fri Jul 27 12:42:08 2012 From: iheim at redhat.com (Itamar Heim) Date: Fri, 27 Jul 2012 15:42:08 +0300 Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <1262673107.13240627.1343391972101.JavaMail.root@redhat.com> References: <1262673107.13240627.1343391972101.JavaMail.root@redhat.com> Message-ID: <50128CA0.20907@redhat.com> On 07/27/2012 03:26 PM, Vojtech Szocs wrote: >> what do you mean by a servlet here? > > I mean a dedicated servlet for rendering HTML page used to load the given plugin. > > Such servlet (PluginSourcePageServlet in PoC patch) would assemble following information into a single HTML page that represents the plugin: > - plugin dependencies > - plugin configuration > - actual plugin code a builtin servelet to provide the plugins is fine. > > On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary. this again assumes custom code running in the engine, rather than static plugins > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > Sent: Monday, July 23, 2012 2:27:56 PM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 03:26 PM, Vojtech Szocs wrote: >> I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. >> >> As for cross-origin iframe communication issues, there are several ways how to address them: >> - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss >> - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) >> >> For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). > > what do you mean by a servlet here? > >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" >> Sent: Monday, July 23, 2012 12:16:04 PM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >>>> it is not supposed to be next to engine.jar, it is supposed to be >>>> somewhere else entirely, served to clients like any static content via a >>>> servelt. >>> >>> If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. >> >> we'll need to solve these in any case for plugins which do have an >> existing external service. >> >>> >>> In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? >> >> because once we tell people it is ok, it makes it our responsibility to >> make sure they don't break during upgrades for example (or worse, not >> fail the entire engine post an upgrade). >> I'm not saying these are not solvable, but i'd rather not try to handle >> them on the first cut of this framework. >> >>> >>>> that's not the scope we discussed so far. >>>> we discussed a 'static' plugin, which can use an external service or the >>>> REST API. >>> >>> This was actually option [1] as described in my email below. >>> >>> From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. >>> >>> Vojtech >>> >>> >>> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Vojtech Szocs" >>> Cc: "engine-devel" , "Einav Cohen" >>> Sent: Monday, July 23, 2012 11:54:14 AM >>> Subject: Re: oVirt UI Plugins: Update on current progress >>> >>> On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>>>> this implies server side code running on the engine, >>>> >>>> Actually, yes and no :) let me explain: >>>> >>>> - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served >>> >>> it is not supposed to be next to engine.jar, it is supposed to be >>> somewhere else entirely, served to clients like any static content via a >>> servelt. >>> >>>> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" >>>> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" >>> >>> that's not the scope we discussed so far. >>> we discussed a 'static' plugin, which can use an external service or the >>> REST API. >>> >>>> >>>>> which has additional implications on compatibility vs. ui plugins as discussed >>>> >>>> I don't think we need to worry about this :) >>>> >>>> If a GWT UI plugin web application needs to use Engine functionality, it can: >>>> >>>> - use REST API from within UI plugin (JavaScript) code [1] >>>> - use REST API from within its server-side (Java) code [2] >>> >>> again, if we want to discuss an approach to making ui plugins which need >>> server side cooperation not in a separate container of their own choice, >>> different server, etc. - we can, but lets separate the discussion on the >>> two. >>> >>>> >>>> [1] - will be supported by UI plugin infrastructure >>>> [2] - not supported by UI plugin infrastructure >>>> >>>> Vojtech >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Vojtech Szocs" >>>> Cc: "engine-devel" , "Einav Cohen" >>>> Sent: Monday, July 23, 2012 9:10:07 AM >>>> Subject: Re: oVirt UI Plugins: Update on current progress >>>> >>>> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>>>> Last but not least, writing plugins in Google Web Toolkit (GWT) should >>>>> be as easy as providing your own plugin source page. Just deploy your >>>>> GWT plugin application on JBoss AS (next to engine.ear), and point to >>>>> GWT plugin application host page. >>>> >>>> this implies server side code running on the engine, which has >>>> additional implications on compatibility vs. ui plugins as discussed so >>>> far which would be java script >>>> (I'm not against using GWT for them if the resulting java script can be >>>> packaged for use as a UI plugin, but sever side code i prefer to be >>>> isolated from engine until we'll define engine plugins). >>>> >>>> >>> >>> >> >> > > From vszocs at redhat.com Fri Jul 27 12:58:30 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 27 Jul 2012 08:58:30 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A4801265B5F@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: <286078781.13301750.1343393910080.JavaMail.root@redhat.com> > It appears to me that the cross-origin issue is caused because the plugin definition is embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires that all plugins also exist within the same origin. Yes, WebAdmin host page is served through Engine JBoss and therefore sits on its origin. WebAdmin host page loads a plugin by creating an iframe element and setting its "src" attribute to HTML page that's responsible for loading the actual plugin code. But if the plugin HTML page originates for a different origin (protocol, domain, port), plugin code that runs within an iframe element is unable to access top-level (WebAdmin host page) pluginApi object, because of Same-Origin-Policy restriction. As Itamar mentioned, we shouldn't deploy custom UI plugins on Engine JBoss, as it would complicate its maintenance from package perspective. There are currently two ways how plugins can be developed, and I'd like to discuss these on the upcoming meeting: --- 1) The "Standard" way: use standard Engine servlet (PluginSourcePageServlet in PoC) to take care of rendering plugin HTML page. This servlet will pick up all plugin dependencies, plugin configuration and actual plugin code, and produce the resulting HTML page used to load the plugin. Because this servlet runs on Engine JBoss, there will be no cross-origin issues. Pros: - well-defined way how to develop plugins (separation of dependencies, configuration and actual plugin code) - no need to take care of producing HTML plugin page (servlet will take care of that) Cons: - doesn't support custom plugin bootstrap schemes (e.g. cannot use GWT to develop plugins) - due to Same-Origin-Policy, plugin can communicate with Engine (e.g. REST API), but not with other external services (on other origins), unless you implement cross-origin communication schemes such as JSONP --- 2) The "Custom" way: run your own application server, deploy your plugin code there (client JavaScript code, plus optional server code). Instead of using standard Engine servlet, use your own application server to serve plugin HTML page. This means that you are responsible for assembling everything (plugin dependencies, configuration, code, etc.) into HTML page used to load your plugin. Pros: - supports custom plugin bootstrap schemes (e.g. can use GWT to develop plugins), since you are responsible for providing plugin HTML content - supports hosting custom server-side plugin code (in addition to plugins being able to call Engine through APIs like REST) Cons: - to work around Same-Origin-Policy (and get hold of WebAdmin's pluginApi object), your application server needs to use CORS (Cross-Origin Resource Sharing), which basically means extra HTTP response header --- Originally, I wanted to start with (1) (the "Standard" way), but we should discuss and evaluate both approaches. Vojtech ----- Original Message ----- From: "George Costea" To: "Vojtech Szocs" , "Itamar Heim" Cc: "engine-devel" Sent: Monday, July 23, 2012 3:33:12 PM Subject: RE: [Engine-devel] oVirt UI Plugins: Update on current progress It appears to me that the cross-origin issue is caused because the plugin definition is embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires that all plugins also exist within the same origin. Rather than extending the WebAdmin page with javascript, would it be possible to instead have an API that modifies that page with extensions? For example, the API tells it to add a new menu item that when launched would invoke the url registered with the extension. The new page is now rendered in a distinct window (much like early versions of GWT hosted mode created an embedded browser window). -George -----Original Message----- From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Vojtech Szocs Sent: Monday, July 23, 2012 8:27 AM To: Itamar Heim Cc: engine-devel Subject: Re: [Engine-devel] oVirt UI Plugins: Update on current progress I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. As for cross-origin iframe communication issues, there are several ways how to address them: - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Vojtech Szocs" Cc: "engine-devel" , "Einav Cohen" Sent: Monday, July 23, 2012 12:16:04 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >> it is not supposed to be next to engine.jar, it is supposed to be >> somewhere else entirely, served to clients like any static content >> via a servelt. > > If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. we'll need to solve these in any case for plugins which do have an existing external service. > > In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? because once we tell people it is ok, it makes it our responsibility to make sure they don't break during upgrades for example (or worse, not fail the entire engine post an upgrade). I'm not saying these are not solvable, but i'd rather not try to handle them on the first cut of this framework. > >> that's not the scope we discussed so far. >> we discussed a 'static' plugin, which can use an external service or >> the REST API. > > This was actually option [1] as described in my email below. > > From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > > Sent: Monday, July 23, 2012 11:54:14 AM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>> this implies server side code running on the engine, >> >> Actually, yes and no :) let me explain: >> >> - UI plugins developed in GWT need some context (plugin web >> application deployed next to engine.ear) from which their code will >> be served > > it is not supposed to be next to engine.jar, it is supposed to be > somewhere else entirely, served to clients like any static content via > a servelt. > >> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" >> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" > > that's not the scope we discussed so far. > we discussed a 'static' plugin, which can use an external service or > the REST API. > >> >>> which has additional implications on compatibility vs. ui plugins as >>> discussed >> >> I don't think we need to worry about this :) >> >> If a GWT UI plugin web application needs to use Engine functionality, it can: >> >> - use REST API from within UI plugin (JavaScript) code [1] >> - use REST API from within its server-side (Java) code [2] > > again, if we want to discuss an approach to making ui plugins which > need server side cooperation not in a separate container of their own > choice, different server, etc. - we can, but lets separate the > discussion on the two. > >> >> [1] - will be supported by UI plugin infrastructure [2] - not >> supported by UI plugin infrastructure >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" >> >> Sent: Monday, July 23, 2012 9:10:07 AM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>> Last but not least, writing plugins in Google Web Toolkit (GWT) >>> should be as easy as providing your own plugin source page. Just >>> deploy your GWT plugin application on JBoss AS (next to engine.ear), >>> and point to GWT plugin application host page. >> >> this implies server side code running on the engine, which has >> additional implications on compatibility vs. ui plugins as discussed >> so far which would be java script (I'm not against using GWT for them >> if the resulting java script can be packaged for use as a UI plugin, >> but sever side code i prefer to be isolated from engine until we'll >> define engine plugins). >> >> > > _______________________________________________ Engine-devel mailing list Engine-devel at ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel From vszocs at redhat.com Fri Jul 27 13:12:15 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 27 Jul 2012 09:12:15 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A480126A6B7@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: <648973533.13328488.1343394735306.JavaMail.root@redhat.com> Hi George, the PoC defines a simple ActionButtonClick event which is fired when the user clicks on "New Server" button, and WebAdmin invokes ActionButtonClick function on all plugins. This is just an example to demonstrate how plugin invocation could work. If you want to add new button to VM main tab, there should be a separate event fired when the VM main tab is rendered, with plugins providing extra button definitions. Alternatively, pluginApi object can provide some API to add these buttons at time when plugin code gets loaded. Unfortunately, this isn't part of the PoC yet, as I wanted to discuss this with you before continuing with PoC implementation. As for developing plugins with GWT, I've sent a mail about this, discussing two possible ways to develop plugins. We should evaluate pros/cons of each approach and decide which way to go first.. (the PoC contains hand-written JavaScript for now though) Vojtech ----- Original Message ----- From: "George Costea" To: "Vojtech Szocs" , "engine-devel" Sent: Wednesday, July 25, 2012 5:25:17 PM Subject: RE: [Engine-devel] oVirt UI Plugins: Update on current progress Hi Vojtech, I just had a chance to try the patch today and it works great. When I click the ?New Server? button on the ?Virtual Machines? tab I see the alert. What do I do to add a new button beside of the ?New Server? button or at the end after the ?Guide Me? button? I would like to add my own button there and then invoke my own UI built with GWT. Thanks, George From: engine-devel-bounces at ovirt.org [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Vojtech Szocs Sent: Friday, July 20, 2012 4:38 PM To: engine-devel Subject: [Engine-devel] oVirt UI Plugins: Update on current progress Hi guys, I've spent some time working on UI Plugins proof-of-concept (PoC) implementation, and thought I'd share my results with you. I've attached a patch that reflects the current progress. The actual PoC implementation takes some inspiration from oVirt UI Plugins wiki page, and simplifies/streamlines/improves its main concepts. The goal is to have simple-to-use, yet flexible and robust plugin infrastructure. Major changes to the original design are outlined below. Each UI plugin runs within the context of an iframe, and therefore requires a plugin source page that executes the actual plugin code. * iframe is essentially the sandbox for each plugin. We can disable plugins by detaching their iframe elements from the main document during WebAdmin runtime. This also allows us to implement features such as plugin safe mode (no plugins loaded on WebAdmin startup). * Plugin source pages and WebAdmin host page share the same origin (protocol, domain, port), with plugin source pages being served through EngineManager application server (JBoss AS). This is to avoid cross-domain window/iframe communication issues, when the actual plugin code running in an iframe tries to register itself into WebAdmin main document's pluginApi object. * There's a servlet designed to render plugin source page for all plugins ( PluginSourcePageServlet ). For the given plugin, it detects its dependencies (3rd party JavaScript libraries) and configuration object (JSON data), reads the actual plugin code, and assembles everything into the resulting HTML page (to be evaluated by the plugin iframe). * iframe isolates plugin dependencies (3rd party JavaScript libraries) from other plugins and the main WebAdmin document. In practice, this means that plugin A can use jQuery 1.7 and plugin B can use jQuery 1.6 without the fear of any clashes. * Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS (next to engine.ear ), and point to GWT plugin application host page. The current PoC declares a simple plugin that gets loaded using hard-coded values in PluginSourcePageServlet . Actual plugin code registers the plugin into global pluginApi.plugins object, with one sample event handler function ( ActionButtonClick ). Just after that, the plugin reports in as ready by calling pluginApi.ready function. This essentially puts the plugin into use within WebAdmin. To simulate extension point (application event to be consumed by plugins), when the user clicks "New server" button on "Virtual Machines" main tab, ActionButtonClickEvent gets fired through WebAdmin event bus. PluginEventHandler receives this event and invokes ActionButtonClick event handler function on all plugins. (Note: for passing context objects from WebAdmin to plugin event handler functions, I'm planning to experiment with gwt-exporter project [1]. This would greatly simplify the way how WebAdmin exposes context-specific plugin API to event handler functions.) As for the next step, I suggest to have some meeting (conference) to discuss the PoC in detail, and outline tasks for the near future. Also, please let me know what you think of the PoC so far. Cheers, Vojtech [1] http://code.google.com/p/gwt-exporter/ From vszocs at redhat.com Fri Jul 27 13:16:13 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Fri, 27 Jul 2012 09:16:13 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins: Update on current progress In-Reply-To: <50128CA0.20907@redhat.com> Message-ID: <234268285.13338771.1343394973245.JavaMail.root@redhat.com> > > On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary. > > this again assumes custom code running in the engine, rather than static > plugins Actually, users can deploy their plugins somewhere outside Engine JBoss (HTML page to load plugin, JavaScript representing the plugin code, plus optional server-side plugin code), and have them referenced from within WebAdmin. Vojtech ----- Original Message ----- From: "Itamar Heim" To: "Vojtech Szocs" Cc: "engine-devel" , "Einav Cohen" Sent: Friday, July 27, 2012 2:42:08 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/27/2012 03:26 PM, Vojtech Szocs wrote: >> what do you mean by a servlet here? > > I mean a dedicated servlet for rendering HTML page used to load the given plugin. > > Such servlet (PluginSourcePageServlet in PoC patch) would assemble following information into a single HTML page that represents the plugin: > - plugin dependencies > - plugin configuration > - actual plugin code a builtin servelet to provide the plugins is fine. > > On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary. this again assumes custom code running in the engine, rather than static plugins > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" > To: "Vojtech Szocs" > Cc: "engine-devel" , "Einav Cohen" > Sent: Monday, July 23, 2012 2:27:56 PM > Subject: Re: oVirt UI Plugins: Update on current progress > > On 07/23/2012 03:26 PM, Vojtech Szocs wrote: >> I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective. >> >> As for cross-origin iframe communication issues, there are several ways how to address them: >> - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss >> - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication) >> >> For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page). > > what do you mean by a servlet here? > >> >> Vojtech >> >> >> ----- Original Message ----- >> From: "Itamar Heim" >> To: "Vojtech Szocs" >> Cc: "engine-devel" , "Einav Cohen" >> Sent: Monday, July 23, 2012 12:16:04 PM >> Subject: Re: oVirt UI Plugins: Update on current progress >> >> On 07/23/2012 01:10 PM, Vojtech Szocs wrote: >>>> it is not supposed to be next to engine.jar, it is supposed to be >>>> somewhere else entirely, served to clients like any static content via a >>>> servelt. >>> >>> If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with. >> >> we'll need to solve these in any case for plugins which do have an >> existing external service. >> >>> >>> In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility? >> >> because once we tell people it is ok, it makes it our responsibility to >> make sure they don't break during upgrades for example (or worse, not >> fail the entire engine post an upgrade). >> I'm not saying these are not solvable, but i'd rather not try to handle >> them on the first cut of this framework. >> >>> >>>> that's not the scope we discussed so far. >>>> we discussed a 'static' plugin, which can use an external service or the >>>> REST API. >>> >>> This was actually option [1] as described in my email below. >>> >>> From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own. >>> >>> Vojtech >>> >>> >>> ----- Original Message ----- >>> From: "Itamar Heim" >>> To: "Vojtech Szocs" >>> Cc: "engine-devel" , "Einav Cohen" >>> Sent: Monday, July 23, 2012 11:54:14 AM >>> Subject: Re: oVirt UI Plugins: Update on current progress >>> >>> On 07/23/2012 12:40 PM, Vojtech Szocs wrote: >>>>> this implies server side code running on the engine, >>>> >>>> Actually, yes and no :) let me explain: >>>> >>>> - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served >>> >>> it is not supposed to be next to engine.jar, it is supposed to be >>> somewhere else entirely, served to clients like any static content via a >>> servelt. >>> >>>> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO" >>>> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES" >>> >>> that's not the scope we discussed so far. >>> we discussed a 'static' plugin, which can use an external service or the >>> REST API. >>> >>>> >>>>> which has additional implications on compatibility vs. ui plugins as discussed >>>> >>>> I don't think we need to worry about this :) >>>> >>>> If a GWT UI plugin web application needs to use Engine functionality, it can: >>>> >>>> - use REST API from within UI plugin (JavaScript) code [1] >>>> - use REST API from within its server-side (Java) code [2] >>> >>> again, if we want to discuss an approach to making ui plugins which need >>> server side cooperation not in a separate container of their own choice, >>> different server, etc. - we can, but lets separate the discussion on the >>> two. >>> >>>> >>>> [1] - will be supported by UI plugin infrastructure >>>> [2] - not supported by UI plugin infrastructure >>>> >>>> Vojtech >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Itamar Heim" >>>> To: "Vojtech Szocs" >>>> Cc: "engine-devel" , "Einav Cohen" >>>> Sent: Monday, July 23, 2012 9:10:07 AM >>>> Subject: Re: oVirt UI Plugins: Update on current progress >>>> >>>> On 07/20/2012 11:37 PM, Vojtech Szocs wrote: >>>>> Last but not least, writing plugins in Google Web Toolkit (GWT) should >>>>> be as easy as providing your own plugin source page. Just deploy your >>>>> GWT plugin application on JBoss AS (next to engine.ear), and point to >>>>> GWT plugin application host page. >>>> >>>> this implies server side code running on the engine, which has >>>> additional implications on compatibility vs. ui plugins as discussed so >>>> far which would be java script >>>> (I'm not against using GWT for them if the resulting java script can be >>>> packaged for use as a UI plugin, but sever side code i prefer to be >>>> isolated from engine until we'll define engine plugins). >>>> >>>> >>> >>> >> >> > > From Dustin.Schoenbrun at netapp.com Fri Jul 27 17:18:36 2012 From: Dustin.Schoenbrun at netapp.com (Schoenbrun, Dustin) Date: Fri, 27 Jul 2012 17:18:36 +0000 Subject: [Engine-devel] FW: Building ovirt engine instructions In-Reply-To: References: <6C8AC8C50E170C4E9B44D47B39B24A480126D751@SACEXCMBX04-PRD.hq.netapp.com>, Message-ID: <0A1534657992624AACDCA570F1D3E20003CD0641@SACEXCMBX03-PRD.hq.netapp.com> Hey All, Ricky sent these out this morning but it never hit the email blaster. I'm forwarding these on his behalf. If you have questions, please let either Ricky or I know. Thanks! -- Dustin Through some experimentation, I found a list of steps that seems to fix everything on my machines: restapi-definition -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/xjc webadmin -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/{annotations,gwt} frontend -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/gwt gwt-common -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/annotations userportal -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/{annotations,gwt} These make sure there can't be any cycles introduced, and resolve all errors in the projects. Let me know if any of this doesn't work for you. - Ricky On 7/27/12 7:03 AM, "Costea, George" wrote: >I get to the step that reads, "Change project settings to Resolve >compilation errors." > >After completing the first 3 steps below: > > restapi-definition -> project -> properties -> java build path -> >source -> add source folder -> target/generated-sources/xjc > webadmin -> project -> properties -> java build path -> source -> >add source folder-> >target/generated-sources/{annotations,gwt,test-annotations} > frontend -> project -> properties -> java build path -> source -> >add source folder-> target/generated-sources/gwt > >I am left with 181 Errors. I then try the 4th step: > > frontend -> project -> properties -> Projects -> Add -> webadmin > >This introduces 5 errors stating, "A cycle was detected in the build path >of project 'frontend'/'gwt-common'/'uicommonweb'/'userportal'/'webadmin'. > The cycle consists of projects {frontend, webadmin, uicommonweb, >gwt-common, userportal}" > >I then try the 5th step: > > sharedgwt -> project -> properties -> Projects -> Add -> common > >But there is no sharedgwt project. Does this provide enough detail? > >-----Original Message----- >From: engine-devel-bounces at ovirt.org >[mailto:engine-devel-bounces at ovirt.org] On Behalf Of Yair Zaslavsky >Sent: Friday, July 27, 2012 1:13 AM >To: engine-devel at ovirt.org >Subject: Re: [Engine-devel] Building ovirt engine instructions > >On 07/27/2012 12:58 AM, Costea, George wrote: >> It works fine from the CLI (I was running out of memory). I'm still >>getting an issue with Eclipse though about a cycle being detected from >>the build path. > >Please elaborate on this cyclic dependency (I guess this is the issue, >right?) > >What matters the most is that you can build from CLI. >Some of the oVirt engine mantainers do not build from Eclipse (I >personally find the maven plugin to be too buggy) , but it's a matter of >personal preference. We will try to help you regardlessly > >Yair > >> >> -----Original Message----- >> From: Oved Ourfalli [mailto:ovedo at redhat.com] >> Sent: Thursday, July 26, 2012 5:34 PM >> To: Costea, George >> Cc: engine-devel at ovirt.org >> Subject: Re: [Engine-devel] Building ovirt engine instructions >> >> >> >> ----- Original Message ----- >>> From: "George Costea" >>> To: engine-devel at ovirt.org >>> Sent: Thursday, July 26, 2012 11:33:04 PM >>> Subject: [Engine-devel] Building ovirt engine instructions >>> >>> >>> >>> >>> >>> I think the wiki page ( >>> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the ovirt >>> engine is outdated. When I reach the deploy section, it always fails. >>> Is there an update to get the ear file deployed? >>> >>> >> Can you elaborate more on the issue? What's the exact failure/error you >>see when deploying? >> >>> >>> The Eclipse instructions ( >>> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem to >>> be out of date. When I follow the steps to change project settings, I >>> get an error stating that ?A cycle was detected in the build path of >>> the project...? Could we get an update on this too? >>> >>> >>> >>> Thanks, >>> >>> George >>> >>> >>> _______________________________________________ >>> 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 amureini at redhat.com Fri Jul 27 18:04:11 2012 From: amureini at redhat.com (Allon Mureinik) Date: Fri, 27 Jul 2012 14:04:11 -0400 (EDT) Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A480126D751@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: <1257273193.4412562.1343412251134.JavaMail.root@redhat.com> Just had to reinstall and reconfigure Eclipse myself due to a yum upgrade misshap (kids, don't try this at home :-)), so here's some insight on the process. ----- Original Message ----- > From: "George Costea" > To: "Yair Zaslavsky" , engine-devel at ovirt.org > Sent: Friday, July 27, 2012 2:03:14 PM > Subject: Re: [Engine-devel] Building ovirt engine instructions > > I get to the step that reads, "Change project settings to Resolve > compilation errors." > > After completing the first 3 steps below: > > restapi-definition -> project -> properties -> java build path -> > source -> add source folder -> target/generated-sources/xjc ack. > webadmin -> project -> properties -> java build path -> source -> > add source folder-> > target/generated-sources/{annotations,gwt,test-annotations} Eclipse Juno did this automatically for me, but yes, if it wasn't added automatically, you should add it. > frontend -> project -> properties -> java build path -> source -> > add source folder-> target/generated-sources/gwt Same as above. > > I am left with 181 Errors. I then try the 4th step: > > frontend -> project -> properties -> Projects -> Add -> webadmin > > This introduces 5 errors stating, "A cycle was detected in the build > path of project > 'frontend'/'gwt-common'/'uicommonweb'/'userportal'/'webadmin'. The > cycle consists of projects {frontend, webadmin, uicommonweb, > gwt-common, userportal}" Indeed - this step seems wrong. I will remove it from the wiki page. > > I then try the 5th step: > > sharedgwt -> project -> properties -> Projects -> Add -> common > It was indeed removed - skip to the next stage regarding uicompat. Also, there are steps missing (I'll add them to the wiki): gwt-extensios - add anything under target/generated-sources gwt-common - add target/generated-sources/annotations; also add depdendency on uicommon-web, common and compat uicompat - add target/generated-sources/annotations generic-api - add dependencies on common, compat and utils > But there is no sharedgwt project. Does this provide enough detail? > > -----Original Message----- > From: engine-devel-bounces at ovirt.org > [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Yair Zaslavsky > Sent: Friday, July 27, 2012 1:13 AM > To: engine-devel at ovirt.org > Subject: Re: [Engine-devel] Building ovirt engine instructions > > On 07/27/2012 12:58 AM, Costea, George wrote: > > It works fine from the CLI (I was running out of memory). I'm > > still getting an issue with Eclipse though about a cycle being > > detected from the build path. > > Please elaborate on this cyclic dependency (I guess this is the > issue, > right?) > > What matters the most is that you can build from CLI. > Some of the oVirt engine mantainers do not build from Eclipse (I > personally find the maven plugin to be too buggy) , but it's a > matter of personal preference. We will try to help you regardlessly > > Yair > > > > > -----Original Message----- > > From: Oved Ourfalli [mailto:ovedo at redhat.com] > > Sent: Thursday, July 26, 2012 5:34 PM > > To: Costea, George > > Cc: engine-devel at ovirt.org > > Subject: Re: [Engine-devel] Building ovirt engine instructions > > > > > > > > ----- Original Message ----- > >> From: "George Costea" > >> To: engine-devel at ovirt.org > >> Sent: Thursday, July 26, 2012 11:33:04 PM > >> Subject: [Engine-devel] Building ovirt engine instructions > >> > >> > >> > >> > >> > >> I think the wiki page ( > >> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the > >> ovirt > >> engine is outdated. When I reach the deploy section, it always > >> fails. > >> Is there an update to get the ear file deployed? > >> > >> > > Can you elaborate more on the issue? What's the exact failure/error > > you see when deploying? > > > >> > >> The Eclipse instructions ( > >> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem > >> to > >> be out of date. When I follow the steps to change project > >> settings, I > >> get an error stating that ?A cycle was detected in the build path > >> of > >> the project...? Could we get an update on this too? > >> > >> > >> > >> Thanks, > >> > >> George > >> > >> > >> _______________________________________________ > >> 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 amureini at redhat.com Fri Jul 27 19:43:53 2012 From: amureini at redhat.com (Allon Mureinik) Date: Fri, 27 Jul 2012 15:43:53 -0400 (EDT) Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: <1257273193.4412562.1343412251134.JavaMail.root@redhat.com> Message-ID: <628167090.4440173.1343418233439.JavaMail.root@redhat.com> Also, if you're using Eclipse Juno, you want to take a look at this gerrit topic: http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:eclipse-juno-support,n,z I found out the hard way Juno is a tad over-strict when it comes to parsing poms, and this may save you some trouble ----- Original Message ----- > From: "Allon Mureinik" > To: "George Costea" > Cc: engine-devel at ovirt.org > Sent: Friday, July 27, 2012 9:04:11 PM > Subject: Re: [Engine-devel] Building ovirt engine instructions > > Just had to reinstall and reconfigure Eclipse myself due to a yum > upgrade misshap (kids, don't try this at home :-)), so here's some > insight on the process. > > ----- Original Message ----- > > From: "George Costea" > > To: "Yair Zaslavsky" , engine-devel at ovirt.org > > Sent: Friday, July 27, 2012 2:03:14 PM > > Subject: Re: [Engine-devel] Building ovirt engine instructions > > > > I get to the step that reads, "Change project settings to Resolve > > compilation errors." > > > > After completing the first 3 steps below: > > > > restapi-definition -> project -> properties -> java build path > > -> > > source -> add source folder -> target/generated-sources/xjc > ack. > > > webadmin -> project -> properties -> java build path -> source > > -> > > add source folder-> > > target/generated-sources/{annotations,gwt,test-annotations} > Eclipse Juno did this automatically for me, but yes, if it wasn't > added automatically, you should add it. > > > frontend -> project -> properties -> java build path -> source > > -> > > add source folder-> target/generated-sources/gwt > Same as above. > > > > > I am left with 181 Errors. I then try the 4th step: > > > > frontend -> project -> properties -> Projects -> Add -> webadmin > > > > This introduces 5 errors stating, "A cycle was detected in the > > build > > path of project > > 'frontend'/'gwt-common'/'uicommonweb'/'userportal'/'webadmin'. The > > cycle consists of projects {frontend, webadmin, uicommonweb, > > gwt-common, userportal}" > Indeed - this step seems wrong. I will remove it from the wiki page. > > > > > I then try the 5th step: > > > > sharedgwt -> project -> properties -> Projects -> Add -> common > > > It was indeed removed - skip to the next stage regarding uicompat. > > Also, there are steps missing (I'll add them to the wiki): > gwt-extensios - add anything under target/generated-sources > gwt-common - add target/generated-sources/annotations; also add > depdendency on uicommon-web, common and compat > uicompat - add target/generated-sources/annotations > generic-api - add dependencies on common, compat and utils > > > But there is no sharedgwt project. Does this provide enough > > detail? > > > > -----Original Message----- > > From: engine-devel-bounces at ovirt.org > > [mailto:engine-devel-bounces at ovirt.org] On Behalf Of Yair Zaslavsky > > Sent: Friday, July 27, 2012 1:13 AM > > To: engine-devel at ovirt.org > > Subject: Re: [Engine-devel] Building ovirt engine instructions > > > > On 07/27/2012 12:58 AM, Costea, George wrote: > > > It works fine from the CLI (I was running out of memory). I'm > > > still getting an issue with Eclipse though about a cycle being > > > detected from the build path. > > > > Please elaborate on this cyclic dependency (I guess this is the > > issue, > > right?) > > > > What matters the most is that you can build from CLI. > > Some of the oVirt engine mantainers do not build from Eclipse (I > > personally find the maven plugin to be too buggy) , but it's a > > matter of personal preference. We will try to help you regardlessly > > > > Yair > > > > > > > > -----Original Message----- > > > From: Oved Ourfalli [mailto:ovedo at redhat.com] > > > Sent: Thursday, July 26, 2012 5:34 PM > > > To: Costea, George > > > Cc: engine-devel at ovirt.org > > > Subject: Re: [Engine-devel] Building ovirt engine instructions > > > > > > > > > > > > ----- Original Message ----- > > >> From: "George Costea" > > >> To: engine-devel at ovirt.org > > >> Sent: Thursday, July 26, 2012 11:33:04 PM > > >> Subject: [Engine-devel] Building ovirt engine instructions > > >> > > >> > > >> > > >> > > >> > > >> I think the wiki page ( > > >> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the > > >> ovirt > > >> engine is outdated. When I reach the deploy section, it always > > >> fails. > > >> Is there an update to get the ear file deployed? > > >> > > >> > > > Can you elaborate more on the issue? What's the exact > > > failure/error > > > you see when deploying? > > > > > >> > > >> The Eclipse instructions ( > > >> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem > > >> to > > >> be out of date. When I follow the steps to change project > > >> settings, I > > >> get an error stating that ?A cycle was detected in the build > > >> path > > >> of > > >> the project...? Could we get an update on this too? > > >> > > >> > > >> > > >> Thanks, > > >> > > >> George > > >> > > >> > > >> _______________________________________________ > > >> 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 alonbl at redhat.com Sat Jul 28 00:31:04 2012 From: alonbl at redhat.com (Alon Bar-Lev) Date: Fri, 27 Jul 2012 20:31:04 -0400 (EDT) Subject: [Engine-devel] Adding VNC support In-Reply-To: <0E5BF7E2-EFCF-43A1-88B6-AB36399C2C3C@redhat.com> Message-ID: <1415180451.949087.1343435464853.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Michal Skrivanek" > To: "Alon Bar-Lev" > Cc: "Ewoud Kohl van Wijngaarden" , engine-devel at ovirt.org > Sent: Friday, July 27, 2012 12:01:32 PM > Subject: Re: [Engine-devel] Adding VNC support > > > On Jul 26, 2012, at 16:55 , Alon Bar-Lev wrote: > > > On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden > > wrote: > >> On Thu, Jul 26, 2012 at 07:36:43AM -0700, > >> snmishra at linux.vnet.ibm.com wrote: > >>> I am looking at adding VNC support in ovirt. What does the > >>> community > >>> think? Ideas, suggestions, comments? > >> By that I think you mean adding VNC support to the java-based web > >> interface. In that case +1. I can recommend noVNC[1], but you do > >> need a > >> websockets proxy. I can recommend VNCAuthProxy[2] as a > >> programmable > >> proxy with a JSON control channel. On the plus side all > >> dependencies are > >> in fedora/epel. Downside is no IPv6 support. Maybe you can also > >> write a > >> pure java implementation integrate this into the engine itself? > >> > >> [1]: http://kanaka.github.com/noVNC/ > >> [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/ > > > > Or launch client program via MIME bindings[1] both for Vnc and > > Spice. > > Not as neat as "noVnc" but will work in most scenarios, without > > having > > to maintain the actual console implementation. > I would think there are many people out there who are not able to use > current spice client, or not willing to(hate switching from chrome > to firefox:-) > Sure they can set up things manually but it would be way more > convenient to allow a simple external launch of their VNC client of > choice Right. Exactly what I think. In time the installation of the client can set up the MIME binding automatically. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=843410 > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel at ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > From iheim at redhat.com Sat Jul 28 04:36:17 2012 From: iheim at redhat.com (Itamar Heim) Date: Sat, 28 Jul 2012 07:36:17 +0300 Subject: [Engine-devel] Adding VNC support In-Reply-To: <1415180451.949087.1343435464853.JavaMail.root@redhat.com> References: <1415180451.949087.1343435464853.JavaMail.root@redhat.com> Message-ID: <50136C41.9030107@redhat.com> On 07/28/2012 03:31 AM, Alon Bar-Lev wrote: > > > ----- Original Message ----- >> From: "Michal Skrivanek" >> To: "Alon Bar-Lev" >> Cc: "Ewoud Kohl van Wijngaarden" , engine-devel at ovirt.org >> Sent: Friday, July 27, 2012 12:01:32 PM >> Subject: Re: [Engine-devel] Adding VNC support >> >> >> On Jul 26, 2012, at 16:55 , Alon Bar-Lev wrote: >> >>> On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden >>> wrote: >>>> On Thu, Jul 26, 2012 at 07:36:43AM -0700, >>>> snmishra at linux.vnet.ibm.com wrote: >>>>> I am looking at adding VNC support in ovirt. What does the >>>>> community >>>>> think? Ideas, suggestions, comments? >>>> By that I think you mean adding VNC support to the java-based web >>>> interface. In that case +1. I can recommend noVNC[1], but you do >>>> need a >>>> websockets proxy. I can recommend VNCAuthProxy[2] as a >>>> programmable >>>> proxy with a JSON control channel. On the plus side all >>>> dependencies are >>>> in fedora/epel. Downside is no IPv6 support. Maybe you can also >>>> write a >>>> pure java implementation integrate this into the engine itself? >>>> >>>> [1]: http://kanaka.github.com/noVNC/ >>>> [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/ >>> >>> Or launch client program via MIME bindings[1] both for Vnc and >>> Spice. >>> Not as neat as "noVnc" but will work in most scenarios, without >>> having >>> to maintain the actual console implementation. >> I would think there are many people out there who are not able to use >> current spice client, or not willing to(hate switching from chrome >> to firefox:-) >> Sure they can set up things manually but it would be way more >> convenient to allow a simple external launch of their VNC client of >> choice > > Right. > Exactly what I think. > In time the installation of the client can set up the MIME binding automatically. that means patching all the vnc clients iiuc, to set mime for multiple browser versions? From Ricky.Hopper at netapp.com Fri Jul 27 13:12:25 2012 From: Ricky.Hopper at netapp.com (Hopper, Ricky) Date: Fri, 27 Jul 2012 13:12:25 +0000 Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A480126D751@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: Through some experimentation, I found a list of steps that seems to fix everything on my machines: restapi-definition -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/xjc webadmin -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/{annotations,gwt} frontend -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/gwt gwt-common -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/annotations userportal -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/{annotations,gwt} These make sure there can't be any cycles introduced, and resolve all errors in the projects. Let me know if any of this doesn't work for you. - Ricky On 7/27/12 7:03 AM, "Costea, George" wrote: >I get to the step that reads, "Change project settings to Resolve >compilation errors." > >After completing the first 3 steps below: > > restapi-definition -> project -> properties -> java build path -> >source -> add source folder -> target/generated-sources/xjc > webadmin -> project -> properties -> java build path -> source -> >add source folder-> >target/generated-sources/{annotations,gwt,test-annotations} > frontend -> project -> properties -> java build path -> source -> >add source folder-> target/generated-sources/gwt > >I am left with 181 Errors. I then try the 4th step: > > frontend -> project -> properties -> Projects -> Add -> webadmin > >This introduces 5 errors stating, "A cycle was detected in the build path >of project 'frontend'/'gwt-common'/'uicommonweb'/'userportal'/'webadmin'. > The cycle consists of projects {frontend, webadmin, uicommonweb, >gwt-common, userportal}" > >I then try the 5th step: > > sharedgwt -> project -> properties -> Projects -> Add -> common > >But there is no sharedgwt project. Does this provide enough detail? > >-----Original Message----- >From: engine-devel-bounces at ovirt.org >[mailto:engine-devel-bounces at ovirt.org] On Behalf Of Yair Zaslavsky >Sent: Friday, July 27, 2012 1:13 AM >To: engine-devel at ovirt.org >Subject: Re: [Engine-devel] Building ovirt engine instructions > >On 07/27/2012 12:58 AM, Costea, George wrote: >> It works fine from the CLI (I was running out of memory). I'm still >>getting an issue with Eclipse though about a cycle being detected from >>the build path. > >Please elaborate on this cyclic dependency (I guess this is the issue, >right?) > >What matters the most is that you can build from CLI. >Some of the oVirt engine mantainers do not build from Eclipse (I >personally find the maven plugin to be too buggy) , but it's a matter of >personal preference. We will try to help you regardlessly > >Yair > >> >> -----Original Message----- >> From: Oved Ourfalli [mailto:ovedo at redhat.com] >> Sent: Thursday, July 26, 2012 5:34 PM >> To: Costea, George >> Cc: engine-devel at ovirt.org >> Subject: Re: [Engine-devel] Building ovirt engine instructions >> >> >> >> ----- Original Message ----- >>> From: "George Costea" >>> To: engine-devel at ovirt.org >>> Sent: Thursday, July 26, 2012 11:33:04 PM >>> Subject: [Engine-devel] Building ovirt engine instructions >>> >>> >>> >>> >>> >>> I think the wiki page ( >>> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the ovirt >>> engine is outdated. When I reach the deploy section, it always fails. >>> Is there an update to get the ear file deployed? >>> >>> >> Can you elaborate more on the issue? What's the exact failure/error you >>see when deploying? >> >>> >>> The Eclipse instructions ( >>> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem to >>> be out of date. When I follow the steps to change project settings, I >>> get an error stating that ?A cycle was detected in the build path of >>> the project...? Could we get an update on this too? >>> >>> >>> >>> Thanks, >>> >>> George >>> >>> >>> _______________________________________________ >>> 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 Ricky.Hopper at netapp.com Fri Jul 27 16:55:35 2012 From: Ricky.Hopper at netapp.com (Hopper, Ricky) Date: Fri, 27 Jul 2012 16:55:35 +0000 Subject: [Engine-devel] Building ovirt engine instructions In-Reply-To: <6C8AC8C50E170C4E9B44D47B39B24A480126D751@SACEXCMBX04-PRD.hq.netapp.com> Message-ID: Through some experimentation, I found a list of steps that seems to fix everything on my machines: restapi-definition -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/xjc webadmin -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/{annotations,gwt} frontend -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/gwt gwt-common -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/annotations userportal -> project -> properties -> java build path -> source -> add source folder -> target/generated-sources/{annotations,gwt} These make sure there can't be any cycles introduced, and resolve all errors in the projects. Let me know if any of this doesn't work for you. - Ricky On 7/27/12 7:03 AM, "Costea, George" wrote: >I get to the step that reads, "Change project settings to Resolve >compilation errors." > >After completing the first 3 steps below: > > restapi-definition -> project -> properties -> java build path -> >source -> add source folder -> target/generated-sources/xjc > webadmin -> project -> properties -> java build path -> source -> >add source folder-> >target/generated-sources/{annotations,gwt,test-annotations} > frontend -> project -> properties -> java build path -> source -> >add source folder-> target/generated-sources/gwt > >I am left with 181 Errors. I then try the 4th step: > > frontend -> project -> properties -> Projects -> Add -> webadmin > >This introduces 5 errors stating, "A cycle was detected in the build path >of project 'frontend'/'gwt-common'/'uicommonweb'/'userportal'/'webadmin'. > The cycle consists of projects {frontend, webadmin, uicommonweb, >gwt-common, userportal}" > >I then try the 5th step: > > sharedgwt -> project -> properties -> Projects -> Add -> common > >But there is no sharedgwt project. Does this provide enough detail? > >-----Original Message----- >From: engine-devel-bounces at ovirt.org >[mailto:engine-devel-bounces at ovirt.org] On Behalf Of Yair Zaslavsky >Sent: Friday, July 27, 2012 1:13 AM >To: engine-devel at ovirt.org >Subject: Re: [Engine-devel] Building ovirt engine instructions > >On 07/27/2012 12:58 AM, Costea, George wrote: >> It works fine from the CLI (I was running out of memory). I'm still >>getting an issue with Eclipse though about a cycle being detected from >>the build path. > >Please elaborate on this cyclic dependency (I guess this is the issue, >right?) > >What matters the most is that you can build from CLI. >Some of the oVirt engine mantainers do not build from Eclipse (I >personally find the maven plugin to be too buggy) , but it's a matter of >personal preference. We will try to help you regardlessly > >Yair > >> >> -----Original Message----- >> From: Oved Ourfalli [mailto:ovedo at redhat.com] >> Sent: Thursday, July 26, 2012 5:34 PM >> To: Costea, George >> Cc: engine-devel at ovirt.org >> Subject: Re: [Engine-devel] Building ovirt engine instructions >> >> >> >> ----- Original Message ----- >>> From: "George Costea" >>> To: engine-devel at ovirt.org >>> Sent: Thursday, July 26, 2012 11:33:04 PM >>> Subject: [Engine-devel] Building ovirt engine instructions >>> >>> >>> >>> >>> >>> I think the wiki page ( >>> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the ovirt >>> engine is outdated. When I reach the deploy section, it always fails. >>> Is there an update to get the ear file deployed? >>> >>> >> Can you elaborate more on the issue? What's the exact failure/error you >>see when deploying? >> >>> >>> The Eclipse instructions ( >>> http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem to >>> be out of date. When I follow the steps to change project settings, I >>> get an error stating that ?A cycle was detected in the build path of >>> the project...? Could we get an update on this too? >>> >>> >>> >>> Thanks, >>> >>> George >>> >>> >>> _______________________________________________ >>> 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 alonbl at redhat.com Sat Jul 28 08:15:01 2012 From: alonbl at redhat.com (Alon Bar-Lev) Date: Sat, 28 Jul 2012 04:15:01 -0400 (EDT) Subject: [Engine-devel] Adding VNC support In-Reply-To: <50136C41.9030107@redhat.com> Message-ID: <61311332.955390.1343463301348.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "Michal Skrivanek" , engine-devel at ovirt.org > Sent: Saturday, July 28, 2012 7:36:17 AM > Subject: Re: [Engine-devel] Adding VNC support > > On 07/28/2012 03:31 AM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > >> From: "Michal Skrivanek" > >> To: "Alon Bar-Lev" > >> Cc: "Ewoud Kohl van Wijngaarden" > >> , engine-devel at ovirt.org > >> Sent: Friday, July 27, 2012 12:01:32 PM > >> Subject: Re: [Engine-devel] Adding VNC support > >> > >> > >> On Jul 26, 2012, at 16:55 , Alon Bar-Lev wrote: > >> > >>> On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden > >>> wrote: > >>>> On Thu, Jul 26, 2012 at 07:36:43AM -0700, > >>>> snmishra at linux.vnet.ibm.com wrote: > >>>>> I am looking at adding VNC support in ovirt. What does the > >>>>> community > >>>>> think? Ideas, suggestions, comments? > >>>> By that I think you mean adding VNC support to the java-based > >>>> web > >>>> interface. In that case +1. I can recommend noVNC[1], but you do > >>>> need a > >>>> websockets proxy. I can recommend VNCAuthProxy[2] as a > >>>> programmable > >>>> proxy with a JSON control channel. On the plus side all > >>>> dependencies are > >>>> in fedora/epel. Downside is no IPv6 support. Maybe you can also > >>>> write a > >>>> pure java implementation integrate this into the engine itself? > >>>> > >>>> [1]: http://kanaka.github.com/noVNC/ > >>>> [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/ > >>> > >>> Or launch client program via MIME bindings[1] both for Vnc and > >>> Spice. > >>> Not as neat as "noVnc" but will work in most scenarios, without > >>> having > >>> to maintain the actual console implementation. > >> I would think there are many people out there who are not able to > >> use > >> current spice client, or not willing to(hate switching from chrome > >> to firefox:-) > >> Sure they can set up things manually but it would be way more > >> convenient to allow a simple external launch of their VNC client > >> of > >> choice > > > > Right. > > Exactly what I think. > > In time the installation of the client can set up the MIME binding > > automatically. > > that means patching all the vnc clients iiuc, to set mime for > multiple > browser versions? > At first we provide support at the engine side, and user get it manually: User will get a dialog: "(o) Open File" "( ) Download" When selecting "Open File" he will need to choose a program. Initially we will provide programs (scripts) for both vnc and spice. Then after user are satisfied we offer these programs to the appropriate upstream. Best case: will be accepted (maybe with modifications). Worse case: will be rejected so we provide engine-console package to our users with these programs. Regards, Alon. From amureini at redhat.com Sun Jul 29 11:49:04 2012 From: amureini at redhat.com (Allon Mureinik) Date: Sun, 29 Jul 2012 07:49:04 -0400 (EDT) Subject: [Engine-devel] Conformining to Java 6 using Animal Sniffer In-Reply-To: <841568069.4716199.1343562494628.JavaMail.root@redhat.com> Message-ID: <23296591.4716209.1343562544642.JavaMail.root@redhat.com> Hi guys, As you may recall, a couple of weeks ago it was decided (in this mailing list), that we want to preserve backwards compatibility to Java 6. Instead of having to install JDK 6 alongside your Java 7, you can now use Animal Sniffer[1] to verify this. Simply run "mvn animal-sniffer:check" before you push, and assuming the build is successful, you're good to go. Note: Animal Sniffer takes about a minute to run, so it was NOT added by default to the "install" target. It is still your responsibility to verify backwards compatibility of you code, this is just a convenient way of doing it. Many thanks to Juan and Doron for their insights and reviews for this patch. -Allon [1] http://mojo.codehaus.org/animal-sniffer-maven-plugin/ From rgolan at redhat.com Sun Jul 29 16:11:23 2012 From: rgolan at redhat.com (Roy Golan) Date: Sun, 29 Jul 2012 19:11:23 +0300 Subject: [Engine-devel] Confusing "Attach Disk" checkbox in Add Virtual Disk dialog Message-ID: <501560AB.7060505@redhat.com> Hi all, I find the new "Attach Disk" checkbox very confusing. It doesn't feel like a feature of the dialog but some kind of a disk property laid in the wrong place. I'd expect toggling between two ways of adding disk using tabs or inner menu. even simple inner " add | attach " feels more friendly. Is that an early sketch waiting to be changed? - Roy From ovedo at redhat.com Mon Jul 30 08:16:57 2012 From: ovedo at redhat.com (Oved Ourfalli) Date: Mon, 30 Jul 2012 04:16:57 -0400 (EDT) Subject: [Engine-devel] Confusing "Attach Disk" checkbox in Add Virtual Disk dialog In-Reply-To: <501560AB.7060505@redhat.com> Message-ID: <476860732.5464650.1343636217733.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Roy Golan" > To: engine-devel at ovirt.org > Sent: Sunday, July 29, 2012 7:11:23 PM > Subject: [Engine-devel] Confusing "Attach Disk" checkbox in Add Virtual Disk dialog > > Hi all, > > I find the new "Attach Disk" checkbox very confusing. It doesn't feel > like a feature of the dialog but some kind of a disk property laid in > the wrong place. > Totally agree it is confusing, and that it seems misplaced. There is a radio button in this dialog, for internal/external disk. I'd add another one for attach disk. Thinking of it, (Roy - perhaps I'm saying what you said, but in my own words), it would be nice if the dialog has three different tabs (instead of radio buttons) for these options (add internal disk/add external disk/attach existing disk). > I'd expect toggling between two ways of adding disk using tabs or > inner > menu. even simple inner " add | attach " feels more friendly. > > Is that an early sketch waiting to be changed? > > - Roy > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From vszocs at redhat.com Mon Jul 30 11:31:48 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 30 Jul 2012 07:31:48 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins Meeting Message-ID: <600489402.18225896.1343647908905.JavaMail.root@redhat.com> The following is a new meeting request: Subject: oVirt UI Plugins Meeting Organizer: "Vojtech Szocs" Time: Tuesday, July 31, 2012, 4:30:00 PM - 5:30:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague Invitees: engine-devel at ovirt.org *~*~*~*~*~*~*~*~*~* Hi guys, let me invite you to a meeting for discussing oVirt UI Plugins feature. Topics covered in this meeting: * UI Plugins proof-of-concept (PoC): how it works and what are its implications * Discuss two ways to build plugins, comparing their pros and cons * Decide on next steps for initial UI Plugins implementation Here are the details required for joining the session. Intercall dial-in numbers can be found at: https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7128867405 Intercall Conference Code ID: 7128867405 # Regards, Vojtech -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 4069 bytes Desc: not available URL: From vszocs at redhat.com Mon Jul 30 12:02:39 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 30 Jul 2012 08:02:39 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins Meeting Message-ID: <1532776984.18312112.1343649759701.JavaMail.root@redhat.com> The following meeting has been modified: Subject: oVirt UI Plugins Meeting Organizer: "Vojtech Szocs" Time: Tuesday, July 31, 2012, 4:30:00 PM - 5:30:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague Invitees: engine-devel at ovirt.org; George.Costea at netapp.com; Troy.Mangum at netapp.com; Dustin.Schoenbrun at netapp.com; Ricky.Hopper at netapp.com; Chris.Frantz at hp.com *~*~*~*~*~*~*~*~*~* Hi guys, let me invite you to a meeting for discussing oVirt UI Plugins feature. Topics covered in this meeting: * UI Plugins proof-of-concept (PoC): how it works and what are its implications * Discuss two ways to build plugins, comparing their pros and cons * Decide on next steps for initial UI Plugins implementation Here are the details required for joining the session. Intercall dial-in numbers can be found at: https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7128867405 Intercall Conference Code ID: 7128867405 # Elluminate session: https://sas.elluminate.com/m.jnlp?sid=819&password=M.9C6593A28029B5159D5DD78B361387 Regards, Vojtech -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 5798 bytes Desc: not available URL: From vszocs at redhat.com Mon Jul 30 12:03:41 2012 From: vszocs at redhat.com (Vojtech Szocs) Date: Mon, 30 Jul 2012 08:03:41 -0400 (EDT) Subject: [Engine-devel] oVirt UI Plugins Meeting Message-ID: <1028969042.18316530.1343649821267.JavaMail.root@redhat.com> The following meeting has been modified: Subject: oVirt UI Plugins Meeting Organizer: "Vojtech Szocs" Time: Tuesday, July 31, 2012, 4:30:00 PM - 5:30:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague Invitees: engine-devel at ovirt.org; George.Costea at netapp.com; Troy.Mangum at netapp.com; Dustin.Schoenbrun at netapp.com; Ricky.Hopper at netapp.com; Chris.Frantz at hp.com *~*~*~*~*~*~*~*~*~* Hi guys, let me invite you to a meeting for discussing oVirt UI Plugins feature. Topics covered in this meeting: * UI Plugins proof-of-concept (PoC): how it works and what are its implications * Discuss two ways to build plugins, comparing their pros and cons * Decide on next steps for initial UI Plugins implementation Here are the details required for joining the session. Intercall dial-in numbers can be found at: https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7128867405 Intercall Conference Code ID: 7128867405 # Elluminate session: https://sas.elluminate.com/m.jnlp?sid=819&password=M.9C6593A28029B5159D5DD78B361387 Regards, Vojtech -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 5909 bytes Desc: not available URL: From iheim at redhat.com Tue Jul 31 06:18:50 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 31 Jul 2012 09:18:50 +0300 Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> Message-ID: <501778CA.40105@redhat.com> On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: > > Hi, > > I am looking at adding VNC support in ovirt. What does the community > think? Ideas, suggestions, comments? so to sum this up: 1. there is the new dialog to open vnc manually. http://gerrit.ovirt.org/#/c/4790/ 2. Alon suggested it should be allowed to open this dialog for spice as well, not only for vnc. 3. Alon also suggested to have a launch button on that window (or parallel to it) which will try to launch vnc or spice by returning a specific mime type response, allowing client to choose the vnc/spice client to run for this mime type, and passing command line parameters to it in the mime type reply. 4. provide a vnc xpi/activex wrappers to allow launching it via web browsers like spice main limitation of this compared to novnc is you need to do this for every browser/platform. 5. novnc 5.1 novnc client - i'd start with the one recently pushed to fedora. https://bugzilla.redhat.com/show_bug.cgi?id=822187 5.2 novnc websocket server - i see three options 5.2.1 extend qemu to do this, so novnc can connect to it directly like we do today for vnc/spice 5.2.2 use the python based one from: https://bugzilla.redhat.com/show_bug.cgi?id=822187 5.2.3 look at a java based websocket solution, assuming easier to deploy it as part of webadmin/user portal war than another service (requires a bit of research) looking forward user portal and webadmin would be deployed on multiple hosts, so a websockets would need to be deployed next to them. from the little i looked at, the various websocket implementations are mostly nascent and are not scaleable/robust/etc. I'd love to be proven wrong, and worth playing with them a bit to measure that. 6. spice.html5 while very nascent - worth mentioning on this thread and trying to take a look: http://www.spice-space.org/page/Html5 From yzaslavs at redhat.com Tue Jul 31 07:58:37 2012 From: yzaslavs at redhat.com (Yair Zaslavsky) Date: Tue, 31 Jul 2012 10:58:37 +0300 Subject: [Engine-devel] Reminder - common Message-ID: <5017902D.2030204@redhat.com> Hi, Please do not insert projects to pom.xml which do not compile by both engine core and gwt. Thanks, Yair From michal.skrivanek at redhat.com Tue Jul 31 08:11:27 2012 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Tue, 31 Jul 2012 10:11:27 +0200 Subject: [Engine-devel] Confusing "Attach Disk" checkbox in Add Virtual Disk dialog In-Reply-To: <476860732.5464650.1343636217733.JavaMail.root@redhat.com> References: <476860732.5464650.1343636217733.JavaMail.root@redhat.com> Message-ID: On Jul 30, 2012, at 10:16 , Oved Ourfalli wrote: > > > ----- Original Message ----- >> From: "Roy Golan" >> To: engine-devel at ovirt.org >> Sent: Sunday, July 29, 2012 7:11:23 PM >> Subject: [Engine-devel] Confusing "Attach Disk" checkbox in Add Virtual Disk dialog >> >> Hi all, >> >> I find the new "Attach Disk" checkbox very confusing. It doesn't feel >> like a feature of the dialog but some kind of a disk property laid in >> the wrong place. >> > Totally agree it is confusing, and that it seems misplaced. > There is a radio button in this dialog, for internal/external disk. > I'd add another one for attach disk. > Thinking of it, (Roy - perhaps I'm saying what you said, but in my own words), it would be nice if the dialog has three different tabs (instead of radio buttons) for these options (add internal disk/add external disk/attach existing disk). +1 did you create bz already?:) > > >> I'd expect toggling between two ways of adding disk using tabs or >> inner >> menu. even simple inner " add | attach " feels more friendly. >> >> Is that an early sketch waiting to be changed? >> >> - Roy >> >> _______________________________________________ >> 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 Tue Jul 31 08:43:59 2012 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Tue, 31 Jul 2012 10:43:59 +0200 Subject: [Engine-devel] Adding VNC support In-Reply-To: <501778CA.40105@redhat.com> References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> <501778CA.40105@redhat.com> Message-ID: I've already expressed my inclination, but?:-) On Jul 31, 2012, at 08:18 , Itamar Heim wrote: > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: >> >> Hi, >> >> I am looking at adding VNC support in ovirt. What does the community >> think? Ideas, suggestions, comments? > > so to sum this up: > 1. there is the new dialog to open vnc manually. > http://gerrit.ovirt.org/#/c/4790/ helps, but not really that friendly. In fact it sort of suggests we are not able to achieve a simple task of running an external app:) > 2. Alon suggested it should be allowed to open this dialog for spice as well, not only for vnc. > > 3. Alon also suggested to have a launch button on that window (or parallel to it) which will try to launch vnc or spice by returning a specific mime type response, allowing client to choose the vnc/spice client to run for this mime type, and passing command line parameters to it in the mime type reply. I think this is reasonable result for little effort. It would allow to seamlessly open the connection for all other platforms we do not support today, Mac, iOS, it's quite easy to get a VNC on almost any platform as opposed to limited spiceclient support. > 4. provide a vnc xpi/activex wrappers to allow launching it via web browsers like spice > main limitation of this compared to novnc is you need to do this for every browser/platform. more effort than #3, too many browsers out there, and you have to install a plugin > > 5. novnc > 5.1 novnc client - i'd start with the one recently pushed to fedora. > https://bugzilla.redhat.com/show_bug.cgi?id=822187 > > 5.2 novnc websocket server - i see three options > > 5.2.1 extend qemu to do this, so novnc can connect to it directly like we do today for vnc/spice > > 5.2.2 use the python based one from: > https://bugzilla.redhat.com/show_bug.cgi?id=822187 > > 5.2.3 look at a java based websocket solution, assuming easier to deploy it as part of webadmin/user portal war than another service (requires a bit of research) > looking forward user portal and webadmin would be deployed on multiple hosts, so a websockets would need to be deployed next to them. > > from the little i looked at, the various websocket implementations are mostly nascent and are not scaleable/robust/etc. > I'd love to be proven wrong, and worth playing with them a bit to measure that. and novnc client is still far less common than vnc. Having it in Fedora doesn't help much. > > 6. spice.html5 > while very nascent - worth mentioning on this thread and trying to take a look: > http://www.spice-space.org/page/Html5 more effort than #3, browser support questionable. I'd have doubts about performance on mobile devices even in the future > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From berrange at redhat.com Tue Jul 31 09:09:26 2012 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 31 Jul 2012 10:09:26 +0100 Subject: [Engine-devel] Adding VNC support In-Reply-To: <501778CA.40105@redhat.com> References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> <501778CA.40105@redhat.com> Message-ID: <20120731090926.GB2475@redhat.com> On Tue, Jul 31, 2012 at 09:18:50AM +0300, Itamar Heim wrote: > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: > > > >Hi, > > > > I am looking at adding VNC support in ovirt. What does the community > >think? Ideas, suggestions, comments? > > so to sum this up: > 1. there is the new dialog to open vnc manually. > http://gerrit.ovirt.org/#/c/4790/ > > 2. Alon suggested it should be allowed to open this dialog for spice > as well, not only for vnc. > > 3. Alon also suggested to have a launch button on that window (or > parallel to it) which will try to launch vnc or spice by returning a > specific mime type response, allowing client to choose the vnc/spice > client to run for this mime type, and passing command line > parameters to it in the mime type reply. > > 4. provide a vnc xpi/activex wrappers to allow launching it via web > browsers like spice > main limitation of this compared to novnc is you need to do this for > every browser/platform. > > 5. novnc > 5.1 novnc client - i'd start with the one recently pushed to fedora. > https://bugzilla.redhat.com/show_bug.cgi?id=822187 > > 5.2 novnc websocket server - i see three options > > 5.2.1 extend qemu to do this, so novnc can connect to it directly > like we do today for vnc/spice I don't think this is a desirable approach. One of the nice benefits you gain from using a websocket proxy is that you only need to have one single TCP port exposed to the internet now. If you put websockets in QEMU itself, you'd be stuck with having to open your firewall to allow 100's of ports. With a separate web proxy, you can even make each QEMU server now use a local UNIX socket for their VNC server, since only the proxy needs to be able to connect. This means that the VNC server would no longer be exposed to random local user access too. > 5.2.2 use the python based one from: > https://bugzilla.redhat.com/show_bug.cgi?id=822187 FWIW, this is what OpenStack Nova uses for its VNC proxy. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From ykaul at redhat.com Tue Jul 31 09:31:20 2012 From: ykaul at redhat.com (Yaniv Kaul) Date: Tue, 31 Jul 2012 12:31:20 +0300 Subject: [Engine-devel] Remove the 'bootable' flag for disks Message-ID: <5017A5E8.1020805@redhat.com> I fail to see its value. What purpose does it serve? The only 'useful' place is in the run once the boot order - as we only define as the boot sequence 'Hard Disk' without mentioning which disk. We can clearly replace 'Hard Disk' with the list of all disks (and let the guest decide) and deprecate that flag ASAP, or we can have the list of disks in that list (and deprecate that flag). Y. From masayag at redhat.com Tue Jul 31 11:33:20 2012 From: masayag at redhat.com (Moti Asayag) Date: Tue, 31 Jul 2012 14:33:20 +0300 Subject: [Engine-devel] New ovirt-engine commit requires updated VDSM Message-ID: <5017C280.40501@redhat.com> Hi, Due to network related API changes between the enging and VDSM, cluster 3.1 host agents should be updated: Starting from ovirt-engine commit ec5f528e80ac8e7b2d8bb4f65eb46391233fd1fd, VDSM must include commit 1fa30a08b93c5ba76c8f5377d030d8a597023d18. The expected behaviour without an updated VDSM, is having all 3.1 hosts as non-operational due to missing networks. Regards, Moti From acathrow at redhat.com Tue Jul 31 12:49:32 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Tue, 31 Jul 2012 08:49:32 -0400 (EDT) Subject: [Engine-devel] Adding VNC support In-Reply-To: <501778CA.40105@redhat.com> Message-ID: <1878263144.1196071.1343738972966.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: snmishra at linux.vnet.ibm.com > Cc: engine-devel at ovirt.org > Sent: Tuesday, July 31, 2012 2:18:50 AM > Subject: Re: [Engine-devel] Adding VNC support > > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: > > > > Hi, > > > > I am looking at adding VNC support in ovirt. What does the > > community > > think? Ideas, suggestions, comments? > > so to sum this up: > 1. there is the new dialog to open vnc manually. > http://gerrit.ovirt.org/#/c/4790/ > > 2. Alon suggested it should be allowed to open this dialog for spice > as > well, not only for vnc. > > 3. Alon also suggested to have a launch button on that window (or > parallel to it) which will try to launch vnc or spice by returning a > specific mime type response, allowing client to choose the vnc/spice > client to run for this mime type, and passing command line parameters > to > it in the mime type reply. > > 4. provide a vnc xpi/activex wrappers to allow launching it via web > browsers like spice > main limitation of this compared to novnc is you need to do this for > every browser/platform. > > 5. novnc > 5.1 novnc client - i'd start with the one recently pushed to fedora. > https://bugzilla.redhat.com/show_bug.cgi?id=822187 > > 5.2 novnc websocket server - i see three options > > 5.2.1 extend qemu to do this, so novnc can connect to it directly > like > we do today for vnc/spice One of the requirements we want to eliminate is the need for clients to connect directly to the hypervisor. I think the novnc server should be externally hosted not part of qemu > > 5.2.2 use the python based one from: > https://bugzilla.redhat.com/show_bug.cgi?id=822187 +1 > > 5.2.3 look at a java based websocket solution, assuming easier to > deploy > it as part of webadmin/user portal war than another service (requires > a > bit of research) > looking forward user portal and webadmin would be deployed on > multiple > hosts, so a websockets would need to be deployed next to them. > > from the little i looked at, the various websocket implementations > are > mostly nascent and are not scaleable/robust/etc. > I'd love to be proven wrong, and worth playing with them a bit to > measure that. > > 6. spice.html5 > while very nascent - worth mentioning on this thread and trying to > take > a look: > http://www.spice-space.org/page/Html5 > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From oschreib at redhat.com Tue Jul 31 12:53:42 2012 From: oschreib at redhat.com (Ofer Schreiber) Date: Tue, 31 Jul 2012 08:53:42 -0400 (EDT) Subject: [Engine-devel] Remove the 'bootable' flag for disks In-Reply-To: <5017A5E8.1020805@redhat.com> Message-ID: <1148569818.2594123.1343739222084.JavaMail.root@redhat.com> ----- Original Message ----- > I fail to see its value. What purpose does it serve? > The only 'useful' place is in the run once the boot order - as we > only > define as the boot sequence 'Hard Disk' without mentioning which > disk. > We can clearly replace 'Hard Disk' with the list of all disks (and > let > the guest decide) and deprecate that flag ASAP, or we can have the > list > of disks in that list (and deprecate that flag). > Y. +1 > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From bos at je-eigen-domein.nl Tue Jul 31 12:57:00 2012 From: bos at je-eigen-domein.nl (Floris Bos / Maxnet) Date: Tue, 31 Jul 2012 14:57:00 +0200 Subject: [Engine-devel] Adding VNC support In-Reply-To: <501778CA.40105@redhat.com> References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> <501778CA.40105@redhat.com> Message-ID: <5017D61C.1080001@je-eigen-domein.nl> Hi, On 07/31/2012 08:18 AM, Itamar Heim wrote: > 5.2 novnc websocket server - i see three options > > 5.2.1 extend qemu to do this, so novnc can connect to it directly like > we do today for vnc/spice > > 5.2.2 use the python based one from: > https://bugzilla.redhat.com/show_bug.cgi?id=822187 > > 5.2.3 look at a java based websocket solution, assuming easier to > deploy it as part of webadmin/user portal war than another service > (requires a bit of research) > looking forward user portal and webadmin would be deployed on multiple > hosts, so a websockets would need to be deployed next to them. > > from the little i looked at, the various websocket implementations are > mostly nascent and are not scaleable/robust/etc. > I'd love to be proven wrong, and worth playing with them a bit to > measure that. For a commercial management product we used the following BSD licensed websocket proxy written in C as a base: https://github.com/kumina/wsproxy Need to use it in combination with stunnel to get SSL. Did modify it a bit. E.g. in our software we do not use URLs in the form of ws://host:41337/1234 but wss://host:41337/249c345e-db0c-11e1-8013-2ce7130dcd93 where the uuid serves as a session id for authentication. Works ok. One thing I did notice is that you must use a proper SSL certificate issued by a CA for the proxy, even during testing. Browsers tend to fail the websockets connection instead of offering a dialog to override if that is not the case. Yours sincerely, Floris Bos From ewoud+ovirt at kohlvanwijngaarden.nl Tue Jul 31 10:00:43 2012 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Tue, 31 Jul 2012 12:00:43 +0200 Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120731090926.GB2475@redhat.com> References: <20120726073643.Horde.XbhN_Jir309QEVX7YpIizCA@imap.linux.ibm.com> <501778CA.40105@redhat.com> <20120731090926.GB2475@redhat.com> Message-ID: <20120731100043.GA4725@bogey.xentower.nl> On Tue, Jul 31, 2012 at 10:09:26AM +0100, Daniel P. Berrange wrote: > On Tue, Jul 31, 2012 at 09:18:50AM +0300, Itamar Heim wrote: > > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: > > 5.2 novnc websocket server - i see three options > > > > 5.2.1 extend qemu to do this, so novnc can connect to it directly > > like we do today for vnc/spice > > I don't think this is a desirable approach. One of the nice benefits > you gain from using a websocket proxy is that you only need to have > one single TCP port exposed to the internet now. If you put websockets > in QEMU itself, you'd be stuck with having to open your firewall to > allow 100's of ports. With a separate web proxy, you can even make > each QEMU server now use a local UNIX socket for their VNC server, > since only the proxy needs to be able to connect. This means that > the VNC server would no longer be exposed to random local user > access too. Another benefit of a proxy is that you can run it in a DMZ and not have to expose all your virtualization hosts to the internet. From ewoud+ovirt at kohlvanwijngaarden.nl Tue Jul 31 10:04:59 2012 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Tue, 31 Jul 2012 12:04:59 +0200 Subject: [Engine-devel] Remove the 'bootable' flag for disks In-Reply-To: <5017A5E8.1020805@redhat.com> References: <5017A5E8.1020805@redhat.com> Message-ID: <20120731100459.GB4725@bogey.xentower.nl> On Tue, Jul 31, 2012 at 12:31:20PM +0300, Yaniv Kaul wrote: > I fail to see its value. What purpose does it serve? > The only 'useful' place is in the run once the boot order - as we > only define as the boot sequence 'Hard Disk' without mentioning > which disk. > We can clearly replace 'Hard Disk' with the list of all disks (and > let the guest decide) and deprecate that flag ASAP, or we can have > the list of disks in that list (and deprecate that flag). +1. It's the wrong way of modeling the boot relation which makes user interfaces very confusing. You can see this in places like foreman which has to show a help text explaining it. From michal.skrivanek at redhat.com Tue Jul 31 13:22:32 2012 From: michal.skrivanek at redhat.com (Michal Skrivanek) Date: Tue, 31 Jul 2012 15:22:32 +0200 Subject: [Engine-devel] Remove the 'bootable' flag for disks In-Reply-To: <1148569818.2594123.1343739222084.JavaMail.root@redhat.com> References: <1148569818.2594123.1343739222084.JavaMail.root@redhat.com> Message-ID: On Jul 31, 2012, at 14:53 , Ofer Schreiber wrote: > > > ----- Original Message ----- >> I fail to see its value. What purpose does it serve? >> The only 'useful' place is in the run once the boot order - as we >> only >> define as the boot sequence 'Hard Disk' without mentioning which >> disk. >> We can clearly replace 'Hard Disk' with the list of all disks (and >> let >> the guest decide) and deprecate that flag ASAP, or we can have the >> list >> of disks in that list (and deprecate that flag). >> Y. > > +1 anyone writing an RFE for that? Definitely a good idea unless there are good reasons for the current state? > >> _______________________________________________ >> 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 Tue Jul 31 13:44:10 2012 From: alonbl at redhat.com (Alon Bar-Lev) Date: Tue, 31 Jul 2012 09:44:10 -0400 (EDT) Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120731100043.GA4725@bogey.xentower.nl> Message-ID: <1636398506.1290873.1343742250166.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ewoud Kohl van Wijngaarden" > To: engine-devel at ovirt.org > Sent: Tuesday, July 31, 2012 1:00:43 PM > Subject: Re: [Engine-devel] Adding VNC support > > On Tue, Jul 31, 2012 at 10:09:26AM +0100, Daniel P. Berrange wrote: > > On Tue, Jul 31, 2012 at 09:18:50AM +0300, Itamar Heim wrote: > > > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: > > > 5.2 novnc websocket server - i see three options > > > > > > 5.2.1 extend qemu to do this, so novnc can connect to it directly > > > like we do today for vnc/spice > > > > I don't think this is a desirable approach. One of the nice > > benefits > > you gain from using a websocket proxy is that you only need to have > > one single TCP port exposed to the internet now. If you put > > websockets > > in QEMU itself, you'd be stuck with having to open your firewall to > > allow 100's of ports. With a separate web proxy, you can even make > > each QEMU server now use a local UNIX socket for their VNC server, > > since only the proxy needs to be able to connect. This means that > > the VNC server would no longer be exposed to random local user > > access too. > > Another benefit of a proxy is that you can run it in a DMZ and not > have > to expose all your virtualization hosts to the internet. But this way you do expose them :) Alon. From ewoud+ovirt at kohlvanwijngaarden.nl Tue Jul 31 15:25:53 2012 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Tue, 31 Jul 2012 17:25:53 +0200 Subject: [Engine-devel] Adding VNC support In-Reply-To: <1636398506.1290873.1343742250166.JavaMail.root@redhat.com> References: <20120731100043.GA4725@bogey.xentower.nl> <1636398506.1290873.1343742250166.JavaMail.root@redhat.com> Message-ID: <20120731152553.GC4725@bogey.xentower.nl> On Tue, Jul 31, 2012 at 09:44:10AM -0400, Alon Bar-Lev wrote: > Ewoud Kohl van Wijngaarden wrote: > > On Tue, Jul 31, 2012 at 10:09:26AM +0100, Daniel P. Berrange wrote: > > > On Tue, Jul 31, 2012 at 09:18:50AM +0300, Itamar Heim wrote: > > > > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: > > > > 5.2 novnc websocket server - i see three options > > > > > > > > 5.2.1 extend qemu to do this, so novnc can connect to it directly > > > > like we do today for vnc/spice > > > > > > I don't think this is a desirable approach. One of the nice > > > benefits > > > you gain from using a websocket proxy is that you only need to have > > > one single TCP port exposed to the internet now. If you put > > > websockets > > > in QEMU itself, you'd be stuck with having to open your firewall to > > > allow 100's of ports. With a separate web proxy, you can even make > > > each QEMU server now use a local UNIX socket for their VNC server, > > > since only the proxy needs to be able to connect. This means that > > > the VNC server would no longer be exposed to random local user > > > access too. > > > > Another benefit of a proxy is that you can run it in a DMZ and not > > have > > to expose all your virtualization hosts to the internet. > > But this way you do expose them :) Since I've worked with VNCAuthProxy I'll explain how that works. First of all it listens on a control port. This can be inside the firewall and has a simple JSON-based protocol. On this control port you can ask it to open a connection on port X to virt-host.example.org:Y. virt-host.example.org can also be behind the firewall and now only port X is exposed to the internet. From iheim at redhat.com Tue Jul 31 15:39:36 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 31 Jul 2012 18:39:36 +0300 Subject: [Engine-devel] oVirt UI Plugins Meeting In-Reply-To: <1028969042.18316530.1343649821267.JavaMail.root@redhat.com> References: <1028969042.18316530.1343649821267.JavaMail.root@redhat.com> Message-ID: <5017FC38.4060601@redhat.com> my notes from the call: vojtech will schedule a follow up for two weeks from now same time. next step is to provide simple sample java script based plugins in the following order: 1. add a main tab showing html page from external url 2. add a sub tab showing html page from external url 3. add a context menu item opening an external url 4. plugin performs a REST API call to the engine 5. cross origin header - plugin asking another server/url a question if anyone wants to pick on of those up rather than wait for vojtech on them - would be great. Thanks, Itamar On 07/30/2012 03:03 PM, Vojtech Szocs wrote: From amureini at redhat.com Tue Jul 31 19:12:39 2012 From: amureini at redhat.com (Allon Mureinik) Date: Tue, 31 Jul 2012 15:12:39 -0400 (EDT) Subject: [Engine-devel] Reminder - common In-Reply-To: <5017902D.2030204@redhat.com> Message-ID: <1663867151.6314358.1343761959445.JavaMail.root@redhat.com> Roy is working on a way to prevent this from happening: http://gerrit.ovirt.org/#/c/6785/ ----- Original Message ----- > From: "Yair Zaslavsky" > To: engine-devel at ovirt.org > Sent: Tuesday, July 31, 2012 10:58:37 AM > Subject: [Engine-devel] Reminder - common > > Hi, > Please do not insert projects to pom.xml which do not compile by both > engine core and gwt. > > Thanks, > Yair > > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From Ricky.Hopper at netapp.com Tue Jul 31 20:30:37 2012 From: Ricky.Hopper at netapp.com (Hopper, Ricky) Date: Tue, 31 Jul 2012 20:30:37 +0000 Subject: [Engine-devel] Domain rescan action question Message-ID: Hey all, As I'm making progress with the domain rescan functionality, I've realized that I'm unsure what to do with any disks that are detected on the domain. Should I add them back into the database to be listed as floating disks, or should I just return a list of disk images to be attached to whatever the caller of the query needs? - Ricky -------------- next part -------------- An HTML attachment was scrubbed... URL: From snmishra at linux.vnet.ibm.com Tue Jul 31 20:44:41 2012 From: snmishra at linux.vnet.ibm.com (snmishra at linux.vnet.ibm.com) Date: Tue, 31 Jul 2012 13:44:41 -0700 Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120731152553.GC4725@bogey.xentower.nl> References: <20120731100043.GA4725@bogey.xentower.nl> <1636398506.1290873.1343742250166.JavaMail.root@redhat.com> <20120731152553.GC4725@bogey.xentower.nl> Message-ID: <20120731134441.Horde.SjnvwJir309QGEO5nM2T-nA@imap.linux.ibm.com> Quoting Ewoud Kohl van Wijngaarden : > On Tue, Jul 31, 2012 at 09:44:10AM -0400, Alon Bar-Lev wrote: >> Ewoud Kohl van Wijngaarden wrote: >> > On Tue, Jul 31, 2012 at 10:09:26AM +0100, Daniel P. Berrange wrote: >> > > On Tue, Jul 31, 2012 at 09:18:50AM +0300, Itamar Heim wrote: >> > > > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: >> > > > 5.2 novnc websocket server - i see three options >> > > > >> > > > 5.2.1 extend qemu to do this, so novnc can connect to it directly >> > > > like we do today for vnc/spice >> > > >> > > I don't think this is a desirable approach. One of the nice >> > > benefits >> > > you gain from using a websocket proxy is that you only need to have >> > > one single TCP port exposed to the internet now. If you put >> > > websockets >> > > in QEMU itself, you'd be stuck with having to open your firewall to >> > > allow 100's of ports. With a separate web proxy, you can even make >> > > each QEMU server now use a local UNIX socket for their VNC server, >> > > since only the proxy needs to be able to connect. This means that >> > > the VNC server would no longer be exposed to random local user >> > > access too. >> > >> > Another benefit of a proxy is that you can run it in a DMZ and not >> > have >> > to expose all your virtualization hosts to the internet. >> >> But this way you do expose them :) > > Since I've worked with VNCAuthProxy I'll explain how that works. > > First of all it listens on a control port. This can be inside the > firewall and has a simple JSON-based protocol. On this control port you > can ask it to open a connection on port X to virt-host.example.org:Y. > virt-host.example.org can also be behind the firewall and now only port > X is exposed to the internet. I am coming from the libvirt/libvirt-cim world and I don't completely follow this discussion. In libvrt-cim (higher level layer using libvirt to create and manage VMs), we took the input from user on what VNC IP, port, vncpassword etc. the user wants to use to access the VM and created a libvirt XML using these user provided values. This XML was then passed to libvirt which created the new VM and magically set vnc up. The user then opened any VNC viewer of their choice to access the VM. If ovirt is using libvirt, why can't we use the same magic? Pardon my ignorance here. -Sharad Mishra > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel From iheim at redhat.com Tue Jul 31 20:44:34 2012 From: iheim at redhat.com (Itamar Heim) Date: Tue, 31 Jul 2012 23:44:34 +0300 Subject: [Engine-devel] Domain rescan action question In-Reply-To: References: Message-ID: <501843B2.7030701@redhat.com> On 07/31/2012 11:30 PM, Hopper, Ricky wrote: > Hey all, > > As I'm making progress with the domain rescan functionality, I've > realized that I'm unsure what to do with any disks that are detected on > the domain. Should I add them back into the database to be listed as > floating disks, or should I just return a list of disk images to be > attached to whatever the caller of the query needs? > > - Ricky i'm not sure they should be added automatically. I think a dialog[1] showing orphan disks/images on the storage domain for user to choose which to import as 'floating' disks would be better than auto importing them. there is also the reverse of flagging existing disks as 'missing' in storage? [1] or a subtab on the storage domain. From abaron at redhat.com Tue Jul 31 21:21:58 2012 From: abaron at redhat.com (Ayal Baron) Date: Tue, 31 Jul 2012 17:21:58 -0400 (EDT) Subject: [Engine-devel] Domain rescan action question In-Reply-To: <501843B2.7030701@redhat.com> Message-ID: <1401554098.6341190.1343769718592.JavaMail.root@redhat.com> ----- Original Message ----- > On 07/31/2012 11:30 PM, Hopper, Ricky wrote: > > Hey all, > > > > As I'm making progress with the domain rescan functionality, I've > > realized that I'm unsure what to do with any disks that are > > detected on > > the domain. Should I add them back into the database to be listed > > as > > floating disks, or should I just return a list of disk images to be > > attached to whatever the caller of the query needs? > > > > - Ricky > > i'm not sure they should be added automatically. > I think a dialog[1] showing orphan disks/images on the storage domain > for user to choose which to import as 'floating' disks would be > better > than auto importing them. why? this same functionality would be used to import an existing domain. If these disks are referenced in OVFs we are not familiar with on this domain then we should import the *VMs*. If they are referenced by other VMs that are already in the system (but disks have been unreachable until now) then the disks should just be added to the db in attached mode. If neither, then the disks should be added as floating disks. For the import functionality, once you subsequently import another domain with OVFs which do reference these disks then if user hasn't appropriated them for other VMs then they would move to attached state, otherwise need to add those VMs with errors. Note that there are 2 reasons for unknown valid disks to be on the domain: 1. delete was initiated in engine but not performed on storage (then floating is fine as only way to automatically delete them is if user chooses to do so) 2. disks were created there outside of the system - should just detect and import and use logic above. > > there is also the reverse of flagging existing disks as 'missing' in > storage? If disks were floating then they should just be removed, otherwise should be moved to illegal state (we have this state for disks today). > > > [1] or a subtab on the storage domain. Another sub-tab for disks? It's possible but what would you do when importing an existing domain into the system? require user to manually select which disks to import? or would you have different flows for import of domain and rescan of contents? (I'd rather keep it simple with less tabs and manual operations for user to perform, seems more intuitive to me). From acathrow at redhat.com Tue Jul 31 21:24:42 2012 From: acathrow at redhat.com (Andrew Cathrow) Date: Tue, 31 Jul 2012 17:24:42 -0400 (EDT) Subject: [Engine-devel] Domain rescan action question In-Reply-To: <501843B2.7030701@redhat.com> Message-ID: <1049657803.1388688.1343769882067.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Itamar Heim" > To: "Ricky Hopper" > Cc: engine-devel at ovirt.org > Sent: Tuesday, July 31, 2012 4:44:34 PM > Subject: Re: [Engine-devel] Domain rescan action question > > On 07/31/2012 11:30 PM, Hopper, Ricky wrote: > > Hey all, > > > > As I'm making progress with the domain rescan functionality, I've > > realized that I'm unsure what to do with any disks that are > > detected on > > the domain. Should I add them back into the database to be listed > > as > > floating disks, or should I just return a list of disk images to be > > attached to whatever the caller of the query needs? > > > > - Ricky > > i'm not sure they should be added automatically. > I think a dialog[1] showing orphan disks/images on the storage domain > for user to choose which to import as 'floating' disks would be > better > than auto importing them. > > there is also the reverse of flagging existing disks as 'missing' in > storage? > Perhaps we should start a feature page to discuss and better scope it. There is a feature page that we could expand, it doesn't discuss the notion of importing those disks which is certainly something we need to address. http://wiki.ovirt.org/wiki/Features/Orphaned_Images > > [1] or a subtab on the storage domain. > > _______________________________________________ > Engine-devel mailing list > Engine-devel at ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > From ewoud+ovirt at kohlvanwijngaarden.nl Tue Jul 31 23:24:47 2012 From: ewoud+ovirt at kohlvanwijngaarden.nl (Ewoud Kohl van Wijngaarden) Date: Wed, 1 Aug 2012 01:24:47 +0200 Subject: [Engine-devel] Adding VNC support In-Reply-To: <20120731134441.Horde.SjnvwJir309QGEO5nM2T-nA@imap.linux.ibm.com> References: <20120731100043.GA4725@bogey.xentower.nl> <1636398506.1290873.1343742250166.JavaMail.root@redhat.com> <20120731152553.GC4725@bogey.xentower.nl> <20120731134441.Horde.SjnvwJir309QGEO5nM2T-nA@imap.linux.ibm.com> Message-ID: <20120731232447.GF4725@bogey.xentower.nl> On Tue, Jul 31, 2012 at 01:44:41PM -0700, snmishra at linux.vnet.ibm.com wrote: > Quoting Ewoud Kohl van Wijngaarden : > >On Tue, Jul 31, 2012 at 09:44:10AM -0400, Alon Bar-Lev wrote: > >>Ewoud Kohl van Wijngaarden wrote: > >>> On Tue, Jul 31, 2012 at 10:09:26AM +0100, Daniel P. Berrange wrote: > >>> > On Tue, Jul 31, 2012 at 09:18:50AM +0300, Itamar Heim wrote: > >>> > > On 07/26/2012 05:36 PM, snmishra at linux.vnet.ibm.com wrote: > >>> > > 5.2 novnc websocket server - i see three options > >>> > > > >>> > > 5.2.1 extend qemu to do this, so novnc can connect to it directly > >>> > > like we do today for vnc/spice > >>> > > >>> > I don't think this is a desirable approach. One of the nice > >>> > benefits > >>> > you gain from using a websocket proxy is that you only need to have > >>> > one single TCP port exposed to the internet now. If you put > >>> > websockets > >>> > in QEMU itself, you'd be stuck with having to open your firewall to > >>> > allow 100's of ports. With a separate web proxy, you can even make > >>> > each QEMU server now use a local UNIX socket for their VNC server, > >>> > since only the proxy needs to be able to connect. This means that > >>> > the VNC server would no longer be exposed to random local user > >>> > access too. > >>> > >>> Another benefit of a proxy is that you can run it in a DMZ and not > >>> have > >>> to expose all your virtualization hosts to the internet. > >> > >>But this way you do expose them :) > > > >Since I've worked with VNCAuthProxy I'll explain how that works. > > > >First of all it listens on a control port. This can be inside the > >firewall and has a simple JSON-based protocol. On this control port you > >can ask it to open a connection on port X to virt-host.example.org:Y. > >virt-host.example.org can also be behind the firewall and now only port > >X is exposed to the internet. > > I am coming from the libvirt/libvirt-cim world and I don't > completely follow this discussion. In libvrt-cim (higher level layer > using libvirt to create and manage VMs), we took the input from user > on what VNC IP, port, vncpassword etc. the user wants to use to > access the VM and created a libvirt XML using these user provided > values. This XML was then passed to libvirt which created the new VM > and magically set vnc up. The user then opened any VNC viewer of > their choice to access the VM. If ovirt is using libvirt, why can't > we use the same magic? I'm not that familiar with the internals ovirt uses (above experience is based on ganeti[1]), but libvirt runs on the virtualisation host. Many users don't want to give those hosts direct internet access for security reasons. Think of a cloud provider based on oVirt / RHEV who wants to provide a console to their customers. AFAIK they Currently have to somehow make those hosts available and I think oVirt can be configured to use a separate network but having a proxy might align better with security policies at the cloud provider. I know my colleagues had to think of a solution for this because we didn't want to expose our RHEV hosts.