[Engine-devel] namingcontexts getting ignored.
by Sharad Mishra
Hi,
I enter "getDefaultNamingContextFromNamingContexts()" with
namingContexts set to -
namingcontexts: CN=SCHEMA, CN=LOCALHOST, CN=IBMPOLICIES, O=IBM.COM,
O=DELETED.IBM.COM
But this method only takes the first case "CN=SCHEMA" and ignores
the rest. Actually I am interested in "O=IBM.COM".
Is this working as designed or needs improvement?
-Sharad Mishra
IBM
public class RootDSEData {
private String domainDN = null;
private LdapProviderType ldapProviderType = null;
private final static String RHDS_NAMING_CONTEXT = "o=netscaperoot";
public static String
getDefaultNamingContextFromNamingContexts(Attribute namingContexts) {
for (int index = 0; index < namingContexts.size(); ++index) {
String namingContext;
try {
namingContext = (String) namingContexts.get(index);
} catch (NamingException e) {
return null;
}
if (!RHDS_NAMING_CONTEXT.equalsIgnoreCase(namingContext)) {
return namingContext;
}
}
return null;
}
13 years
[Engine-devel] bi-weekly status
by Livnat Peer
Hi All,
It is memorial day in Israel tomorrow, so I am canceling tomorrow's
ovirt-engine-core meeting.
Please reply on the list if there is something that can't/shouldn't wait
for next meeting and I'll schedule a meeting for next week instead of
this one.
Thanks, Livnat
13 years
[Engine-devel] upstream/downstream compat
by Ryan Harper
I've submitted some changes to start some of the work of removing the
RHEV/RHEVM names throughout the vdsm code. In one of the patches,
there's a good discussion on compatibility with downstream[1]
And I wanted to continue that on the mailing list so we could have more
eyes; it's not clear to me if everyone is able to see/participate in an
inline thread to just one of my patches.
To the point; as we look at moving toward an upstream vdsm which may be
used stand-alone; ie, it may or may not having ovirt-engine/RHEVM
driving actions. I'm interested in hearing details what our
requirements for compatibility are and which parts of the tree might be
affected.
I'd like to posit that downstream compat is the responsibility of the
distro versus the upstream community; though that's not a license to
make things difficult. IMHO, this means we can do things that help
clean up the code or move the project in a particular direction without
having to always worry about what the package looks like in a particular
distro.
The other aspect to compatibility I'd like to hear details/discussion on
the interfaces (explicit or implicit) between vdsm and ovirt-engine.
I rekindled a discussion[2] on at least one known issue around engine
including the qemu machine type in the database; Any pointers to other
places would be helpful as I'm wrapping my head around the back and
forth between vdsm and engine.
1. http://gerrit.ovirt.org/#patch,unified,3287,1,vds_bootstrap/vds_bootstrap.py
2. http://lists.ovirt.org/pipermail/engine-devel/2012-April/001209.html
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
13 years
[Engine-devel] StorageHelperDirector "factory" and StorageType
by Yair Zaslavsky
Hi all,
StorageHelperDirector.java implements a mechanism that creates instances
of classes implementing IStorageHelper based on String value of
StorageType enum.
Although the InitializeHelpers method has an "automated" mechanism for
creating the helpers, I think it causes some bad practice -
It creates a tight coupling between the StorageType values and the class
names of storage helpers, and a result of that, Java naming convention
is broken (we use upper case enum literals at StorageType which yield
class names such as LOCALFSStorageHelper.
I think that this mechanism is an overkill, and during addition of new
storage type, its easily to detect during development if one has
forgotten to add the helper to the factory (if done manually).
Thoughts about this issue are more than welcome
Yair
13 years
Re: [Engine-devel] Floating Disks implementation in REST-API
by Ori Liel
I'd like us to move forward with this.
The option of using 'attach' action does not exist, because, as Eoghan observed, we would be executing an action on an entity which doesn't exist in the collection: (.../api/vms/{vm:id}/disks/???-no entity-???/attach)
There are two options left on the table; let's see if we can agree on one of them:
1)
POST/api/vms/{vm:id}/disks
<disk id="{disk:id}"/> => attach disk
DELETE .../api/vms/{vm:id}/disks/{disk:id}
<disk><detach>true</detach><disk> => detach disk
Pros: symmetrical
Cons: risky (if user wants to detach but forgot to give parameter, disk will be deleted).
2)
POST/api/vms/{vm:id}/disks
<disk id="{disk:id}"/> => attach disk
DELETE .../api/vms/{vm:id}/disks/{disk:id}/detach => detach disk
Pros: not dangerous
Cons: asymmetrical, attach done like add, but detach done using action.
No solution is perfect but we need to decide.
Thanks,
Ori.
13 years
[Engine-devel] Jar versions in ovirt-engine
by Ofer Schreiber
Ever wondered why the version of oVirt's first release is 3.0.0_0001?
The answer is simple - We use ovirt-engine jar's version as our "main" release version.
Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
What can we do about it? We have couple of options:
1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
2. Remove "_" from engine jars
3. Do nothing.
I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
---
Ofer Schreiber
oVirt Release Manager
13 years
[Engine-devel] [Jenkins] ovirt-engine fails due to last commit
by Eyal Edri
commit b9a6f23be188e2bf4d56f8b548db1b2536372385 - core: Add methods missing from PGHack (detail / gitweb)
Compilation Error:
Waiting for Jenkins to finish collecting data
mavenExecutionResult exceptions not empty
message : Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project dal: Compilation failure
/home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol
symbol : method getParentLogger()
location: interface javax.sql.DataSource
cause : Compilation failure
/home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol
symbol : method getParentLogger()
location: interface javax.sql.DataSource
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project dal: Compilation failure
/home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol
symbol : method getParentLogger()
location: interface javax.sql.DataSource
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:122)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:74)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
/home/jenkins/workspace/ovirt_engine/backend/manager/modules/dal/src/main/java/org/ovirt/engine/core/dal/dbbroker/PGHack.java:[68,19] cannot find symbol
symbol : method getParentLogger()
location: interface javax.sql.DataSource
at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 27 more
13 years
