We don't have an agenda for today - open for suggestions.
If no other requests will be suggested for today's agenda we'll discuss
storage live migration and who ever is interested can join us.
Federico/ayal can you make the slot today at 1600?
In general loggers are recommended to be private static final, also have the correct class. (e.g. commons logging standards from PMD http://pmd.sourceforge.net/rules/logging-jakarta-commons.html)
In oVirt backend, very often the logger is just package protected, which allows classes in the same package to use it. Actually the classes that really use it are usualy subclasses, but what I believe is misleading in this case is that when reading a log, you will see that e.g. org.foo.Bar logged 'X', and you look into the sourcecode of org.foo.Bar and you do not see any code that would ever log that message, you will have to look for that message in all of it's subclasses and this will make debugging harder especially if the number of subclasses is high.
I am trying to maintain a coding standard here, please feel free to edit:
Based on my recent experience with audit logs and event notifications, I
have created a Wiki page explaining how to introduce the same for a new
entity in oVirt. It is available at following URL:
Please feel free to contribute to the same in order to correct any
discrepancies or enhance the information provided.
∘ provision MTU when network is down
∘ valid values? -1, minimum = 68, maximum = configurable
∘ MTU -1 -> dont send the value to VDSM let the default take place
∘ mtu checkbox, label : "override MTU" , unchecked, value box always blank when uncheck.
∘ mtu box checked, show a box for a value
∘ support matrix of co-exisiting networks MTU values on single interface - open issue
• remove stp from the dialog
• checked by default for management network as well
∘ On what host status we allow to run setup networks on ? - open issue
∘ boxes are a bit naked. Add icons for allowed actions on each interface box.
I am running sonar (http://www.sonarsource.org/) on oVirt source code since last October and I would like to share some results with you.
http://twitpic.com/8son6o/full - showing the backend complexity, rules compliance and coverage. While complexity increased about 10%, the code coverage doubled.
http://twitpic.com/8soojz/full - size vs coverage in backend (100% would be green)
Unfortunately this server is on the internal network but it would be great to have a public sonar instance.
one of these commits inserted 3 new HIGH Priority bugs:
core : Fixing import of vm with snapshots (detail / gitweb)
restapi: rename case-sensitive matrix param (detail / gitweb)
restapi: Add JSON support (detail / gitweb)
pleae check here for more details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/278/
Gerrit ticket: http://gerrit.ovirt.org/#change,2164 was just merged,
This commit removes the SharedGwt module from oVirt maven structure,
This module aggregated backend source code of three modules: Common, Compat and SearchBackend for UI (gwt) modules during compile phase,
This is replaced now by a direct access to the backend modules using sources artifacts,
GWT module descriptor of SharedGwt maven module (named: SharedGwt.gwt.xml) contained a list of java classes that should be visible for the GWT compiler,
Since this module does not exist anymore, this file was split into three files per backend module:
Common.gwt.xml - Contains backend Common code that is visible to GWT compiler.
SearchBackend.gwt.xml - Contains SearchBackend code that is visible to GWT compiler.
Compat.gwt.xml - Contains backend Compat code that is visible to GWT compiler.
To avoid pushing UI related files directly into the backend modules, these files are located in gwt-common module, which contains shared code for UI modules.
In short: any backend source code that should be available during UI compilation which exist in Common|Compat|SearchBackend must be included in the appropriate GWT module descriptor according to its parent module.
Please contact me if this is causing any issue,
In order to identify whether a cluster exposes Gluster / Virtualization
capabilities, we plan to introduce two boolean columns - virt_service
and gluster_service in the vds_groups table. As per immediate plans, it
is intended to support only one service per cluster, meaning only one of
these two values can be true.
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table
- virt_service - boolean - NOT_NULL - default value true
- gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it
? By that logic, the name of our script will be something like
2) Modify vds_groups_sp.sql to introduce these arguments / variables in
save and update methods
3) Modify the DAO interface and implementation to introduce these
arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if
5) Modify class VDSGroup to introduce the two new boolean variables
virtService and glusterService and modify the methods equals and
hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have
annotations like @XmlElement and @Column. I think these are related to
jaxb and JPA. Are these annotations really required? If yes, how are
6) REST API : Default populate these variables (virtService = true,
glusterService = false) before invoking the BLL command
(AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the
existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables,
same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can
initialize these variables with default values, so that changes to UI /
REST API code (points 6 and 7) may not be required immediately. What do
Inputs / comments / suggestions welcome.