- Devel - oVirt List Archives

[Engine-devel] java 1.6 compatibility no more?
by Laszlo Hornyak 23 Jul '12

23 Jul '12

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

9 35

[Engine-devel] No more forking in bll tests
by Allon Mureinik 23 Jul '12

23 Jul '12

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.

1 0

[Engine-devel] Proposed change in default port numbers
by Juan Hernandez 18 Jul '12

18 Jul '12

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.

5 7

[Engine-devel] Getting rid of arch@ovirt.org?
by Ayal Baron 17 Jul '12

17 Jul '12

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.

8 12

[Engine-devel] Change in the location of krb5.conf
by Juan Hernandez 16 Jul '12

16 Jul '12

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.

1 0

[Engine-devel] Please review: Sync Networks enhancement
by Mike Kolesnik 15 Jul '12

15 Jul '12

--=_1e0ac87f-e0d0-4bb3-87c1-1bffd4f2d29f Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 --=_1e0ac87f-e0d0-4bb3-87c1-1bffd4f2d29f Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>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. <div>Regards, Mike </div> </div></body></html> --=_1e0ac87f-e0d0-4bb3-87c1-1bffd4f2d29f--

4 7

[Engine-devel] Requirements for hosts in a non-virt cluster.
by Steve Gordon 15 Jul '12

15 Jul '12

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

4 3

[Engine-devel] Minor trouble getting SSL enabled in JBOSS
by Frantz, Chris 12 Jul '12

12 Jul '12

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@localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:add [standalone@localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=name,value=https) [standalone@localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=key-alias,value=jboss) [standalone@localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=password,value=PASSWORD) [standalone@localhost:9999 /] /subsystem=web/connector=https/ssl=configuration/:write-attribute(name=certificate-key-file,value=/usr/share/jboss-as/.keystore) [standalone@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

2 1

[Engine-devel] Changes to engine DB DWH views.
by Yaniv Dary 09 Jul '12

09 Jul '12

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(a)redhat.com IRC : Yaniv D

1 0

[Engine-devel] Fwd: Problem in REST API handling/displaying of logical networks
by Mike Kolesnik 08 Jul '12

08 Jul '12

--=_4ee2f20c-97ca-4df5-82e5-22b48c2bc7b8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 --=_4ee2f20c-97ca-4df5-82e5-22b48c2bc7b8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= ><div style=3D"color:#000;font-weight:normal;font-style:normal;text-decorat= ion:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><style></s= tyle><div style=3D"font-family: Times New Roman; font-size: 12pt; color: #0= 00000">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 "l= ogical 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://engi= ne/api/cluster/xxx/networks The network itself is defined per DC lev= el, so for each DC you would have at least one logical network for mana= gement, which has some properties such as STP, MTU, etc.. The top lev= el collection is used to create/delete such network entities. The su= b-collection in the context of a Cluster is used to attach/detach a net= work from the DC of that cluster. The network in the context of a cluste= r has some additional information, let's say for example 'status' of the= network:     If a network is defined on all hosts in the clus= ter then it's status is     'Operational'.   &nb= sp; If a network is not defined on some of the hosts in the cluster then it= 's     status is 'Not Operational'[1]. -- Pro= blem -- The problem is that details which are only relevant in context o= f a cluster, are still displayed in the root context as well (e.g: 'stat= us'). This can, in certain cases, cause unexpected behaviour. For example,= let's consider this topology:   Data Center A   &nbsp= ;     |         |= \____ Network 'red'         |\____ Cluster A1<b= r>        |      &nb= sp;       \______ Network 'red' attached &= nbsp;       \____ Cluster A2    &nbsp= ;            &n= bsp;      \______ 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).<= br>If, however, the status is not the same (ie. on A1 the network is 'Op= erational' and on A2 it is 'Non Operational') then the top-level collec= tion will show two elements for the network, where all network details a= re the same and only the 'status' field is different. This is proble= matic IMHO for several reasons:   1. Showing one network in certain= states, and multiple copies of this       netw= ork in other states is not optimal, to say the least.   2. In the t= op-level collection there is no indicator of the cluster for which &nbsp= ;     the network is displayed, so there is no way to d= ifferentiate between the       two 'red' networ= k elements (they will have same id, name, etc.).   3. There is a ce= rtain asymmetry between the remove action[2] and the    =    result in that you would expect: you either remove a network b= ut in the       result you would see several el= ements removed. -- Proposed Solutions -- Personally I can thi= nk of several solutions to this problem:   1. Declare the top-level= collection as a collection of all networks that are    &= nbsp;  either attached to cluster or not, and if they are indeed attac= hed then       show the details for each cluste= r, including a link to the cluster.   2. Declare the top-level coll= ection as a collection of all networks that are     =   defined in data-centers, but they will not contain any cluster speci= fic       data, and thus each entry is unique.<= br> Solution #2 is breaking the API backwards-compatibility, since it in= cludes removing certain fields that have appeared today (namely 'status'= and 'display') but IMO would give a better experience since the top-lev= el collection is actually used for managing networks, and not their atta= chment to clusters which should be done in the context of each cluster.<= br> 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 simplicit= y I didn't      specify the new behaviour. [2] Cu= rrently you can't update the network if it's attached to any cluster, &n= bsp;    but perhaps in the future this would be possible.<br= > <div>Regards, Mike </div> </div></d= iv> </div></body></html> --=_4ee2f20c-97ca-4df5-82e5-22b48c2bc7b8--

12 36