Re: Reviewboard and jenkins

[Hugo]

Hey Chip,

Working on it! :-)

Cheers,

Hugo

On Friday, July 26, 2013, Chip Childers wrote:

> Hugo,
>
> Any chance you could add some logic to pick the right branch for the build
> test?
>
>
> On Mon, Jul 22, 2013 at 6:06 AM, Hugo Trippaers 
> >
> wrote:
>
> > The job is running on jenkins.cloudstack.org
> >
> > This is de job doing the work:
> >
> >
> http://jenkins.cloudstack.org/view/management/job/mgmt-build-reviewboard-requests/
> >
> > This is the job being executed with the patch:
> >
> >
> http://jenkins.cloudstack.org/view/master/job/cloudstack-master-with-patch/
> >
> > I really like the pipeline ideas, but we need to be careful with the
> > timing and the external factors influencing builds. If we run complex
> > chains there is a possibility that jobs will fail due to external
> factors.
> > This would reflect badly on reviewboard as that review would be marked as
> > "bad" for a reason that has nothing to do with the patch itself.
> >
> > For now i would like to stick with just the unit tests (master build) and
> > when this proves stable we can add other builds in the chain?
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On Jul 20, 2013, at 6:58 PM, Prasanna Santhanam 
> > >
> wrote:
> >
> > > On Sat, Jul 20, 2013 at 09:46:59AM -0400, David Nalley wrote:
> > >> On Sat, Jul 20, 2013 at 5:53 AM, Hugo Trippaers 
> > >> 
> >
> > wrote:
> > >>>
> > >>>
> > >>> Sent from my iPhone
> > >>>
> > >>> On 20 jul. 2013, at 10:09, Prasanna Santhanam 
> > >>> >
> wrote:
> > >>>
> > >>>> On Sat, Jul 20, 2013 at 12:20:11AM +0200, Hugo Trippaers wrote:
> > >>>>>
> > >>>>> On Jul 19, 2013, at 7:15 PM, Daan Hoogland <
> daan.hoogl...@gmail.com >
> > wrote:
> > >>>>>
> > >>>>>> good stuff, does it run the risk of running while another instance
> > is busy?
> > >>>>>
> > >>>>> Probably not, it's a single threaded script. I intend to use
> jenkins
> > >>>>> to schedule it and i can tell jenkins not to start another instance
> > >>>>> of a job once one is running.
> > >>>> should set a "quiet period" for the job so that it doesn't kick up
> > >>>> jobs for each checkin but a group instead. we'll run out of
> executors
> > >>>> fast if that happens.
> > >>>
> > >>> Every time the script runs it will look at the newest 20 submissions
> > and process them in order. That should be ok for now.
> > >>>
> > >>
> > >> I actually wonder if we shouldn't pipeline this - e.g. - does the
> > >> patch apply
> > >> If it applies does it build (and have unit tests pass)
> > >> If it builds does it package
> > >> If it packages, do the integration tests pass (or given the long
> > >> running nature, perhaps we have stages of that as well)
> > >>
> > >> The first three are pretty easy to scale using on-demand resources.
> > >
> > > Yup that's what I'd like to do with this as well. The simulator
> > > pipeline that Ian is helping build will tie in very well with this.
> > >
> > >>
> > >>
> > >>>>
> > >>>>> There are probably some bug still in the script, but hey we got to
> > >>>>> start somewhere. ;-)
> > >>>>
> > >>>> Absolutely, could you put it up on cso-infra/github so we can hack
> it
> > >>>> and customize?
> > >>>
> > >>> Absolutely, will put it there this weekend if I have some time. I
> > don't have enough permissions to setup a new repo in CloudStack extras
> yet.
> > >>>
> > >>
> > >>
> > >> You do now.
> > >
> > > --
> > > Prasanna.,
> > >
> > > 
> > > Powered by BigRock.com
> > >
> >
> >
> >
>


-- 
Tsune ni ite, kyu ni awasu.

Hugo
h...@strocamp.net

Re: systemvm.iso does not get copied with mvn jetty:run

[Hugo]

Just noticed Kelvens commit f35272b6c585f85c5c0f1e92f99b8224feceb29e

That fixed it right?

Cheers,

Hugo


On Thu, Apr 11, 2013 at 8:46 PM, Hugo Trippaers  wrote:

> Ouch. I'll try and fix that. Without this commit it would use the
> systemvm.iso from the previous compile, which is also bad.
>
> Probably some tweaking in the phases should be ok.
>
> Cheers,
>
> Hugo
>
> Sent from my iPhone
>
> On 11 apr. 2013, at 19:33, Chiradeep Vittal 
> wrote:
>
> > Hi Hugo,
> >
> > With the change 4a7d392f1, the systemvm.iso no longer appears in
> > cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/vms/systemvm.iso
> >
> > For 'clean' hypervisors this means that during a developer build and
> test,
> > the systemvm.iso is no longer copied over.
> >
> > I'd like to revert this. I do not understand the intent of the commit, so
> > I can't fix both issues.
> >
> >
> > On 4/3/13 5:56 AM, "h...@apache.org"  wrote:
> >
> >> Updated Branches:
> >> refs/heads/master 44567453e -> 4a7d392f1
> >>
> >>
> >> Summary: Small changes to the maven phases.
> >>
> >> Moved the copy of the systemvm to the package phase as the systemiso is
> >> made during this phase. So in the original config the old systemvm.zip
> >> would be copied to the server.
> >>
> >> Add a cleanup to the console-proxy to clean the dist dir during the
> >> clean phase.
> >>
> >> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> >> Commit:
> http://git-wip-us.apache.org/repos/asf/cloudstack/commit/4a7d392f
> >> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/4a7d392f
> >> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/4a7d392f
> >>
> >> Branch: refs/heads/master
> >> Commit: 4a7d392f18d5720676cbb22174f2a1a3566cd163
> >> Parents: 4456745
> >> Author: Hugo Trippaers 
> >> Authored: Wed Apr 3 14:55:50 2013 +0200
> >> Committer: Hugo Trippaers 
> >> Committed: Wed Apr 3 14:55:50 2013 +0200
> >>
> >> --
> >> client/pom.xml|   26 --
> >> services/console-proxy/server/pom.xml |   12 
> >> 2 files changed, 32 insertions(+), 6 deletions(-)
> >> --
> >>
> >>
> >>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4a7d392f/client/pom
> >> .xml
> >> --
> >> diff --git a/client/pom.xml b/client/pom.xml
> >> index ff861b7..9323d0f 100644
> >> --- a/client/pom.xml
> >> +++ b/client/pom.xml
> >> @@ -279,6 +279,26 @@
> >>maven-antrun-plugin
> >>1.7
> >>
> >> +  
> >> +  
> >> +copy-systemvm
> >> +package
> >> +
> >> +  run
> >> +
> >> +
> >> +  
> >> + >> todir="${basedir}/target/generated-webapp/WEB-INF/classes/vms">
> >> +   >> dir="${basedir}/../services/console-proxy/server/dist">
> >> +
> >> +
> >> +  
> >> +
> >> +  
> >> +
> >> +  
> >>  
> >>generate-resource
> >>generate-resources
> >> @@ -306,12 +326,6 @@
> >>
> >>  
> >>
> >> - >> todir="${basedir}/target/generated-webapp/WEB-INF/classes/vms">
> >> -   >> dir="${basedir}/../services/console-proxy/server/dist">
> >> -
> >> -
> >> -  
> >> -
> >>
> >>  
> >>
> >>
> >>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4a7d392f/services/c
> >> onsole-proxy/server/pom.xml
> >> --
> >> diff --git a/services/console-proxy/server/pom.xml
> >> b/services/console-proxy/server/pom.xml
> >> index 0df7559..f57b4ca 100644
> >> --- a/services/console-proxy/server/pom.xml
> >> +++ b/services/console-proxy/server/pom.xml
> >> @@ -139,6 +139,18 @@
> >>  
> >>
> >>  
> >> +  
> >> +maven-clean-plugin
> >> +2.5
> >> +
> >> +
> >> +
> >> +dist
> >> +false
> >> +
> >> +
> >> +
> >> +
> >> 

Re: [DISCUSS] Java 7, tomcat 7 and further upgrades

[Hugo Trippaers]

Hey all,

Sorry for the threadomancy, but the discussion have become relevant again with 
the current issues with the libvirt library. Of course this could also be 
solved by updating the libvirt library with a jdk6 version. Still it might be 
good to revisit this topic.

It appears not to be possible to switch code style to 1.7 and produce a 1.6 
compatible binary. I remember this working with olders versions, but didn't dig 
to much into this.

So the new question in this thread will be, should we switch CloudStack to jdk 
1.7?

Cheers,

Hugo

On Jul 1, 2013, at 12:45 AM, Prasanna Santhanam  wrote:

> On Thu, Jun 27, 2013 at 04:18:40PM -0400, John Burwell wrote:
>> All,
>> 
>> I am +1 for Java7.  However, I would like to propose ridding
>> ourselves of Tomcat entirely and embedding a network stack such as
>> Netty (http://netty.io) with a servlet bridge.  We have one JSP in
>> the system that generates JSON resources.  It could be easily
>> eliminated with a simple servlet that generates JSON from a
>> ResourceBundle.  Outside of this JSP. I don't see any other
>> requirements for a JEE container besides hosting a servlet.  We
>> would gain a far simpler, self-contained deployment model (a single
>> jar).  Additionally, we would gain greater control of the startup
>> and shutdown lifecycle, as well as, threading dynamics.  If there is
>> interest in this approach, I have thoughts on how to achieve this
>> embedding and create a lightweight daemon framework that could be
>> used for all CloudStack daemons.
>> 
>> As an aside, I also think we should replace our hand-rolled NIO code
>> with Netty as well.
>> 
> 
> John - could you break this and other thoughts down a little more in
> what's involved?  Perhaps into its own thread. I don't know Netty. And
> my J2EE is shaky at best. 
> 
> It's been a previous wish on this list to have the packaging of
> cloudstack into a single easily deployable war instead of all the
> complicated packaging we do. So I'd like to hear more of that and
> other issues you describe.
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

[MERGE] changing nonoss to noredist

[Hugo Trippaers]

Hey all,

As discussed on the mailing list we want to change the name of the nonoss 
branch to noredist as this better reflects the reason for this separate branch.

In the branch nonoss-to-noredist i've made the necessary changes to the code. 
After merging this branch i will also update the wiki and the jenkins jobs. 
It's not a big change but something that we all must be aware of to avoid 
problems during compilation.

Tests done on this branch
 * compile test regular
 * compile test noredist
 * package RPM regular
 * package RPM noredist

Comments or feedback on this branch? Otherwise i will merge this branch .

Cheers,

Hugo

Re: conflicting dependencies between CloudStack and Whirr

[Hugo Trippaers]

The Nicira NVP plugin is also depending on gson. If we make any changes we need 
to validate against their api to ensure that the interface still works.

If we put the changes in a separate branch i'd be happy to run the changes 
against the api.

Cheers,

Hugo


On Sep 20, 2013, at 12:08 PM, Darren Shepherd  
wrote:

> After much searching I found the two lines of code I needed to get it to 
> serialize right.  I'll keep looking and see if I find other snags.  Maybe we 
> can just move to jackson we'll see, haven't tried to deserialize yet.  
> 
> Darren
> 
>> On Sep 19, 2013, at 4:25 PM, Alex Huang  wrote:
>> 
>> Darren,
>> 
>> When I looked into updating to the latest gson, the problem, IIRC, is things 
>> that weren't considered cyclical dependencies are suddenly considered 
>> cyclical with the latest.  I don't recall where though. 
>> 
>> --Alex
>> 
>>> -Original Message-
>>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>>> Sent: Thursday, September 19, 2013 1:33 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: conflicting dependencies between CloudStack and Whirr
>>> 
>>> Alright, I looked into this and it will take a bit more work to switch to 
>>> Jackson.
>>> The snag I hit was how we serialize commands for the agents.  We use a
>>> customer typeadatper in gson to produce a format like { "org.MyClass"
>>> : {...} }.  In jackson I don't see producing a similar format as being so 
>>> straight
>>> forward.  I'm sure there's an elegant solution, but I didn't immediately 
>>> find it.
>>> The problem is if you use a custom serializer in jackson and do
>>> writeObjectField(x.getClass().getName(), x), you'll get stuck in a loop
>>> because it will call your serializer again.  So if somebody can figure out 
>>> how to
>>> do this format easily in jackson, the rest looks simple enough.
>>> 
>>> So, being that it is not an obvious switch to using jackson, what is the 
>>> impact
>>> of moving to the latest gson?  What were the issue encountered when
>>> people tried it before?
>>> 
>>> Darren
>>> 
>>> 
>>> On Wed, Sep 18, 2013 at 4:42 PM, Darren Shepherd <
>>> darren.s.sheph...@gmail.com> wrote:
>>> 
>>>> I can do some analysis on this.  I'm always up for a terribly painful
>>>> refactor :)
>>>> 
>>>> Darren
>>>> 
>>>> 
>>>>> On Wed, Sep 18, 2013 at 4:06 PM, Alex Huang 
>>>> wrote:
>>>> 
>>>>> I actually did a quick try to update cloudstack to use newest gson
>>>>> version about 3 months back.  Had to roll it back but I didn't try
>>>>> very hard though.  Part of the reason why I decided to rollback is
>>>>> due to gson is used differently by various components in CloudStack
>>>>> and I didn't have time to get into each component to see if I break
>>>>> anything.  The other is also I thought using Jackson would be much
>>>>> better and thought our next attempt should be with Jackson.
>>>>> 
>>>>> Not that any of these helps you.  Just know updating CloudStack to
>>>>> latest gson is not simple.
>>>>> 
>>>>> --Alex
>>>>> 
>>>>>> -Original Message-
>>>>>> From: Andrei Savu [mailto:savu.and...@gmail.com]
>>>>>> Sent: Wednesday, September 18, 2013 10:53 AM
>>>>>> To: d...@whirr.apache.org
>>>>>> Cc: dev@cloudstack.apache.org
>>>>>> Subject: Re: conflicting dependencies between CloudStack and Whirr
>>>>>> 
>>>>>> It's easy to usr jclouds and whirr inside an OSGi container - just
>>>>>> add
>>>>> the
>>>>>> feature url. Bonus: you can also use jclouds shell interface (part
>>>>>> of
>>>>> jclouds cli).
>>>>>> 
>>>>>> Another option is to upgrade the CloudStack API to use the new version.
>>>>>>> On Sep 18, 2013 5:14 AM, "Han,Meng"  wrote:
>>>>>>> 
>>>>>>> Dear all,
>>>>>>> 
>>>>>>> I am adding an API to CloudStack which utilizes Whirr to launch
>>>>>>> various clusters on CloudStack. Now I am facing a dependency
>>>&

Moved the systemvm to its own maven project

[Hugo Trippaers]

Hey all,

Just a heads-up that i pushed this commit to master:

commit 6c261042821c5597dab8d6be85dc59c948424e13
Author: Hugo Trippaers 
Date:   Fri Sep 20 18:08:20 2013 +0800

Move the system vm to a separate maven project.

All (almost) files belonging to the systemvm aer now centralize in the 
systemvm directory. The code for the separate functions is still in the 
services directory. This will make the code easier to understa


This commit effectively separates the code in the console-proxy from the actual 
building of the systemvm.iso. The systemvm profile (mvn -Psystemvm) will now 
control if the systemvm will be build entirely instead of just determining if 
the iso will be built. For slight speed up in the complete compile just leave 
the systemvm profile disabled.

I think this will make it more clear for everybody where the systemvm is 
located as its current location in console-proxy was a bit confusing.

Testing done:
 * Setting up devcloud with new build and new systemvm.iso
 * Verified ssvm operation (nfs secondary storage)
 * Verified  cvm operation

As with all maven changes don't forget to update the maven configuration in 
your IDE. (For eclipse users, right-click on the project, Maven -> Update 
Project)

Cheers,

Hugo

Re: [MERGE] changing nonoss to noredist

[Hugo Trippaers]

All,

I've merged the branch to master.

Please beware that the nonoss flag is now gone from master. To build CloudStack 
with the non-redistributable components please use the noredist flag. Please 
adjust your build scripts accordingly.

I've updated the jenkins builds, but testing them is troublesome as all builds 
keep failing due to the libvirt issue.

On Sep 19, 2013, at 2:37 PM, Hugo Trippaers  wrote:

> Hey all,
> 
> As discussed on the mailing list we want to change the name of the nonoss 
> branch to noredist as this better reflects the reason for this separate 
> branch.
> 
> In the branch nonoss-to-noredist i've made the necessary changes to the code. 
> After merging this branch i will also update the wiki and the jenkins jobs. 
> It's not a big change but something that we all must be aware of to avoid 
> problems during compilation.
> 
> Tests done on this branch
> * compile test regular
> * compile test noredist
> * package RPM regular
> * package RPM noredist
> 
> Comments or feedback on this branch? Otherwise i will merge this branch .
> 
> Cheers,
> 
> Hugo

Re: Moved the systemvm to its own maven project

[Hugo Trippaers]

Hey Darren,

Good find. I've moved the dependency to the systemvm profile, including the ant 
tasks to copy the systemvm to the right location.

Cheers,

Hugo

On Sep 21, 2013, at 4:55 AM, Darren Shepherd  
wrote:

> I think the build is broken now.  client/pom.xml depends on cloud-systemvm,
> so if you don't put -Psystemvm the build breaks.  I think the
> cloud-systemvm dep in client/pom.xml needs to be conditional on the
> systemvm profile.
> 
> Darren
> 
> 
> On Fri, Sep 20, 2013 at 11:01 AM, Alex Huang  wrote:
> 
>> Nice!  Can't wait to look at this!
>> 
>> --Alex
>> 
>>> -Original Message-
>>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
>>> Sent: Friday, September 20, 2013 3:40 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Moved the systemvm to its own maven project
>>> 
>>> Hey all,
>>> 
>>> Just a heads-up that i pushed this commit to master:
>>> 
>>> commit 6c261042821c5597dab8d6be85dc59c948424e13
>>> Author: Hugo Trippaers 
>>> Date:   Fri Sep 20 18:08:20 2013 +0800
>>> 
>>>Move the system vm to a separate maven project.
>>> 
>>>All (almost) files belonging to the systemvm aer now centralize in
>> the
>>> systemvm directory. The code for the separate functions is still in the
>>> services directory. This will make the code easier to understa
>>> 
>>> 
>>> This commit effectively separates the code in the console-proxy from the
>>> actual building of the systemvm.iso. The systemvm profile (mvn
>> -Psystemvm)
>>> will now control if the systemvm will be build entirely instead of just
>>> determining if the iso will be built. For slight speed up in the complete
>>> compile just leave the systemvm profile disabled.
>>> 
>>> I think this will make it more clear for everybody where the systemvm is
>>> located as its current location in console-proxy was a bit confusing.
>>> 
>>> Testing done:
>>> * Setting up devcloud with new build and new systemvm.iso
>>> * Verified ssvm operation (nfs secondary storage)
>>> * Verified  cvm operation
>>> 
>>> As with all maven changes don't forget to update the maven configuration
>> in
>>> your IDE. (For eclipse users, right-click on the project, Maven -> Update
>>> Project)
>>> 
>>> Cheers,
>>> 
>>> Hugo
>> 

Re: Libvirt-java 0.5.0 has been released

[Hugo Trippaers]

Hey Wido,

Did they publish the updated jar with the same version number? If that is the 
case maven will not take care of it as by definition release artefacts will be 
cached indefinitely and never be replaced. Only snapshot dependencies will be 
updated.

Cheers,

HUgo



On Sep 21, 2013, at 3:03 PM, Wido den Hollander  wrote:

> 
> 
> On 09/17/2013 08:35 PM, Mike Tutkowski wrote:
>> I'm not familiar with how we package these binding classes in CloudStack.
>> 
>> Is there a new JAR I need to download or source code?
>> 
> 
> Sorry, forgot this one! Nothing to do on your side. Maven will take care of 
> this.
> 
> The RPM and DEB packaging will automatically include these bindings.
> 
> Wido
> 
>> Thanks!
>> 
>> 
>> On Mon, Sep 16, 2013 at 2:19 PM, Wido den Hollander  wrote:
>> 
>>> 
>>> 
>>> On 09/16/2013 07:46 PM, Min Chen wrote:
>>> 
>>>> I got the following test failure in building master:
>>>> 
>>>> Running com.cloud.hypervisor.kvm.**resource.**
>>>> LibvirtComputingResourceTest
>>>> Tests run: 3, Failures: 0, Errors: 2, Skipped: 1, Time elapsed: 0.059 sec
>>>> <<< FAILURE!
>>>> testCreateVMFromSpecLegacy(**com.cloud.hypervisor.kvm.**
>>>> resource.LibvirtComputi
>>>> ngResourceTest)  Time elapsed: 0.018 sec  <<< ERROR!
>>>> java.lang.**UnsupportedClassVersionError: org/libvirt/LibvirtException :
>>>> Unsupported major.minor version 51.0
>>>> at java.lang.ClassLoader.**defineClass1(Native Method)
>>>> at java.lang.ClassLoader.**defineClassCond(ClassLoader.**
>>>> java:631)
>>>> at java.lang.ClassLoader.**defineClass(ClassLoader.java:**615)
>>>> at java.security.**SecureClassLoader.defineClass(**
>>>> SecureClassLoader.java:141)
>>>> at java.net.URLClassLoader.**defineClass(URLClassLoader.**
>>>> java:283)
>>>> at java.net.URLClassLoader.**access$000(URLClassLoader.**java:58)
>>>> at java.net.URLClassLoader$1.run(**URLClassLoader.java:197)
>>>> at java.security.**AccessController.doPrivileged(**Native Method)
>>>> at java.net.URLClassLoader.**findClass(URLClassLoader.java:**190)
>>>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**306)
>>>> at sun.misc.Launcher$**AppClassLoader.loadClass(**
>>>> Launcher.java:301)
>>>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**247)
>>>> at
>>>> com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResourceTest.**
>>>> testCreateVM
>>>> FromSpecLegacy(**LibvirtComputingResourceTest.**java:64)
>>>> 
>>>> 
>>>> Wido, is this related to this libvirt change?
>>>> 
>>>> 
>>> I think so. I'll test this tomorrow, but I think the RedHat guys build the
>>> bindings with Java 7 since they all work on a recent Fedora version.
>>> 
>>> Wido
>>> 
>>> 
>>> 
>>>> Thanks
>>>> -min
>>>> 
>>>> 
>>>> 
>>>> On 9/16/13 4:28 AM, "Wido den Hollander"  wrote:
>>>> 
>>>>  On 09/16/2013 12:51 PM, Wei ZHOU wrote:
>>>>> 
>>>>>> Thanks Wido.
>>>>>> 
>>>>>> Do you know the minimal requirement of libvirt if we use libvirt-java
>>>>>> 0.5.0
>>>>>> ?
>>>>>> 
>>>>>> 
>>>>> There shouldn't be a difference in the required libvirt version. I
>>>>> implemented a couple of methods in the bindings which were already in
>>>>> libvirt for a long time, but the bindings was just missing them.
>>>>> 
>>>>> Wido
>>>>> 
>>>>> 
>>>>>> 2013/9/16 Wido den Hollander 
>>>>>> 
>>>>>>  Hi,
>>>>>>> 
>>>>>>> I worked with the RedHat guys last week to get libvirt-java 0.5.0
>>>>>>> released
>>>>>>> which has some nice new features for us:
>>>>>>> 
>>>>>>> - Supports different XML on destination host during migration
>>>>>>> - Supports resizing volumes
>>>>>>> - Supports more snapshot functionalities
>>>>>>> 
>>>>>>> I took the liberty to depend on 0.5.0 in master and also merge in the
>>>>>>> code
>>>>>>> for the VNC listen, we now no longer listen on 0.0.0.0 for VNC, which
>>>>>>> was a
>>>>>>> security issue imho.
>>>>>>> 
>>>>>>> The reason I'm bringing this to the list is that we can simplify some
>>>>>>> code
>>>>>>> around resizing volumes and snapshotting where we currently have some
>>>>>>> nasty
>>>>>>> scripts to do the work.
>>>>>>> 
>>>>>>> See my commits in libvirt-java: 
>>>>>>> http://www.libvirt.org/git/?p=<http://www.libvirt.org/git/?p=**>
>>>>>>> 
>>>>>>> libvirt-java.git;a=summary>>>>>> libvirt-java.gi <http://www.libvirt.org/git/?p=libvirt-java.gi>
>>>>>>> t;a=summary>
>>>>>>> 
>>>>>>> So keep in mind libvirt-java has some new features!
>>>>>>> 
>>>>>>> Wido
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 

Re: Libvirt-java 0.5.0 has been released

[Hugo Trippaers]

Ahh ok.

Any idea how long that is going to take? At the moment our automated build are 
basically non functional as they all fail to build and thus also don't kickoff 
the downstream builds like the noredist build. Can we revert to an older 
version of libvirt in the meantime to work around this issue?

Cheers,

Hugo


On Sep 21, 2013, at 3:28 PM, Wido den Hollander  wrote:

> 
> 
> On 09/21/2013 09:15 AM, Hugo Trippaers wrote:
>> Hey Wido,
>> 
>> Did they publish the updated jar with the same version number? If that is 
>> the case maven will not take care of it as by definition release artefacts 
>> will be cached indefinitely and never be replaced. Only snapshot 
>> dependencies will be updated.
>> 
> 
> They didn't publish a new JAR yet. They want some feedback on 0.5.0 first if 
> it technically works, if so, they will release 0.5.1 which is Java 6 
> compatible.
> 
> Wido
> 
>> Cheers,
>> 
>> HUgo
>> 
>> 
>> 
>> On Sep 21, 2013, at 3:03 PM, Wido den Hollander  wrote:
>> 
>>> 
>>> 
>>> On 09/17/2013 08:35 PM, Mike Tutkowski wrote:
>>>> I'm not familiar with how we package these binding classes in CloudStack.
>>>> 
>>>> Is there a new JAR I need to download or source code?
>>>> 
>>> 
>>> Sorry, forgot this one! Nothing to do on your side. Maven will take care of 
>>> this.
>>> 
>>> The RPM and DEB packaging will automatically include these bindings.
>>> 
>>> Wido
>>> 
>>>> Thanks!
>>>> 
>>>> 
>>>> On Mon, Sep 16, 2013 at 2:19 PM, Wido den Hollander  wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 09/16/2013 07:46 PM, Min Chen wrote:
>>>>> 
>>>>>> I got the following test failure in building master:
>>>>>> 
>>>>>> Running com.cloud.hypervisor.kvm.**resource.**
>>>>>> LibvirtComputingResourceTest
>>>>>> Tests run: 3, Failures: 0, Errors: 2, Skipped: 1, Time elapsed: 0.059 sec
>>>>>> <<< FAILURE!
>>>>>> testCreateVMFromSpecLegacy(**com.cloud.hypervisor.kvm.**
>>>>>> resource.LibvirtComputi
>>>>>> ngResourceTest)  Time elapsed: 0.018 sec  <<< ERROR!
>>>>>> java.lang.**UnsupportedClassVersionError: org/libvirt/LibvirtException :
>>>>>> Unsupported major.minor version 51.0
>>>>>> at java.lang.ClassLoader.**defineClass1(Native Method)
>>>>>> at java.lang.ClassLoader.**defineClassCond(ClassLoader.**
>>>>>> java:631)
>>>>>> at java.lang.ClassLoader.**defineClass(ClassLoader.java:**615)
>>>>>> at java.security.**SecureClassLoader.defineClass(**
>>>>>> SecureClassLoader.java:141)
>>>>>> at java.net.URLClassLoader.**defineClass(URLClassLoader.**
>>>>>> java:283)
>>>>>> at java.net.URLClassLoader.**access$000(URLClassLoader.**java:58)
>>>>>> at java.net.URLClassLoader$1.run(**URLClassLoader.java:197)
>>>>>> at java.security.**AccessController.doPrivileged(**Native Method)
>>>>>> at java.net.URLClassLoader.**findClass(URLClassLoader.java:**190)
>>>>>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**306)
>>>>>> at sun.misc.Launcher$**AppClassLoader.loadClass(**
>>>>>> Launcher.java:301)
>>>>>> at java.lang.ClassLoader.**loadClass(ClassLoader.java:**247)
>>>>>> at
>>>>>> com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResourceTest.**
>>>>>> testCreateVM
>>>>>> FromSpecLegacy(**LibvirtComputingResourceTest.**java:64)
>>>>>> 
>>>>>> 
>>>>>> Wido, is this related to this libvirt change?
>>>>>> 
>>>>>> 
>>>>> I think so. I'll test this tomorrow, but I think the RedHat guys build the
>>>>> bindings with Java 7 since they all work on a recent Fedora version.
>>>>> 
>>>>> Wido
>>>>> 
>>>>> 
>>>>> 
>>>>>> Thanks
>>>>>> -min
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 9/16/13 4:28 AM, "Wido den Hollander"  wrote:
>>>>>> 
>>>>>

Re: http://jenkins.cloudstack.org/ is down ?

[Hugo Trippaers]

Hey Laszlo,

We have that already :-)

On Jenkins.buildacloud.org you can find the job 
http://jenkins.buildacloud.org/view/management/job/mgmt-build-reviewboard-requests/

This job will regularly check the reviewboard for new reviews and use the 
Jenkins patch plugin to build master with that patch 
http://jenkins.buildacloud.org/view/master/job/cloudstack-master-with-patch/

Cheers,

Hugo

Sent from my iPhone

> On 21 sep. 2013, at 23:44, Laszlo Hornyak  wrote:
> 
> Hi,
> 
> Is it be possible to get jenkins automatically run a build with patches
> uploaded to reviewboard? It would be especially useful to make sure we do
> not break something in the non-os projects or other projects that need some
> special settings and/or do not build by default.
> 
> Thank you,
> Laszlo
> 
> 
>> On Sat, Sep 21, 2013 at 5:16 PM, David Nalley  wrote:
>> 
>> jenkins.buildacloud.org
>> 
>> On Fri, Sep 20, 2013 at 1:03 PM, Rayees Namathponnan
>>  wrote:
> 
> 
> 
> -- 
> 
> EOF

Re: http://jenkins.cloudstack.org/ is down ?

[Hugo Trippaers]

I fixed the job. The url still pointed to the jenkins.cloudstack.org, it's now 
pointing to jenkins.buildacloud.org.

The source for the script doing most of the magic is on gihub: 
https://github.com/CloudStack-extras/reviewboard-tools

Cheers,

Hugo




On Sep 22, 2013, at 1:34 AM, Laszlo Hornyak  wrote:

> Cool, then I only have to learn how to use it :-)
> 
> 
> On Sat, Sep 21, 2013 at 5:54 PM, Hugo Trippaers  wrote:
> 
>> Hey Laszlo,
>> 
>> We have that already :-)
>> 
>> On Jenkins.buildacloud.org you can find the job
>> http://jenkins.buildacloud.org/view/management/job/mgmt-build-reviewboard-requests/
>> 
>> This job will regularly check the reviewboard for new reviews and use the
>> Jenkins patch plugin to build master with that patch
>> http://jenkins.buildacloud.org/view/master/job/cloudstack-master-with-patch/
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> Sent from my iPhone
>> 
>>> On 21 sep. 2013, at 23:44, Laszlo Hornyak 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> Is it be possible to get jenkins automatically run a build with patches
>>> uploaded to reviewboard? It would be especially useful to make sure we do
>>> not break something in the non-os projects or other projects that need
>> some
>>> special settings and/or do not build by default.
>>> 
>>> Thank you,
>>> Laszlo
>>> 
>>> 
>>>> On Sat, Sep 21, 2013 at 5:16 PM, David Nalley  wrote:
>>>> 
>>>> jenkins.buildacloud.org
>>>> 
>>>> On Fri, Sep 20, 2013 at 1:03 PM, Rayees Namathponnan
>>>>  wrote:
>>> 
>>> 
>>> 
>>> --
>>> 
>>> EOF
>> 
> 
> 
> 
> -- 
> 
> EOF

Re: Moved the systemvm to its own maven project

[Hugo Trippaers]

Attachements are filtered.

Either send it in plain text or send it to my email directly and i'll commit it.

Cheers,

Hugo

On Sep 22, 2013, at 1:03 PM, Darren Shepherd  
wrote:

> I noticed that the 
> tools/appliance/definitions/systemvmtemplate/postinstall.sh scripts was not 
> updated to the new path.  Review board seems to be down, so I'll just attempt 
> to attach a patch to this email.
> 
> Darren
> 

VmWare SDK to vijava

[Hugo Trippaers]

Hey all,

This is something we wanted to do for a long time, but never got started as far 
as i know. With some time on my hands i've made some progress on this. I just 
pushed the branch vmwaresdk-to-vijava to git. In this branch i've changed the 
poms to use the vijava library (version 5.1) and i've started fixing all 
resulting compile errors.

It is not a complete drop in replacement, but apparently just enough to make it 
work with a few changes. The major issues i've encountered so far by working my 
way through VmwareResource.java are
 * changes to enums, slightly different naming convention for the values
 * vijava used arrays where vmware sdk uses lists
 * changes names of exceptions.

I've fixed all compile issues in VmwareResource.java at the moment and i will 
keep at it. If somebody want to pitch in, feel free. Just pick a file with 
compile errors and fix it :-)

So far i've not focussed on the potential benefits of the vijava library, let's 
get it compiling first so we can do some testing with the new library.

Is anybody planning some major work on the vmware stuff in CS? If you do, 
please let me know, so we can coordinate otherwise this will be a bother to 
merge into master eventually. ;-)

Cheers,

Hugo

Re: VmWare SDK to vijava

[Hugo Trippaers]

Hey Darren,

There is actually just a bit more to the vijava library than just processing 
the wsdl. It simplifies some of the weirder parts of the vmware sdk. And in 
general it seems a well maintained piece of code. I'd rather use that that have 
to keep another set of bindings in sync with the outside world. We already have 
custom versions our own bindings for xapi and i would prefer the get rid of 
those too.

With some work we could simplify parts of our vmware code, which would make it 
more easy to understand for the people working on it.

Cheers,

Hugo

On Sep 23, 2013, at 10:59 AM, Darren Shepherd  
wrote:

> I was looking at the vmware jar and realized it's just a jaxws generated
> client stubs.  I'm sure this has been discussed before, so I'm curious why
> we can't just download the wsdl and generate the stubs ourselves?  I assume
> we can't distribute the wsdl's, so we can just check in the java code minus
> the wsdl.  That should work fine at runtime.  I downloaded the sdk and
> generated the client with the below command and its 100% compatible with
> the vim25.jar
> 
> ~/Downloads/apache-cxf-2.7.6/bin/wsdl2java -frontend jaxws21 -p
> com.vmware.vim25 vim25/vimService.wsdl
> 
> Darren
> 
> 
> On Sun, Sep 22, 2013 at 4:09 AM, Hugo Trippaers  wrote:
> 
>> Hey all,
>> 
>> This is something we wanted to do for a long time, but never got started
>> as far as i know. With some time on my hands i've made some progress on
>> this. I just pushed the branch vmwaresdk-to-vijava to git. In this branch
>> i've changed the poms to use the vijava library (version 5.1) and i've
>> started fixing all resulting compile errors.
>> 
>> It is not a complete drop in replacement, but apparently just enough to
>> make it work with a few changes. The major issues i've encountered so far
>> by working my way through VmwareResource.java are
>> * changes to enums, slightly different naming convention for the values
>> * vijava used arrays where vmware sdk uses lists
>> * changes names of exceptions.
>> 
>> I've fixed all compile issues in VmwareResource.java at the moment and i
>> will keep at it. If somebody want to pitch in, feel free. Just pick a file
>> with compile errors and fix it :-)
>> 
>> So far i've not focussed on the potential benefits of the vijava library,
>> let's get it compiling first so we can do some testing with the new library.
>> 
>> Is anybody planning some major work on the vmware stuff in CS? If you do,
>> please let me know, so we can coordinate otherwise this will be a bother to
>> merge into master eventually. ;-)
>> 
>> Cheers,
>> 
>> Hugo

Re: VmWare SDK to vijava

[Hugo Trippaers]

On Sep 23, 2013, at 1:01 PM, Darren Shepherd  
wrote:

> Oh, I thought the primary motivation was just to get to fully open source
> and out of noredist.  I don't know enough about VMware and vijava so my
> comments may be off base (everything I know about vmware client is based
> off about 2 hours of googling), but my gut reaction is that its better to
> stick with mainstream than use vijava.  I understand the VMware wsdl is a
> complicated and weird API.  But the fact that you could drop vijava in real
> quick and it mostly matches the existing illustrates that its not a big
> departure from from the vmware bindings so doesn't seem to make consuming
> it much easier.  It seems that vijava was better than vmware sdk 2.5
> because you didn't need Apache Axis.  But vSphere 5.1 sdk is based off of
> JAXWS and thus doesn't need axis anymore.  If I'm going to put my trust in
> something at runtime I'd rather use the sun/oracle jaxws or apache CXF and
> not some custom xml/soap framework one guy wrote.

The drop in real quick bit is just for starters. Some of the enums have changes 
names and instead of lists vijava uses arrays. Those items are pretty quick to 
adapt. The real interesting things are in the serviceInstance etc. That's where 
there are some changes. A nice example is on the vijava website where 100 lines 
of "regular" vmware sdk is replaced by 20-something lines of vijava. I'd say 
dig a bit deeper and i could use the help with the conversion process.

> 
> Additionally, if somebody wants to know how to do something with VMware or
> why something isn't working, I'd rather point them to the VMware SDK
> documentation than vijava.  I would assume that there is going to be more
> information about the VMware library then there would be for vijava on
> stackoverflow and google in general.

Google it, so far you are right, but java projects are switching. Don't forget 
that vijava is sort of an official vmware project. It is being maintained by 
one of their engineers and actually published in the com.vmware namespace.

> 
> Finally, I wouldn't consider us generating and checking in the JAXWS
> bindings as being overhead in maintenance.  The xapi bindings are not the
> same thing.  VMware API is first and foremost a SOAP service.  The java
> bindings they provide are just a convenience in that they already generated
> the client stubs for you.  But if I was to consume any other SOAP service
> in the world, I would be generating my client stubs for it.  So this is
> just the normal approach you take to consume a webservice.  Typically you
> generate the stubs as part of the build and never check-in the generated
> code to git, but I don't think we can check the vmware wsdl into git (if we
> could, that would be ideal).  But basically, if I'm generating stubs or I'm
> using a java jar, its about the same overhead.  If the webservice moves
> from version X, I generate new stubs against version X of the wsdl.  If the
> jar changes to version X, I update the pom dependency to version X.  In
> both cases, you still have to regression test for compatibility, so testing
> effort trumps all other concerns.

I would seriously consider that overhead in maintenance. Now i don't even have 
to worry about that besides 4 lines of dependency in my maven project. 


> 
> So I'd personally like it if we just generated the stubs ourself and then
> we can move VMware plugin out of redist.  I guess it would be helpful if
> you could illustrate some of the benefits of vijava.  I know you wanted to
> get it working first so we could test the merits of it, I'm just having a
> hard time seeing why we would even attempt it, if we can just stick
> basically with what we have today, but make it all open source and
> distributable.

Stay tuned and follow the commits :-)


> 
> Darren

Cheers,

Hugo

Re: VmWare SDK to vijava

[Hugo Trippaers]

On Sep 23, 2013, at 1:39 PM, Darren Shepherd  
wrote:

> Yeah, I'll dig into it more.  I think I understand a bit that vmware api is 
> just a bunch of generics objects, so another library on top to create types 
> on top of it helps.  So I'll look at it more.  In the end I'm still going to 
> probably have reservations about 1) a custom XML/soap framework 2) a third 
> party maintained later between us and vmware (sorta like libvirt-java always 
> behind and incomplete with native libvirt).  So it just depends on if the 
> nicer api is worth the risk of the other things.  I don't think vmwares api 
> changes much, and you can always get to the generic objects so maybe my 
> concerns are moot.  

Thanks, i could actually use a second pair of eyes if we want to get this into 
master. It would be nice to have a few people test this. I don't really share 
the concern on the XML/soap framework one is a good or bad as the other 
usually, i've seen interesting things with the axes framework as well. But 
thats besides the point for now. My main objective now it to get vijava working 
with as little changes as possible. Later we can do some refactoring and see if 
vijava really benefits us as much as i think/hope it will do. 

Your second concern is one i share, we will have to see how it goes. Vmware 
doesn't really change its api that often and if it does we are generally not 
the early adopters of new versions of libraries. So for now we should be ok. 

Hopefully we will get the vmware stuff in the redistributable build which is 
the primary objective here. All benefits are nice to have for future 
developments.

Cheers,

Hugo

> 
> Darren
> 
>> On Sep 22, 2013, at 10:14 PM, Hugo Trippaers  wrote:
>> 
>> 
>>> On Sep 23, 2013, at 1:01 PM, Darren Shepherd  
>>> wrote:
>>> 
>>> Oh, I thought the primary motivation was just to get to fully open source
>>> and out of noredist.  I don't know enough about VMware and vijava so my
>>> comments may be off base (everything I know about vmware client is based
>>> off about 2 hours of googling), but my gut reaction is that its better to
>>> stick with mainstream than use vijava.  I understand the VMware wsdl is a
>>> complicated and weird API.  But the fact that you could drop vijava in real
>>> quick and it mostly matches the existing illustrates that its not a big
>>> departure from from the vmware bindings so doesn't seem to make consuming
>>> it much easier.  It seems that vijava was better than vmware sdk 2.5
>>> because you didn't need Apache Axis.  But vSphere 5.1 sdk is based off of
>>> JAXWS and thus doesn't need axis anymore.  If I'm going to put my trust in
>>> something at runtime I'd rather use the sun/oracle jaxws or apache CXF and
>>> not some custom xml/soap framework one guy wrote.
>> 
>> The drop in real quick bit is just for starters. Some of the enums have 
>> changes names and instead of lists vijava uses arrays. Those items are 
>> pretty quick to adapt. The real interesting things are in the 
>> serviceInstance etc. That's where there are some changes. A nice example is 
>> on the vijava website where 100 lines of "regular" vmware sdk is replaced by 
>> 20-something lines of vijava. I'd say dig a bit deeper and i could use the 
>> help with the conversion process.
>> 
>>> 
>>> Additionally, if somebody wants to know how to do something with VMware or
>>> why something isn't working, I'd rather point them to the VMware SDK
>>> documentation than vijava.  I would assume that there is going to be more
>>> information about the VMware library then there would be for vijava on
>>> stackoverflow and google in general.
>> 
>> Google it, so far you are right, but java projects are switching. Don't 
>> forget that vijava is sort of an official vmware project. It is being 
>> maintained by one of their engineers and actually published in the 
>> com.vmware namespace.
>> 
>>> 
>>> Finally, I wouldn't consider us generating and checking in the JAXWS
>>> bindings as being overhead in maintenance.  The xapi bindings are not the
>>> same thing.  VMware API is first and foremost a SOAP service.  The java
>>> bindings they provide are just a convenience in that they already generated
>>> the client stubs for you.  But if I was to consume any other SOAP service
>>> in the world, I would be generating my client stubs for it.  So this is
>>> just the normal approach you take to consume a webservice.  Typically you
>>> generate the stubs as part 

Re: [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Hugo Trippaers]

+1 (binding)

Based on previous testing of the 5th round RC and a manual comparison of the 
differences.

Cheers,

Hugo


On Sep 23, 2013, at 2:24 PM, Marcus Sorensen  wrote:

> +0 (binding), created 4.1.1 zone with vms and a vpc, upgraded to 4.2
> via RPMs. Restarted vpc. Then wiped database and redeployed zone, vms
> to test 4.2 basic functionality. All on CentOS 6.4
> 
> The reason for the +0 is that I found a regression when going beyond
> the basic testing and trying things like maintenance mode, I'm not
> sure if it's related to the new storage framework or not, but it
> definitely didn't exist in the previous release. I'm including the bug
> below.  Basically the agent fails to connect to the management server
> on restart because we are trying to register the same pool multiple
> times. We should just check for the pool, match the uuid/properties,
> and say 'success' if it already exists. There is a hokey workaround,
> which is why I'm not going to block, if you stop libvirtd after taking
> the host out of maintenance and wait for the agent to reconnect, then
> you can start libvirtd again and everything will jumpstart into
> action. That can be done in order to complete a successful upgrade,
> and upon deploying a fresh zone I don't think anyone will notice until
> they go to use maintenance mode.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4725
> 
> Should be easy to fix, but I'm not going to look at it right this
> second. Maybe Edison can take a peek in the meantime.
> 
> Looks like nobody has voted yet, I'm not sure if that means nobody has
> tested over the weekend or if they're being more thorough. If we do
> find that nobody has tested, and decide to fix this, I'd request we
> pull in 39f7ddbb8f7eedb050da2991cdc1fb72a9e97f5f from 4.2-forward as
> well.
> 
> On Fri, Sep 20, 2013 at 9:36 PM, Animesh Chaturvedi
>  wrote:
>> 
>> 
>> 
>> 
>> I've created a 4.2.0 release, with the following artifacts up for a vote:
>> 
>> Git Branch and Commit SH:
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.2
>> Commit: 69c459342c568e2400d57ee88572b301603d8686
>> 
>> List of changes:
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2
>> 
>> Source release (checksums and signatures are available at the same
>> location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/
>> 
>> PGP release keys (signed using 94BE0D7C):
>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>> 
>> Testing instructions are here:
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure
>> 
>> Vote will be open for 72 hours (Monday 9/23 PST EOD).
>> 
>> For sanity in tallying the vote, can PMC members please be sure to indicate 
>> "(binding)" with their vote?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> 

Re: VmWare SDK to vijava

[Hugo Trippaers]

We have been having this discussion on moving vmware out of noredist since i 
joined the project. So no real need to rush this suddenly. Still it would be 
nice to get this in for the next release. The feature freeze of 4.3 is october 
31st for the 4.3 release. This change (or any sdk change to vmware) should be 
considered an architecture change so it should come in at the start of the new 
release cycle.

So this is currently my main activity on CloudStack meaning i can work pretty 
much dedicated on this. With a bit of luck i can have the changes finished this 
week. Then it's up to the test results if we can make it into the 4.3 release 
or the 4.4 release. Of course all pending a successful merge vote.

Cheers,

Hugo

On Sep 23, 2013, at 3:10 PM, Darren Shepherd  
wrote:

> It's seems there could be some good merit to adopting vijava.  I hate to 
> belabor this point, but we could get vmware plugin out of noredist real fast 
> if we just generate bindings (I think) 
> 
> Do you know if legally we can add the vmware wsdl to git?  We wouldn't 
> redistribute it in the binary builds.  If we could add the wsdl to git, I 
> could add a couple lines to the Pom and it will generate the bindings as part 
> of the build.  Then vmware will be fully redistributable and there is no 
> change to existing code.  At runtime everything should be the same too.  We 
> could make that change real fast and then additionally continue to look at 
> vijava.
> 
> Personal I want to get rid of noredist.  If somebody wants to contribute code 
> that depends on nonfree code, it seems that should be in a cloudstack-nonfree 
> repo.  
> 
> Darren
> 
>> On Sep 22, 2013, at 11:43 PM, Hugo Trippaers  wrote:
>> 
>> 
>>> On Sep 23, 2013, at 1:39 PM, Darren Shepherd  
>>> wrote:
>>> 
>>> Yeah, I'll dig into it more.  I think I understand a bit that vmware api is 
>>> just a bunch of generics objects, so another library on top to create types 
>>> on top of it helps.  So I'll look at it more.  In the end I'm still going 
>>> to probably have reservations about 1) a custom XML/soap framework 2) a 
>>> third party maintained later between us and vmware (sorta like libvirt-java 
>>> always behind and incomplete with native libvirt).  So it just depends on 
>>> if the nicer api is worth the risk of the other things.  I don't think 
>>> vmwares api changes much, and you can always get to the generic objects so 
>>> maybe my concerns are moot.  
>> 
>> Thanks, i could actually use a second pair of eyes if we want to get this 
>> into master. It would be nice to have a few people test this. I don't really 
>> share the concern on the XML/soap framework one is a good or bad as the 
>> other usually, i've seen interesting things with the axes framework as well. 
>> But thats besides the point for now. My main objective now it to get vijava 
>> working with as little changes as possible. Later we can do some refactoring 
>> and see if vijava really benefits us as much as i think/hope it will do. 
>> 
>> Your second concern is one i share, we will have to see how it goes. Vmware 
>> doesn't really change its api that often and if it does we are generally not 
>> the early adopters of new versions of libraries. So for now we should be ok. 
>> 
>> Hopefully we will get the vmware stuff in the redistributable build which is 
>> the primary objective here. All benefits are nice to have for future 
>> developments.
>> 
>> Cheers,
>> 
>> Hugo
>> 
>>> 
>>> Darren
>>> 
>>>> On Sep 22, 2013, at 10:14 PM, Hugo Trippaers  wrote:
>>>> 
>>>> 
>>>>> On Sep 23, 2013, at 1:01 PM, Darren Shepherd 
>>>>>  wrote:
>>>>> 
>>>>> Oh, I thought the primary motivation was just to get to fully open source
>>>>> and out of noredist.  I don't know enough about VMware and vijava so my
>>>>> comments may be off base (everything I know about vmware client is based
>>>>> off about 2 hours of googling), but my gut reaction is that its better to
>>>>> stick with mainstream than use vijava.  I understand the VMware wsdl is a
>>>>> complicated and weird API.  But the fact that you could drop vijava in 
>>>>> real
>>>>> quick and it mostly matches the existing illustrates that its not a big
>>>>> departure from from the vmware bindings so doesn't seem to make consuming
>>>>> it much easier.  It seems that vijava was better than vmware sdk 2.5
>>>>> becaus

Re: Moved the systemvm to its own maven project

[Hugo Trippaers]

Good point!

BTW Did you submit the appliance patch yet?

Cheers,

Hugo

On Sep 23, 2013, at 3:25 PM, Darren Shepherd  
wrote:

> The rat exclude list needs to be updated for this too.  Just noticed that is 
> what is breaking the Jenkins rat builds right now.
> 
> Darren
> 
>> On Sep 21, 2013, at 10:11 PM, Hugo Trippaers  wrote:
>> 
>> Attachements are filtered.
>> 
>> Either send it in plain text or send it to my email directly and i'll commit 
>> it.
>> 
>> Cheers,
>> 
>> Hugo
>> 
>>> On Sep 22, 2013, at 1:03 PM, Darren Shepherd  
>>> wrote:
>>> 
>>> I noticed that the 
>>> tools/appliance/definitions/systemvmtemplate/postinstall.sh scripts was not 
>>> updated to the new path.  Review board seems to be down, so I'll just 
>>> attempt to attach a patch to this email.
>>> 
>>> Darren
>> 

Re: VmWare SDK to vijava

[Hugo Trippaers]

Heya,

This biggest advantage i see in using vijava is that a lot of the functionality 
that we now have in the vmware-base project is already supplied with vijava.

There is a lot of code that facilitates calling tasks and other stuff in our MO 
classes. These classes are available in vijava and could be used instead of our 
classes. Basically when using vijava correctly you hardly have to work with the 
ManagedObjectReferences anymore. For me this would be a big benefit as it makes 
programming against vmware a lot easier. We also have a lot of duplicate code 
currently in the vmware class and i wouldn't mind getting rid of it, which i 
think is easier with the vijava libraries.

That said, the main driver is getting it into the main build so any other 
efforts towards that goal are ok with me.

I would propose that somebody else puts up a branch with our own wdsl wrapper 
and we open a discussion thread when both branches are ready to see which we 
want to merge in master. Anybody who wants to pick that up?

I'm stubbornly going to continue with converting to vijava, I put some effort 
into it and i want at least to see it running once ;-)  And the more i work 
with it the more i'm seeing to benefits of the library so i might be able to be 
more convincing in the end :-)

Cheers,

Hugo


On Sep 24, 2013, at 2:18 AM, Kelven Yang  wrote:

> Prior to 5.1, VMware provides java binding in its SDK and this is where
> CloudStack VMware integration began with. Starting from 5.1, VMware no
> longer provides the java binding in binary form and recommends its
> customers to generate directly from its WS WSDL.
> 
> Since we are not sure if we can distribute VMware wsdl legally or not,
> therefore, we ended up to generate and distribute the java binding in
> binary form. If we can get this cleared in lebal, as Darren pointed, we
> can solve our non-dist issue easily in matter of adding couple of lines in
> maven.
> 
> As of vijava, yes, I think it may add some value from developer's point of
> view, but on the other hand, I don't see immediate benefits to having
> another layer on top of VMware official WS API, vijava is an open source
> project for providing convenient java binding to vmware WS API, maybe I'm
> wrong, but I think VMware vSphere WS API is the only official published
> API from VMware, and the testing result of the API is endorsed by VMware
> as an commercial entity. So I see more business value to stick with the
> official WS API directly. If we can clear the legal concern of
> redistributing VMware wsdl. I would +1 to add a build step of generating
> VMware java binding from wsdl.
> 
> Kelven
> 
> 
> On 9/23/13 12:40 AM, "Hugo Trippaers"  wrote:
> 
>> We have been having this discussion on moving vmware out of noredist
>> since i joined the project. So no real need to rush this suddenly. Still
>> it would be nice to get this in for the next release. The feature freeze
>> of 4.3 is october 31st for the 4.3 release. This change (or any sdk
>> change to vmware) should be considered an architecture change so it
>> should come in at the start of the new release cycle.
>> 
>> So this is currently my main activity on CloudStack meaning i can work
>> pretty much dedicated on this. With a bit of luck i can have the changes
>> finished this week. Then it's up to the test results if we can make it
>> into the 4.3 release or the 4.4 release. Of course all pending a
>> successful merge vote.
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> On Sep 23, 2013, at 3:10 PM, Darren Shepherd
>>  wrote:
>> 
>>> It's seems there could be some good merit to adopting vijava.  I hate
>>> to belabor this point, but we could get vmware plugin out of noredist
>>> real fast if we just generate bindings (I think)
>>> 
>>> Do you know if legally we can add the vmware wsdl to git?  We wouldn't
>>> redistribute it in the binary builds.  If we could add the wsdl to git,
>>> I could add a couple lines to the Pom and it will generate the bindings
>>> as part of the build.  Then vmware will be fully redistributable and
>>> there is no change to existing code.  At runtime everything should be
>>> the same too.  We could make that change real fast and then additionally
>>> continue to look at vijava.
>>> 
>>> Personal I want to get rid of noredist.  If somebody wants to
>>> contribute code that depends on nonfree code, it seems that should be in
>>> a cloudstack-nonfree repo.
>>> 
>>> Darren
>>> 
>>>> On Sep 22, 2013, at 11:43 PM, Hugo Trippaers  wrote:
>>>> 
>>>> 
>>>>> On Sep 23, 2013, at 

Configuration table changes and database update

[Hugo Trippaers]

Hey all,

Noticed an interesting problem today. I was trying to start a management server 
based on the latest sources in master, but failed. The reason was that the 
configuration threw an exception that a certain column in the database fit not 
exist. This column is added during the database upgrade sequence, but 
apparently the configuration is already accessed before the database upgrade 
takes place.

Seems like a chicken and egg problem to me.

Did anybody else run into this problem?

Cheers,

Hugo

Re: VmWare SDK to vijava

[Hugo Trippaers]

So at this moment we have the following tally,

Darren, Alex, Kelven opt for the wsdl route
Hugo opts for the vijava route

I'm perfectly ok with ditching my work on the vijava in favour of the wsdl 
route. The arguments presented in the last few mails make a lot of sense. So i 
say the wsdl route is the way to go.

I do think however that we need to revisit the vmware code anyway. There is 
dead code in there, formatting issues and a general duplication of code. Parts 
of my plan to switch to vijava was to simplify the code as well, but i can 
still do that with the WSDL layer. 

Darren, did you run your wsdl branch through the BVT test suite? If you did we 
can merge it on short notice and get on with it. If you didn't can you take 
care of that and give an overview of the testing done on that branch besides 
the BVT?

Cheers,

Hugo


On Sep 25, 2013, at 2:58 AM, Kelven Yang  wrote:

> We have commercial releases on top of existing code base and there are
> lots of testing efforts behind it, dramatic switch means $ cost, the major
> concern for me is not about how beautiful vijava is or how bad a direct
> wsdl approach would be. it is about to get things move smoothly.
> 
> It looks like that we should have VMware layer on its own to have a plugin
> structure so that we can replace underlying binding easier, it should
> solve the balance between developer's tho motivation and carrying on the
> legacy with minimal impacts to the rest of others.
> 
> 
> Kelven
> 
> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
> 
>> Heya,
>> 
>> This biggest advantage i see in using vijava is that a lot of the
>> functionality that we now have in the vmware-base project is already
>> supplied with vijava.
>> 
>> There is a lot of code that facilitates calling tasks and other stuff in
>> our MO classes. These classes are available in vijava and could be used
>> instead of our classes. Basically when using vijava correctly you hardly
>> have to work with the ManagedObjectReferences anymore. For me this would
>> be a big benefit as it makes programming against vmware a lot easier. We
>> also have a lot of duplicate code currently in the vmware class and i
>> wouldn't mind getting rid of it, which i think is easier with the vijava
>> libraries.
>> 
>> That said, the main driver is getting it into the main build so any other
>> efforts towards that goal are ok with me.
>> 
>> I would propose that somebody else puts up a branch with our own wdsl
>> wrapper and we open a discussion thread when both branches are ready to
>> see which we want to merge in master. Anybody who wants to pick that up?
>> 
>> I'm stubbornly going to continue with converting to vijava, I put some
>> effort into it and i want at least to see it running once ;-)  And the
>> more i work with it the more i'm seeing to benefits of the library so i
>> might be able to be more convincing in the end :-)
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> 
>> On Sep 24, 2013, at 2:18 AM, Kelven Yang  wrote:
>> 
>>> Prior to 5.1, VMware provides java binding in its SDK and this is where
>>> CloudStack VMware integration began with. Starting from 5.1, VMware no
>>> longer provides the java binding in binary form and recommends its
>>> customers to generate directly from its WS WSDL.
>>> 
>>> Since we are not sure if we can distribute VMware wsdl legally or not,
>>> therefore, we ended up to generate and distribute the java binding in
>>> binary form. If we can get this cleared in lebal, as Darren pointed, we
>>> can solve our non-dist issue easily in matter of adding couple of lines
>>> in
>>> maven.
>>> 
>>> As of vijava, yes, I think it may add some value from developer's point
>>> of
>>> view, but on the other hand, I don't see immediate benefits to having
>>> another layer on top of VMware official WS API, vijava is an open source
>>> project for providing convenient java binding to vmware WS API, maybe
>>> I'm
>>> wrong, but I think VMware vSphere WS API is the only official published
>>> API from VMware, and the testing result of the API is endorsed by VMware
>>> as an commercial entity. So I see more business value to stick with the
>>> official WS API directly. If we can clear the legal concern of
>>> redistributing VMware wsdl. I would +1 to add a build step of generating
>>> VMware java binding from wsdl.
>>> 
>>> Kelven
>>> 
>>> 
>>> On 9/23/13 12:40 AM, "Hugo Trippaers"  wrote:
>>> 
>>>

Re: VmWare SDK to vijava

[Hugo Trippaers]

Darren, you can probably work with Prussians to get it through the bvt suite. 
That would be a nice start.

Cheers,

Hugo

Sent from my iPhone

> On 25 sep. 2013, at 09:06, Darren Shepherd  
> wrote:
> 
> My extensive testing consisted of "it compiles!"  So somebody needs to 
> validate it, I don't have a vmware setup handy.  The wsdl generation route is 
> not feasible unless legal says it's okay.  Somebody want to email legal@?
> 
> Darren
> 
>> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
>> 
>> So at this moment we have the following tally,
>> 
>> Darren, Alex, Kelven opt for the wsdl route
>> Hugo opts for the vijava route
>> 
>> I'm perfectly ok with ditching my work on the vijava in favour of the wsdl 
>> route. The arguments presented in the last few mails make a lot of sense. So 
>> i say the wsdl route is the way to go.
>> 
>> I do think however that we need to revisit the vmware code anyway. There is 
>> dead code in there, formatting issues and a general duplication of code. 
>> Parts of my plan to switch to vijava was to simplify the code as well, but i 
>> can still do that with the WSDL layer. 
>> 
>> Darren, did you run your wsdl branch through the BVT test suite? If you did 
>> we can merge it on short notice and get on with it. If you didn't can you 
>> take care of that and give an overview of the testing done on that branch 
>> besides the BVT?
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> 
>>> On Sep 25, 2013, at 2:58 AM, Kelven Yang  wrote:
>>> 
>>> We have commercial releases on top of existing code base and there are
>>> lots of testing efforts behind it, dramatic switch means $ cost, the major
>>> concern for me is not about how beautiful vijava is or how bad a direct
>>> wsdl approach would be. it is about to get things move smoothly.
>>> 
>>> It looks like that we should have VMware layer on its own to have a plugin
>>> structure so that we can replace underlying binding easier, it should
>>> solve the balance between developer's tho motivation and carrying on the
>>> legacy with minimal impacts to the rest of others.
>>> 
>>> 
>>> Kelven
>>> 
>>>> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>>>> 
>>>> Heya,
>>>> 
>>>> This biggest advantage i see in using vijava is that a lot of the
>>>> functionality that we now have in the vmware-base project is already
>>>> supplied with vijava.
>>>> 
>>>> There is a lot of code that facilitates calling tasks and other stuff in
>>>> our MO classes. These classes are available in vijava and could be used
>>>> instead of our classes. Basically when using vijava correctly you hardly
>>>> have to work with the ManagedObjectReferences anymore. For me this would
>>>> be a big benefit as it makes programming against vmware a lot easier. We
>>>> also have a lot of duplicate code currently in the vmware class and i
>>>> wouldn't mind getting rid of it, which i think is easier with the vijava
>>>> libraries.
>>>> 
>>>> That said, the main driver is getting it into the main build so any other
>>>> efforts towards that goal are ok with me.
>>>> 
>>>> I would propose that somebody else puts up a branch with our own wdsl
>>>> wrapper and we open a discussion thread when both branches are ready to
>>>> see which we want to merge in master. Anybody who wants to pick that up?
>>>> 
>>>> I'm stubbornly going to continue with converting to vijava, I put some
>>>> effort into it and i want at least to see it running once ;-)  And the
>>>> more i work with it the more i'm seeing to benefits of the library so i
>>>> might be able to be more convincing in the end :-)
>>>> 
>>>> Cheers,
>>>> 
>>>> Hugo
>>>> 
>>>> 
>>>>> On Sep 24, 2013, at 2:18 AM, Kelven Yang  wrote:
>>>>> 
>>>>> Prior to 5.1, VMware provides java binding in its SDK and this is where
>>>>> CloudStack VMware integration began with. Starting from 5.1, VMware no
>>>>> longer provides the java binding in binary form and recommends its
>>>>> customers to generate directly from its WS WSDL.
>>>>> 
>>>>> Since we are not sure if we can distribute VMware wsdl legally or not,
>>>>> therefore, we ended up to

Re: VmWare SDK to vijava

[Hugo Trippaers]

Hahah,

Yeah indeed, awful autocorrect.

Sent from my iPhone

> On 25 sep. 2013, at 10:01, Chiradeep Vittal  
> wrote:
> 
> Ha! Prussians == Prasanna?
> Godawful autocorrect.
> 
>> On 9/24/13 6:47 PM, "Hugo Trippaers"  wrote:
>> 
>> Darren, you can probably work with Prussians to get it through the bvt
>> suite. That would be a nice start.
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> Sent from my iPhone
>> 
>>> On 25 sep. 2013, at 09:06, Darren Shepherd
>>>  wrote:
>>> 
>>> My extensive testing consisted of "it compiles!"  So somebody needs to
>>> validate it, I don't have a vmware setup handy.  The wsdl generation
>>> route is not feasible unless legal says it's okay.  Somebody want to
>>> email legal@?
>>> 
>>> Darren
>>> 
>>>> On Sep 24, 2013, at 5:27 PM, Hugo Trippaers  wrote:
>>>> 
>>>> So at this moment we have the following tally,
>>>> 
>>>> Darren, Alex, Kelven opt for the wsdl route
>>>> Hugo opts for the vijava route
>>>> 
>>>> I'm perfectly ok with ditching my work on the vijava in favour of the
>>>> wsdl route. The arguments presented in the last few mails make a lot of
>>>> sense. So i say the wsdl route is the way to go.
>>>> 
>>>> I do think however that we need to revisit the vmware code anyway.
>>>> There is dead code in there, formatting issues and a general
>>>> duplication of code. Parts of my plan to switch to vijava was to
>>>> simplify the code as well, but i can still do that with the WSDL layer.
>>>> 
>>>> Darren, did you run your wsdl branch through the BVT test suite? If
>>>> you did we can merge it on short notice and get on with it. If you
>>>> didn't can you take care of that and give an overview of the testing
>>>> done on that branch besides the BVT?
>>>> 
>>>> Cheers,
>>>> 
>>>> Hugo
>>>> 
>>>> 
>>>>> On Sep 25, 2013, at 2:58 AM, Kelven Yang 
>>>>> wrote:
>>>>> 
>>>>> We have commercial releases on top of existing code base and there are
>>>>> lots of testing efforts behind it, dramatic switch means $ cost, the
>>>>> major
>>>>> concern for me is not about how beautiful vijava is or how bad a
>>>>> direct
>>>>> wsdl approach would be. it is about to get things move smoothly.
>>>>> 
>>>>> It looks like that we should have VMware layer on its own to have a
>>>>> plugin
>>>>> structure so that we can replace underlying binding easier, it should
>>>>> solve the balance between developer's tho motivation and carrying on
>>>>> the
>>>>> legacy with minimal impacts to the rest of others.
>>>>> 
>>>>> 
>>>>> Kelven
>>>>> 
>>>>>> On 9/23/13 6:01 PM, "Hugo Trippaers"  wrote:
>>>>>> 
>>>>>> Heya,
>>>>>> 
>>>>>> This biggest advantage i see in using vijava is that a lot of the
>>>>>> functionality that we now have in the vmware-base project is already
>>>>>> supplied with vijava.
>>>>>> 
>>>>>> There is a lot of code that facilitates calling tasks and other
>>>>>> stuff in
>>>>>> our MO classes. These classes are available in vijava and could be
>>>>>> used
>>>>>> instead of our classes. Basically when using vijava correctly you
>>>>>> hardly
>>>>>> have to work with the ManagedObjectReferences anymore. For me this
>>>>>> would
>>>>>> be a big benefit as it makes programming against vmware a lot
>>>>>> easier. We
>>>>>> also have a lot of duplicate code currently in the vmware class and i
>>>>>> wouldn't mind getting rid of it, which i think is easier with the
>>>>>> vijava
>>>>>> libraries.
>>>>>> 
>>>>>> That said, the main driver is getting it into the main build so any
>>>>>> other
>>>>>> efforts towards that goal are ok with me.
>>>>>> 
>>>>>> I would propose that somebody else puts up a branch with our own wdsl
>>>>>> wrapper and we open a disc

Re: [VOTE] Accept the donation of a Contrail plugin into Apache CloudStack

[Hugo Trippaers]

+1

Sent from my iPhone

> On 26 sep. 2013, at 05:44, "Musayev, Ilya"  wrote:
> 
> +1(binding)
> 
>> -Original Message-
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: Wednesday, September 25, 2013 5:23 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] Accept the donation of a Contrail plugin into Apache
>> CloudStack
>> 
>> +1 (binding)
>> 
>>> On 9/25/13 10:13 AM, "Chip Childers"  wrote:
>>> 
>>> Hi all!
>>> 
>>> As stated in other threads, Juniper is proposing the donation of a
>>> Contrail plugin to Apache CloudStack.  The code itself has been posted
>>> to reviewboard [1].  The design has been documented by Pedro [2].
>>> 
>>> [1] https://reviews.apache.org/r/14325/
>>> [2]
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Contrail+netwo
>> rk
>>> +pl
>>> ugin
>>> 
>>> I'm calling a vote here, so that we have a formal consensus on
>>> accepting the code into the project.  As I've suggested earlier, I'd
>>> like us to accept the code into a branch, and then work through any
>>> technical concerns / reviews / changes prior to a master branch merge.
>>> 
>>> So...  voting will end in ~72 hours.  As this is a technical decision,
>>> committer and PMC votes are binding.
>>> 
>>> -chip
>>> 
>>> 
>>> Votes please!
>>> 
>>> [ ] +1 - Accept the donation
>>> [ ] +/-0 - No strong opinion
>>> [ ] -1 - Do not accept the donation
> 
> 

Re: Review Request 14398: NumbersUtil cleanup

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14398/#review26603
---

Ship it!


Ship It!

- Hugo Trippaers


On Sept. 29, 2013, 7:24 a.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14398/
> ---
> 
> (Updated Sept. 29, 2013, 7:24 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> - removed methods that were not used
> - parseLong, parseInt and parseFloat replaced with the commons-lang 
> NumberUtils call
> - Test for the remaining methods
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/NumbersUtil.java 035239a 
>   utils/test/com/cloud/utils/NumbersUtilTest.java f60f58a 
> 
> Diff: https://reviews.apache.org/r/14398/diff/
> 
> 
> Testing
> ---
> 
> tests included
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: VmWare SDK to vijava

[Hugo Trippaers]

Darren,

Any update on the vmware patch? Did you get the patch tested already? Would be 
nice to get this in for the next release.

Cheers,

Hugo


On Sep 26, 2013, at 6:23 AM, David Nalley  wrote:

> On Tue, Sep 24, 2013 at 8:01 PM, Alex Huang  wrote:
>> Wow good guess...Hugo had me scratching my head on that oneIs Prussian 
>> some code name for Apache legalShould I askWould it make me look 
>> stupid if I askedall sorts of doubts going through my mind.
>> 
>> --Alex
>> 
> 
> I think Prasanna just earned a new nickname thanks to autocorrect. :)
> 
> --David

Re: Configuration table changes and database update

[Hugo Trippaers]

Heya guys,

I'm still running into this problem. Our jenkins automagically installs and 
tests the latest packages based on master. With a clean database on clean 
machines.

The error reported is similar to the error encountered:

Caused by: com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
com.mysql.jdbc.JDBC4PreparedStatement@64726693: SELECT configuration.instance, 
configuration.component, configuration.name, configuration.value, 
configuration.default_value, configuration.description, configuration.category, 
configuration.is_dynamic, configuration.scope, configuration.updated FROM 
configuration WHERE configuration.name = 
_binary'storage.cache.replacement.lru.interval'  ORDER BY RAND() LIMIT 1
at 
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:421)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:356)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
com.cloud.utils.db.GenericDaoBase.findOneIncludingRemovedBy(GenericDaoBase.java:869)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.framework.config.dao.ConfigurationDaoImpl.findByName(ConfigurationDaoImpl.java:201)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.framework.config.dao.ConfigurationDaoImpl.getValue(ConfigurationDaoImpl.java:166)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.storage.cache.manager.StorageCacheReplacementAlgorithmLRU.initialize(StorageCacheReplacementAlgorithmLRU.java:63)
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.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:346)
at 
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:299)
at 
org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:132)
... 79 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown 
column 'configuration.default_value' in 'field list'
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
at com.mysql.jdbc.Util.getInstance(Util.java:386)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1053)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4074)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4006)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2468)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2629)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2719)
at 
com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155)
at 
com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2318)
at 
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at 
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
at 
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:415)
... 116 more

The full log is here: 
http://nvpmadm1.nvp.strocamp.net:8080/job/cloudstack-qa-env-test/505/console

This still appears to be an issue. How can we make sure that the database is 
properly updated before this piece of code is hit? 

Cheers,

Hugo


On Sep 24, 2013, at 4:13 PM, Daan Hoogland  wrote:

> works in the latest version
> 
> On Tue, Sep 24, 2013 at 4:0

Re: Configuration table changes and database update

[Hugo Trippaers]

Just pushed a stop-gap fix to master. I'm running my qa tests now to check if 
it is ok now.

Cheers,

Hugo

Sent from my iPhone

> On 3 okt. 2013, at 12:18, Prasanna Santhanam  wrote:
> 
> This was my problem too for running tests o master :(
> 
> I posted CLOUDSTACK-4791 today for the issue.
> 
> 
>> On Thu, Oct 03, 2013 at 11:08:16AM +0200, Hugo Trippaers wrote:
>> Heya guys,
>> 
>> I'm still running into this problem. Our jenkins automagically installs and 
>> tests the latest packages based on master. With a clean database on clean 
>> machines.
>> 
>> The error reported is similar to the error encountered:
>> 
>> Caused by: com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
>> com.mysql.jdbc.JDBC4PreparedStatement@64726693: SELECT 
>> configuration.instance, configuration.component, configuration.name, 
>> configuration.value, configuration.default_value, configuration.description, 
>> configuration.category, configuration.is_dynamic, configuration.scope, 
>> configuration.updated FROM configuration WHERE configuration.name = 
>> _binary'storage.cache.replacement.lru.interval'  ORDER BY RAND() LIMIT 1
>>at 
>> com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:421)
>>at 
>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>at 
>> com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:356)
>>at 
>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>at 
>> com.cloud.utils.db.GenericDaoBase.findOneIncludingRemovedBy(GenericDaoBase.java:869)
>>at 
>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>at 
>> org.apache.cloudstack.framework.config.dao.ConfigurationDaoImpl.findByName(ConfigurationDaoImpl.java:201)
>>at 
>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>at 
>> org.apache.cloudstack.framework.config.dao.ConfigurationDaoImpl.getValue(ConfigurationDaoImpl.java:166)
>>at 
>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>at 
>> org.apache.cloudstack.storage.cache.manager.StorageCacheReplacementAlgorithmLRU.initialize(StorageCacheReplacementAlgorithmLRU.java:63)
>>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.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:346)
>>at 
>> org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:299)
>>at 
>> org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:132)
>>... 79 more
>> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
>> Unknown column 'configuration.default_value' in 'field list'
>>at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>at 
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>>at 
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
>>at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
>>at com.mysql.jdbc.Util.getInstance(Util.java:386)
>>at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1053)
>>at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4074)
>>at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4006)
>>at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2468)
>>at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2629)
>>at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2719)
>>at 
>> com.mysql.jdbc

Re: Configuration table changes and database update

[Hugo Trippaers]

It's fixed with commit 3f583684c6ddcf7efb66adada63957f8ca06cfdc

Not really the nicest of fixes, but at least the QA can continue. For a 
structural fix we would need to run the database upgrade check before 
initialising any of the beans. That can't be done yet as the upgrade checker 
depends on a dao bean at the moment.

Cheers,

Hugo

On Oct 3, 2013, at 12:47 PM, Hugo Trippaers  wrote:

> Just pushed a stop-gap fix to master. I'm running my qa tests now to check if 
> it is ok now.
> 
> Cheers,
> 
> Hugo
> 
> Sent from my iPhone
> 
>> On 3 okt. 2013, at 12:18, Prasanna Santhanam  wrote:
>> 
>> This was my problem too for running tests o master :(
>> 
>> I posted CLOUDSTACK-4791 today for the issue.
>> 
>> 
>>> On Thu, Oct 03, 2013 at 11:08:16AM +0200, Hugo Trippaers wrote:
>>> Heya guys,
>>> 
>>> I'm still running into this problem. Our jenkins automagically installs and 
>>> tests the latest packages based on master. With a clean database on clean 
>>> machines.
>>> 
>>> The error reported is similar to the error encountered:
>>> 
>>> Caused by: com.cloud.utils.exception.CloudRuntimeException: DB Exception 
>>> on: com.mysql.jdbc.JDBC4PreparedStatement@64726693: SELECT 
>>> configuration.instance, configuration.component, configuration.name, 
>>> configuration.value, configuration.default_value, 
>>> configuration.description, configuration.category, 
>>> configuration.is_dynamic, configuration.scope, configuration.updated FROM 
>>> configuration WHERE configuration.name = 
>>> _binary'storage.cache.replacement.lru.interval'  ORDER BY RAND() LIMIT 1
>>>   at 
>>> com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:421)
>>>   at 
>>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>>   at 
>>> com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:356)
>>>   at 
>>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>>   at 
>>> com.cloud.utils.db.GenericDaoBase.findOneIncludingRemovedBy(GenericDaoBase.java:869)
>>>   at 
>>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>>   at 
>>> org.apache.cloudstack.framework.config.dao.ConfigurationDaoImpl.findByName(ConfigurationDaoImpl.java:201)
>>>   at 
>>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>>   at 
>>> org.apache.cloudstack.framework.config.dao.ConfigurationDaoImpl.getValue(ConfigurationDaoImpl.java:166)
>>>   at 
>>> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>>   at 
>>> org.apache.cloudstack.storage.cache.manager.StorageCacheReplacementAlgorithmLRU.initialize(StorageCacheReplacementAlgorithmLRU.java:63)
>>>   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.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:346)
>>>   at 
>>> org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:299)
>>>   at 
>>> org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:132)
>>>   ... 79 more
>>> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
>>> Unknown column 'configuration.default_value' in 'field list'
>>>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>   at 
>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>>>   at 
>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De

RE: 4.2.1 rpm build failing - CLOUDSTACK-4808

[Hugo Trippaers]

Hey Rayees,

It's fixed.

You can find the 4.2 nonoss packages here if you want 
http://nvpmadm1.nvp.strocamp.net:8080/job/cloudstack-branch-4_2-package-rpm-nonoss/

Cheers,

Hugo

From: Rayees Namathponnan [mailto:rayees.namathpon...@citrix.com]
Sent: vrijdag 4 oktober 2013 7:30
To: Hugo Trippaers
Cc: dev@cloudstack.apache.org
Subject: 4.2.1 rpm build failing - CLOUDSTACK-4808

Hi Hugo,

4.2.1 rpm build failing; submitted patch for review; can you please review and 
push to 4.2.1 branch ?

https://reviews.apache.org/r/14482/
https://issues.apache.org/jira/browse/CLOUDSTACK-4808

Regards,
Rayees

Re: Review Request 13499: [GSoC] Add staticNat support to GRE controller

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13499/#review26726
---

Ship it!


Ship It!

- Hugo Trippaers


On Aug. 12, 2013, 5:09 p.m., tuna wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13499/
> ---
> 
> (Updated Aug. 12, 2013, 5:09 p.m.)
> 
> 
> Review request for cloudstack, Sebastien Goasguen and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> I make a patch for supporting staticNat service to gre controller. The 
> scenario is:
> + use GRE isolation method
> + create a network offering with staticNat,Connectivity (Ovs) and 
> sourceNat,...(VirtualRouter)
> + create a guest network using the above network offering
> + deploy VM, enable staticNat
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/ovs/src/com/cloud/api/response/OvsDeviceResponse.java
>  c0901b2 
>   
> plugins/network-elements/ovs/src/com/cloud/network/commands/AddOvsDeviceCmd.java
>  1abc324 
>   
> plugins/network-elements/ovs/src/com/cloud/network/commands/DeleteOvsDeviceCmd.java
>  87eedfb 
>   
> plugins/network-elements/ovs/src/com/cloud/network/commands/ListOvsDevicesCmd.java
>  2adb33a 
>   plugins/network-elements/ovs/src/com/cloud/network/element/OvsElement.java 
> 3824669 
>   plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsApi.java b533312 
>   plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsApiException.java 
> 20603e0 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsCreateGreTunnelAnswer.java
>  5f0f8c1 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsCreateGreTunnelCommand.java
>  e2cd2d8 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsCreateTunnelAnswer.java
>  fc2eb8a 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsCreateTunnelCommand.java
>  1ececa0 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsDeleteFlowCommand.java
>  2a6d5d7 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsDestroyBridgeCommand.java
>  8be5586 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsDestroyTunnelCommand.java
>  4594d99 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsFetchInterfaceAnswer.java
>  1ee6606 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsFetchInterfaceCommand.java
>  c27daf0 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsSetTagAndFlowAnswer.java
>  ba16839 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsSetTagAndFlowCommand.java
>  17121a0 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsSetupBridgeCommand.java
>  29cce15 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/StartupOvsCommand.java 
> b85331e 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/dao/OvsDeviceDao.java 
> 794e45e 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/dao/OvsDeviceDaoImpl.java
>  11a4d48 
>   plugins/network-elements/ovs/src/com/cloud/network/ovs/dao/OvsDeviceVO.java 
> cab63f6 
>   
> plugins/network-elements/ovs/src/com/cloud/network/resource/OvsResource.java 
> a94e4f8 
>   server/src/com/cloud/network/element/VirtualRouterElement.java ecf6473 
> 
> Diff: https://reviews.apache.org/r/13499/diff/
> 
> 
> Testing
> ---
> 
> Test done with above scenario. 
> Deploy VMs.
> enable/disable staticNat.
> 
> 
> Thanks,
> 
> tuna
> 
>

Re: Review Request 13499: [GSoC] Add staticNat support to GRE controller

[Hugo Trippaers]

> On Oct. 7, 2013, 11:47 a.m., Hugo Trippaers wrote:
> > Ship It!

Applied to the sdnextensions branch


- Hugo


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13499/#review26726
---


On Aug. 12, 2013, 5:09 p.m., tuna wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13499/
> ---
> 
> (Updated Aug. 12, 2013, 5:09 p.m.)
> 
> 
> Review request for cloudstack, Sebastien Goasguen and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> I make a patch for supporting staticNat service to gre controller. The 
> scenario is:
> + use GRE isolation method
> + create a network offering with staticNat,Connectivity (Ovs) and 
> sourceNat,...(VirtualRouter)
> + create a guest network using the above network offering
> + deploy VM, enable staticNat
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/ovs/src/com/cloud/api/response/OvsDeviceResponse.java
>  c0901b2 
>   
> plugins/network-elements/ovs/src/com/cloud/network/commands/AddOvsDeviceCmd.java
>  1abc324 
>   
> plugins/network-elements/ovs/src/com/cloud/network/commands/DeleteOvsDeviceCmd.java
>  87eedfb 
>   
> plugins/network-elements/ovs/src/com/cloud/network/commands/ListOvsDevicesCmd.java
>  2adb33a 
>   plugins/network-elements/ovs/src/com/cloud/network/element/OvsElement.java 
> 3824669 
>   plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsApi.java b533312 
>   plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsApiException.java 
> 20603e0 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsCreateGreTunnelAnswer.java
>  5f0f8c1 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsCreateGreTunnelCommand.java
>  e2cd2d8 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsCreateTunnelAnswer.java
>  fc2eb8a 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsCreateTunnelCommand.java
>  1ececa0 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsDeleteFlowCommand.java
>  2a6d5d7 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsDestroyBridgeCommand.java
>  8be5586 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsDestroyTunnelCommand.java
>  4594d99 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsFetchInterfaceAnswer.java
>  1ee6606 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsFetchInterfaceCommand.java
>  c27daf0 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsSetTagAndFlowAnswer.java
>  ba16839 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsSetTagAndFlowCommand.java
>  17121a0 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsSetupBridgeCommand.java
>  29cce15 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/StartupOvsCommand.java 
> b85331e 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/dao/OvsDeviceDao.java 
> 794e45e 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/dao/OvsDeviceDaoImpl.java
>  11a4d48 
>   plugins/network-elements/ovs/src/com/cloud/network/ovs/dao/OvsDeviceVO.java 
> cab63f6 
>   
> plugins/network-elements/ovs/src/com/cloud/network/resource/OvsResource.java 
> a94e4f8 
>   server/src/com/cloud/network/element/VirtualRouterElement.java ecf6473 
> 
> Diff: https://reviews.apache.org/r/13499/diff/
> 
> 
> Testing
> ---
> 
> Test done with above scenario. 
> Deploy VMs.
> enable/disable staticNat.
> 
> 
> Thanks,
> 
> tuna
> 
>

Re: Review Request 14168: [GSoC] Ading KVM support for GRE controller

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14168/#review26728
---

Ship it!


Applied to branch sdnextensions

- Hugo Trippaers


On Sept. 17, 2013, 3:32 a.m., tuna wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14168/
> ---
> 
> (Updated Sept. 17, 2013, 3:32 a.m.)
> 
> 
> Review request for cloudstack, Sebastien Goasguen and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> I add a patch about adding KVM support for GRE controller. This patch will 
> enable GRE working on KVM hypervisor
> 
> 
> Diffs
> -
> 
>   plugins/hypervisors/kvm/pom.xml 1babe7c 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  914017c 
>   scripts/vm/hypervisor/kvm/cloudstack_pluginlib.py PRE-CREATION 
>   scripts/vm/network/vnet/ovstunnel.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/14168/diff/
> 
> 
> Testing
> ---
> 
> Testing done. I will make a screencast demo asap
> 
> 
> Thanks,
> 
> tuna
> 
>

Re: Review Request 14482: CLOUDSTACK-4808 - Fix for build failure in 4.2.1. branch

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14482/#review26730
---


This is fixed with commit 2b47611c5d44893021016d2df9713c392cfa92df on master 
and commit acf5ad5bf3305b7167304ab738006e89a18009cd on 4.2.

Thanks for raising this issue.

- Hugo Trippaers


On Oct. 4, 2013, 5:12 a.m., Rayees Namathponnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14482/
> ---
> 
> (Updated Oct. 4, 2013, 5:12 a.m.)
> 
> 
> Review request for cloudstack, Frank Zhang and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-4808
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 4.2.1 RPM build failing, we need to remove below two check-ins from 4.2.1 
> branch; these changes are made during 4.2 release build 
> 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=8689f7f504acee7ccbf6870d409cbb47b177d598
>  
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=db9f5243c31cf00dbf3ed4a81585671c27bab469
>  
> 
> 
> Diffs
> -
> 
>   packaging/centos63/package.sh f30a0e7 
> 
> Diff: https://reviews.apache.org/r/14482/diff/
> 
> 
> Testing
> ---
> 
> tested with 4.2.1 RPM build
> 
> 
> Thanks,
> 
> Rayees Namathponnan
> 
>

Cloudstack collab Hackathons

[Hugo Trippaers]

Hey Guys,

The CloudStack collaboration conference is right around the corner. The first 
day of the conference will be dedicated to workshops and a hackathon.

I'm curious which developers are planning to attend the hackthon and what 
subjects you are interested in. In Santa Clara we had a short list of some 
subjects to discuss and some tables and discussions were already prepared in 
advance. In the upcoming conference we can do the same, so if you have a 
discussion or project idea that you want to work on at the hackthon let us know 
with a reply in this thread.

I'm also curious if there are any aspiring developers that would like to have a 
sort of introduction into cloudstack development during the hackathon.

If you have any other ideas, just shout.

Cheers,

Hugo

Jenkins build slaves

[Hugo Trippaers]

Hey Prasanna,

I've made a few changes to jclouds and jclouds-jenkins over the past few days. 
Yesterday i upgraded the plugin version on jenkins.bacd.org with my custom 
version. For now it seems to behave a lot better and the buildslaves appear to 
be created as they should be. So we can finally utilise the added capacity.

Currently we have the centos6 buildslaves available, but i'll see if i can 
build a debian slave template as well. Would be nice to have a lot of the 
builds running on a cloudstack cloud. Eat your own dogfood ;-)

We are still working on the cloud-in-a-cloud deployment from jenkins. We have 
the vmware equipment ready and when we upgrade our internal cloud to 4.2 we can 
enable the nested hypervisor option that i put in there. Sander is already 
working on templates for xenserver so we can deploy those on demand. 

Hopefully we have a lot of this stuff ready before CCC EU so we can sit down 
and work on the test stuff. How about we reserve some time at the hackaton to 
work on this?

Btw, i switched the incremental build of cloudstack-master back to a full 
build. We can only do the incremental build with the slaves if we have a 
central networked maven repository apparently.

Cheers,

Hugo

Re: Wiki access

[Hugo Trippaers]

Kishan,

look like you have the permissions already on account kishan. Can you check?

Cheers,

Hugo


On Oct 16, 2013, at 3:45 PM, Kishan Kavala  wrote:

> Please grant me edit access.
> Email: kis...@cloud.com
> 
> ~kishan
> 
>> -Original Message-
>> From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com]
>> Sent: Wednesday, 16 October 2013 3:22 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: Wiki access
>> 
>> Hi,
>> 
>> I do not have the edit permissions. My username is radhikap.
>> 
>> Kindly provide me with the necessary permissions.
>> 
>> Thanks
>> -Radhika
>> 
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Friday, October 04, 2013 3:26 PM
>> To: dev
>> Subject: Re: Wiki access
>> 
>> anshulg is in
>> 
>> 
>> On Fri, Oct 4, 2013 at 11:51 AM, Anshul Gangwar
>> wrote:
>> 
>>> need edit permissions , username: anshulg
>>> 
>>> Regards,
>>> Anshul
>>> 
>>> On Friday 04 October 2013 02:47 PM, Saksham Srivastava wrote:
>>>> Please provide me edit permissions, username: saksham
>>>> 
>>>> Regards,
>>>> Saksham
>>>> 
>>>> -Original Message-
>>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>>> Sent: Friday, October 04, 2013 10:46 AM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: Re: Wiki access
>>>> 
>>>> Mike, Tuna, Srinivas, Go, done.
>>>> 
>>>> On 10/3/13 9:12 PM, "Mike Tutkowski" 
>>> wrote:
>>>> 
>>>>> I seem to need edit access, as well.
>>>>> 
>>>>> I'm usually logged in by default, but I believe my username is
>>>>> mike-tutkowski (else please try mtutkowski).
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> 
>>>>> On Thu, Oct 3, 2013 at 7:07 PM, Go Chiba  wrote:
>>>>> 
>>>>>> Hi Chip,
>>>>>> 
>>>>>> Please grant me to edit pages. My id is "gochiba".
>>>>>> 
>>>>>> 
>>>>>> On Thu, Oct 3, 2013 at 6:01 AM, Chip Childers
>>>>>> >>>>>> wrote:
>>>>>>> Not all committers were easy to find, but those that I did should
>>>>>>> be
>>>>>> all
>>>>>>> set.
>>>>>>> 
>>>>>>> So committers / contributors = provide your confluence ID's if
>>>>>>> you
>>>>>> can't
>>>>>>> add / edit pages.  PMC folks - help add them please.
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Oct 2, 2013 at 4:48 PM, Chip Childers
>>>>>> >>>>>>> wrote:
>>>>>>>> There were major issues with Spam on the wiki, so infra changed
>>>>>>>> the permissions.
>>>>>>>> 
>>>>>>>> I've just gone and added all PMC members to the space as space
>>>>>> admins.
>>>>>>>>  That means all PMC members can help deal with this issue (or
>>>>>>>> at
>>>>>> least
>>>>>>>> those that I could find in the wiki user list).
>>>>>>>> 
>>>>>>>> I'm going to deal with committers next.  That permission level
>>>>>> needs to
>>>>>>>> exclude space admin.  I'm using alena1108 as the example for
>>>>>> committer
>>>>>> /
>>>>>>>> contributor permissions.
>>>>>>>> 
>>>>>>>> So if you are not a committer, give your confluence ID in this
>>>>>> thread
>>>>>> and
>>>>>>>> PMC folks can help get them added (make them look like alena's
>>>>>> perms).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Oct 2, 2013 at 4:35 PM, Chiradeep Vittal <
>>>>>>>> chiradeep.vit...@citrix.com> wrote:
>>>>>>>> 
>>>>>>>>> Apparently, edit access has been revoked for all. Who do we
>>>>>>>>> contact
>>>>>> for
>>>>>>>>> edit permissions?
>>>>>>>>> 
>>>>>>>>> TIA
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 千葉 豪  Go Chiba
>>>>>> E-mail:go.ch...@gmail.com
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> *Mike Tutkowski*
>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>> e: mike.tutkow...@solidfire.com
>>>>> o: 303.746.7302
>>>>> Advancing the way the world uses the
>>>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>>>> *?*
>>> 

Re: [MERGE] txn-refactor

[Hugo Trippaers]

Hey Darren,

I'm having a look at the branch. Takes some time so i will get back to you when 
i have something.

Did you run the bvt test suite on this branch already?

Cheers,

Hugo

On Oct 16, 2013, at 6:59 PM, Darren Shepherd  
wrote:

> I need as many people as possible to review this branch.  I'm still
> testing it out, but I wanted to get as many eyes on it as possible.
> This is a huge cross cutting change.  This branch is the changes to
> use a new Transaction API that will be consistent Spring TX's style so
> that we can eventually move to it.  You can get a bit more context
> from 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Database+Transactions
> 
> Having spent so much time looking at the transaction management in
> ACS, I'm well convinced we need to adopt Spring TX as soon as we can.
> I've found just too many bugs.  It will be a painful transitiion, as
> you can see from this branch.  It will also be very tricky, but I'll
> figure it out.
> 
> If you are reviewing this branch, use a diff tool that ignores
> whitespace.  Also if you don't know about "git difftool -d", you
> should use that.  Just know, its was 10x more tedious and painful for
> me to make this change then it is for you to review it :)
> 
> Darren

Re: [MERGE] txn-refactor

[Hugo Trippaers]

Hey Darren,

Looking through the code it looks like this more an API change than an actual 
redesign of the transaction code? I like the resulting code a lot better than 
the existing way of doing it. As far as i can see you wrapped the existing 
TransactionLegacy way of doing it (txn.start / txn.commit) inside of the new 
Transaction functions execute and executeWithException. So if i understand it 
correctly, nothing changed in how transactions are actually handled, except 
that the code can now be easily changed to use spring TX.

Also you made that changes to a couple of classes to use the new api, but the 
majority of the classes still need to be done. It might be nice to annotate the 
TransactionLegacy class with @Deprecated so we can easily identify what needs 
to be done?

The new code is not covered by any new unit test yet? I couldn't check the 
cobertura result yet as there are some build and test failures. Can you have a 
look at this build : 
http://jenkins.buildacloud.org/job/cloudstack-maven-build-with-branch-parameter/3/.
  You can kick off that job yourself from jenkins if you like to do the full 
test. Didn't do the noredist build test yet as the normal build failed.

In short there are some things to fix before we can merge this.


Cheers,

Hugo


On Oct 17, 2013, at 9:04 AM, Hugo Trippaers  wrote:

> Hey Darren,
> 
> I'm having a look at the branch. Takes some time so i will get back to you 
> when i have something.
> 
> Did you run the bvt test suite on this branch already?
> 
> Cheers,
> 
> Hugo
> 
> On Oct 16, 2013, at 6:59 PM, Darren Shepherd  
> wrote:
> 
>> I need as many people as possible to review this branch.  I'm still
>> testing it out, but I wanted to get as many eyes on it as possible.
>> This is a huge cross cutting change.  This branch is the changes to
>> use a new Transaction API that will be consistent Spring TX's style so
>> that we can eventually move to it.  You can get a bit more context
>> from 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Database+Transactions
>> 
>> Having spent so much time looking at the transaction management in
>> ACS, I'm well convinced we need to adopt Spring TX as soon as we can.
>> I've found just too many bugs.  It will be a painful transitiion, as
>> you can see from this branch.  It will also be very tricky, but I'll
>> figure it out.
>> 
>> If you are reviewing this branch, use a diff tool that ignores
>> whitespace.  Also if you don't know about "git difftool -d", you
>> should use that.  Just know, its was 10x more tedious and painful for
>> me to make this change then it is for you to review it :)
>> 
>> Darren
> 

[JENKINS] systemvm build jobs

[Hugo Trippaers]

Heya,

The systemvm jobs on master are failing because the netinst iso for 7.0.0 is no 
longer available from the debian mirrors. I've added the images to the 
userContent on the master so we can use the copy-to-slave plugin to get them. 
I'm updating and testing the jobs now.

Cheers,

Hugo

Re: Wiki access

[Hugo Trippaers]

Added edit permissions for Harm Boertien (CCC EU Organizer)

Cheers,

Hugo


On 16 okt. 2013, at 16:28, Hugo Trippaers  wrote:

> Kishan,
> 
> look like you have the permissions already on account kishan. Can you check?
> 
> Cheers,
> 
> Hugo
> 
> 
> On Oct 16, 2013, at 3:45 PM, Kishan Kavala  wrote:
> 
>> Please grant me edit access.
>> Email: kis...@cloud.com
>> 
>> ~kishan
>> 
>>> -Original Message-
>>> From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com]
>>> Sent: Wednesday, 16 October 2013 3:22 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: Wiki access
>>> 
>>> Hi,
>>> 
>>> I do not have the edit permissions. My username is radhikap.
>>> 
>>> Kindly provide me with the necessary permissions.
>>> 
>>> Thanks
>>> -Radhika
>>> 
>>> -Original Message-
>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>> Sent: Friday, October 04, 2013 3:26 PM
>>> To: dev
>>> Subject: Re: Wiki access
>>> 
>>> anshulg is in
>>> 
>>> 
>>> On Fri, Oct 4, 2013 at 11:51 AM, Anshul Gangwar
>>> wrote:
>>> 
>>>> need edit permissions , username: anshulg
>>>> 
>>>> Regards,
>>>> Anshul
>>>> 
>>>> On Friday 04 October 2013 02:47 PM, Saksham Srivastava wrote:
>>>>> Please provide me edit permissions, username: saksham
>>>>> 
>>>>> Regards,
>>>>> Saksham
>>>>> 
>>>>> -Original Message-
>>>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>>>> Sent: Friday, October 04, 2013 10:46 AM
>>>>> To: dev@cloudstack.apache.org
>>>>> Subject: Re: Wiki access
>>>>> 
>>>>> Mike, Tuna, Srinivas, Go, done.
>>>>> 
>>>>> On 10/3/13 9:12 PM, "Mike Tutkowski" 
>>>> wrote:
>>>>> 
>>>>>> I seem to need edit access, as well.
>>>>>> 
>>>>>> I'm usually logged in by default, but I believe my username is
>>>>>> mike-tutkowski (else please try mtutkowski).
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> 
>>>>>> On Thu, Oct 3, 2013 at 7:07 PM, Go Chiba  wrote:
>>>>>> 
>>>>>>> Hi Chip,
>>>>>>> 
>>>>>>> Please grant me to edit pages. My id is "gochiba".
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Oct 3, 2013 at 6:01 AM, Chip Childers
>>>>>>> >>>>>>> wrote:
>>>>>>>> Not all committers were easy to find, but those that I did should
>>>>>>>> be
>>>>>>> all
>>>>>>>> set.
>>>>>>>> 
>>>>>>>> So committers / contributors = provide your confluence ID's if
>>>>>>>> you
>>>>>>> can't
>>>>>>>> add / edit pages.  PMC folks - help add them please.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Oct 2, 2013 at 4:48 PM, Chip Childers
>>>>>>> >>>>>>>> wrote:
>>>>>>>>> There were major issues with Spam on the wiki, so infra changed
>>>>>>>>> the permissions.
>>>>>>>>> 
>>>>>>>>> I've just gone and added all PMC members to the space as space
>>>>>>> admins.
>>>>>>>>> That means all PMC members can help deal with this issue (or
>>>>>>>>> at
>>>>>>> least
>>>>>>>>> those that I could find in the wiki user list).
>>>>>>>>> 
>>>>>>>>> I'm going to deal with committers next.  That permission level
>>>>>>> needs to
>>>>>>>>> exclude space admin.  I'm using alena1108 as the example for
>>>>>>> committer
>>>>>>> /
>>>>>>>>> contributor permissions.
>>>>>>>>> 
>>>>>>>>> So if you are not a committer, give your confluence ID in this
>>>>>>> thread
>>>>>>> and
>>>>>>>>> PMC folks can help get them added (make them look like alena's
>>>>>>> perms).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Oct 2, 2013 at 4:35 PM, Chiradeep Vittal <
>>>>>>>>> chiradeep.vit...@citrix.com> wrote:
>>>>>>>>> 
>>>>>>>>>> Apparently, edit access has been revoked for all. Who do we
>>>>>>>>>> contact
>>>>>>> for
>>>>>>>>>> edit permissions?
>>>>>>>>>> 
>>>>>>>>>> TIA
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> 千葉 豪  Go Chiba
>>>>>>> E-mail:go.ch...@gmail.com
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> *Mike Tutkowski*
>>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>>> e: mike.tutkow...@solidfire.com
>>>>>> o: 303.746.7302
>>>>>> Advancing the way the world uses the
>>>>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>>>>> *?*
>>>> 
> 

Re: [JENKINS] systemvm build jobs

[Hugo Trippaers]

Heya,

The systemvm builds are working again on master. The created templates can be 
downloaded from:

http://jenkins.buildacloud.org/job/build-systemvm-master/
http://jenkins.buildacloud.org/job/build-systemvm64-master/


Cheers,

Hugo

On 17 okt. 2013, at 12:30, Hugo Trippaers  wrote:

> Heya,
> 
> The systemvm jobs on master are failing because the netinst iso for 7.0.0 is 
> no longer available from the debian mirrors. I've added the images to the 
> userContent on the master so we can use the copy-to-slave plugin to get them. 
> I'm updating and testing the jobs now.
> 
> Cheers,
> 
> Hugo

Re: [MERGE] txn-refactor

[Hugo Trippaers]

Sent from my iPhone

> On 17 okt. 2013, at 20:12, Darren Shepherd  
> wrote:
> 
>> On 10/17/2013 01:53 AM, Hugo Trippaers wrote:
>> Hey Darren,
>> 
>> Looking through the code it looks like this more an API change than an 
>> actual redesign of the transaction code? I like the resulting code a lot 
>> better than the existing way of doing it. As far as i can see you wrapped 
>> the existing TransactionLegacy way of doing it (txn.start / txn.commit) 
>> inside of the new Transaction functions execute and executeWithException. So 
>> if i understand it correctly, nothing changed in how transactions are 
>> actually handled, except that the code can now be easily changed to use 
>> spring TX.
>> 
> Yes the purpose of this is to introduce a new API that will be compatible 
> with Spring TX.  The internals are all still custom ACS transaction.  This is 
> why I'm comfortable with this change, because nothing changed too much.

Nice, that also makes it a lot easier to review the changes!
> 
> But know I do need to make this change because I found that people were 
> inconsistently using the old API and it was causing problems with the spring 
> modularization branch.  In the spring modularization branch I've moved the 
> AOP logic for the transactions from custom ACS AOP to Spring AOP which has a 
> slightly different semantics.
> 
> Also note I found tons of bugs in the transaction handling while doing this.  
> Having the anonymous class style has made error handling more consistent.  
> But, there a tons of places that people are catching Throwable/Exception 
> where they shouldn't.  That's a different discussion, I need to put together 
> some thoughts on more consistent error handling in ACS.
> 
>> Also you made that changes to a couple of classes to use the new api, but 
>> the majority of the classes still need to be done. It might be nice to 
>> annotate the TransactionLegacy class with @Deprecated so we can easily 
>> identify what needs to be done?
> 
> I updated all of the management non-DAO code.  AWS, Usage and DAOs are still 
> using the old API.  I didn't touch DAOs because its not worth it in my mind.  
> DAOs should move to declarative transaction managment which will mean 
> basically the whole method will be under a transactions.  So I didn't want to 
> convert the code to the anonymous class style, and then when I do declarative 
> transactions go and change all the DAOs again.

Sounds like a solid approach. Works for me.
> 
> I don't know if I want to actually put @Deprecated on TransactionLegacy yet 
> because there are things you can do with it that you can't do in the new API. 
>  Namely, prepared statements and switching databases.

Maybe just mark start() as deprecated then. Would at least put a marker for 
anybody writing new code that they should think again about using it.

> 
>> 
>> The new code is not covered by any new unit test yet? I couldn't check the 
>> cobertura result yet as there are some build and test failures. Can you have 
>> a look at this build : 
>> http://jenkins.buildacloud.org/job/cloudstack-maven-build-with-branch-parameter/3/.
>>   You can kick off that job yourself from jenkins if you like to do the full 
>> test. Didn't do the noredist build test yet as the normal build failed.
>> 
> 
> I can write a unit test that tests the new code.  I started by altering the 
> existing transaction unit test, but then later figured out they don't work 
> and are not being ran as part of the build.  So I just did a bunch of manual 
> testing.

A unit test would be really nice to have for this piece of code. Especially now 
we know there will be changes is this area for some time to come. The DB layer 
is at the core of CloudStack so a test is a real requirement here. I know there 
is a bunch of stuff disabled, we decided long ago to fix those tests when we 
would touch that bit of code, and you just hit the jackpot ;-)

Did you have a look at the build link? The current build for your branch 
appears broken. One test failure and a compile error as far as I can tell.

> 
> Darren

Cheers,

Hugo

Re: Cloudstack collab Hackathons

[Hugo Trippaers]

That's a shame, but I could check if I can setup some teleconference gear. If 
you are interested. Though the time might be a serious bother depending on your 
timezone.

Cheers,

Hugo 

Sent from my iPhone

> On 17 okt. 2013, at 17:39, Marcus Sorensen  wrote:
> 
> I won't be this time.
> 
> On Thu, Oct 17, 2013 at 9:35 AM, Darren Shepherd
>  wrote:
>> Marcus,
>> 
>> Will you be at CCC?  I think it's immensely important and can give plenty of 
>> good reasons, but too lazy to type at the moment.  And I need to do a bit 
>> more analysis on the scope.
>> 
>> Darren
>> 
>>> On Oct 17, 2013, at 8:19 AM, Marcus Sorensen  wrote:
>>> 
>>> I'm not at all against it, I just haven't heard anyone give any reason
>>> as to why.  Keep in mind that we'd essentially be asking anyone who
>>> has written code for the agent to re-do their work (midonet, vxlan,
>>> storage plugins).  My impression is that people just like the 'feel'
>>> of it being in Python, and for good reason, but that ignores the fact
>>> that 1) we've already done the work, and 2) features still require
>>> java knowledge since the agent doesn't do anything the mgmt server
>>> doesn't ask for.  Without anyone explaining why, it just sort of feels
>>> like rearranging deck chairs on a boat with serious leaks going on
>>> below deck. Worse, people brought their own chairs, and we threw them
>>> overboard because they're now the wrong color.
>>> 
>>> On Wed, Oct 16, 2013 at 6:54 PM, Darren Shepherd
>>>  wrote:
>>>> +1 for kvm in python.  I'd like to take it a step further.  I'd like to 
>>>> create a framework for adding compute and storage with python drivers. The 
>>>> first implementation should just happen to be libvirt/kvm.  So yeah, I'll 
>>>> be interested in this.  I'll be landing around 10am so don't know what 
>>>> time I'll get to the hackathon.
>>>> 
>>>> Darren
>>>> 
>>>>>>> On Oct 14, 2013, at 9:29 AM, Marcus Sorensen  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> On Mon, Oct 14, 2013 at 8:22 AM, Sebastien Goasguen  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> On Oct 11, 2013, at 4:43 AM, Hugo Trippaers  wrote:
>>>>>>> 
>>>>>>> Hey Guys,
>>>>>>> 
>>>>>>> The CloudStack collaboration conference is right around the corner. The 
>>>>>>> first day of the conference will be dedicated to workshops and a 
>>>>>>> hackathon.
>>>>>>> 
>>>>>>> I'm curious which developers are planning to attend the hackthon and 
>>>>>>> what subjects you are interested in. In Santa Clara we had a short list 
>>>>>>> of some subjects to discuss and some tables and discussions were 
>>>>>>> already prepared in advance. In the upcoming conference we can do the 
>>>>>>> same, so if you have a discussion or project idea that you want to work 
>>>>>>> on at the hackthon let us know with a reply in this thread.
>>>>>>> 
>>>>>>> I'm also curious if there are any aspiring developers that would like 
>>>>>>> to have a sort of introduction into cloudstack development during the 
>>>>>>> hackathon.
>>>>>>> 
>>>>>>> If you have any other ideas, just shout.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Hugo
>>>>>> 
>>>>>> I am adding couple topics that I would like to see:
>>>>>> 
>>>>>> -API interfaces (AWS refactor, GCE, OCCI&CIMI standard): Discuss the 
>>>>>> state of our interfaces, plans for future, needs etc. AWS interface 
>>>>>> might need a refactor, GCE is a new interface, OCCI is a standard and 
>>>>>> Isaac Chiang has developed an interface. We are missing a CIMI interface.
>>>>>> 
>>>>>> -DOCs: We are having lots of talks about docs, they have been split in a 
>>>>>> separate repo, we need to discuss format, release life cycle, format etc.
>>>>>> 
>>>>>> -KVM agent: There has been discussions/wishes to re-write the KVM agent 
>>>>>> in somethin

[JENKINS] Build permission for anonymous users

[Hugo Trippaers]

Heya,

Based on the question by Darren on how to kick-off the builds i've made a 
permission change on the jenkins host. Anonymous users can now start builds, so 
you don't have to have an account to start one of the builds. This makes it 
easier to trigger one of the parameterised builds.

Interesting builds:
 cloudstack-master-with-patch, takes a patchfile as parameter and executes the 
default maven build
 cloudstack-maven-build-with-branch-parameter, takes a branch name as parameter 
and does the entire build on that branch

Cheers,

Hugo 

Re: Wiki access

[Hugo Trippaers]

Hey Kishan,

I've granted you permissions. There apparently is another Kishan with edit 
permission as well, so i got confused.

Cheers,

Hugo

On 18 okt. 2013, at 12:38, Kishan Kavala  wrote:

> Hugo,
> I've checked again. My account doesn't have edit permission.
> 
>> -Original Message-
>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
>> Sent: Wednesday, 16 October 2013 7:59 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: Wiki access
>> 
>> Kishan,
>> 
>> look like you have the permissions already on account kishan. Can you check?
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> 
>> On Oct 16, 2013, at 3:45 PM, Kishan Kavala  wrote:
>> 
>>> Please grant me edit access.
>>> Email: kis...@cloud.com
>>> 
>>> ~kishan
>>> 
>>>> -Original Message-
>>>> From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com]
>>>> Sent: Wednesday, 16 October 2013 3:22 PM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: RE: Wiki access
>>>> 
>>>> Hi,
>>>> 
>>>> I do not have the edit permissions. My username is radhikap.
>>>> 
>>>> Kindly provide me with the necessary permissions.
>>>> 
>>>> Thanks
>>>> -Radhika
>>>> 
>>>> -Original Message-
>>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>>> Sent: Friday, October 04, 2013 3:26 PM
>>>> To: dev
>>>> Subject: Re: Wiki access
>>>> 
>>>> anshulg is in
>>>> 
>>>> 
>>>> On Fri, Oct 4, 2013 at 11:51 AM, Anshul Gangwar
>>>> wrote:
>>>> 
>>>>> need edit permissions , username: anshulg
>>>>> 
>>>>> Regards,
>>>>> Anshul
>>>>> 
>>>>> On Friday 04 October 2013 02:47 PM, Saksham Srivastava wrote:
>>>>>> Please provide me edit permissions, username: saksham
>>>>>> 
>>>>>> Regards,
>>>>>> Saksham
>>>>>> 
>>>>>> -Original Message-
>>>>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>>>>> Sent: Friday, October 04, 2013 10:46 AM
>>>>>> To: dev@cloudstack.apache.org
>>>>>> Subject: Re: Wiki access
>>>>>> 
>>>>>> Mike, Tuna, Srinivas, Go, done.
>>>>>> 
>>>>>> On 10/3/13 9:12 PM, "Mike Tutkowski" 
>>>>> wrote:
>>>>>> 
>>>>>>> I seem to need edit access, as well.
>>>>>>> 
>>>>>>> I'm usually logged in by default, but I believe my username is
>>>>>>> mike-tutkowski (else please try mtutkowski).
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Oct 3, 2013 at 7:07 PM, Go Chiba  wrote:
>>>>>>> 
>>>>>>>> Hi Chip,
>>>>>>>> 
>>>>>>>> Please grant me to edit pages. My id is "gochiba".
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Oct 3, 2013 at 6:01 AM, Chip Childers
>>>>>>>> >>>>>>>> wrote:
>>>>>>>>> Not all committers were easy to find, but those that I did
>>>>>>>>> should be
>>>>>>>> all
>>>>>>>>> set.
>>>>>>>>> 
>>>>>>>>> So committers / contributors = provide your confluence ID's if
>>>>>>>>> you
>>>>>>>> can't
>>>>>>>>> add / edit pages.  PMC folks - help add them please.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Oct 2, 2013 at 4:48 PM, Chip Childers
>>>>>>>> >>>>>>>>> wrote:
>>>>>>>>>> There were major issues with Spam on the wiki, so infra changed
>>>>>>>>>> the permissions.
>>>>>>>>>> 
>>>>>>>>>> I've just gone and added all PMC members to the space as space
>>>>>>>> admins.
>>>>>>>>>> That means all PMC members can help deal with this issue (or
>>>>>>>>>> at
>>>>>>>> least
>>>>>>>>>> those that I could find in the wiki user list).
>>>>>>>>>> 
>>>>>>>>>> I'm going to deal with committers next.  That permission level
>>>>>>>> needs to
>>>>>>>>>> exclude space admin.  I'm using alena1108 as the example for
>>>>>>>> committer
>>>>>>>> /
>>>>>>>>>> contributor permissions.
>>>>>>>>>> 
>>>>>>>>>> So if you are not a committer, give your confluence ID in this
>>>>>>>> thread
>>>>>>>> and
>>>>>>>>>> PMC folks can help get them added (make them look like alena's
>>>>>>>> perms).
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Oct 2, 2013 at 4:35 PM, Chiradeep Vittal <
>>>>>>>>>> chiradeep.vit...@citrix.com> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Apparently, edit access has been revoked for all. Who do we
>>>>>>>>>>> contact
>>>>>>>> for
>>>>>>>>>>> edit permissions?
>>>>>>>>>>> 
>>>>>>>>>>> TIA
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> 千葉 豪  Go Chiba
>>>>>>>> E-mail:go.ch...@gmail.com
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> *Mike Tutkowski*
>>>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>>>> e: mike.tutkow...@solidfire.com
>>>>>>> o: 303.746.7302
>>>>>>> Advancing the way the world uses the
>>>>>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>>>>>> *?*
>>>>> 
> 

[JENKINS] removed cobertura from master build, added new daily build with cobertura

[Hugo Trippaers]

Hey,

The cloudstack-master build that runs on every commit was taking a long time 
because it would also do the code coverage checks by cobertura. I've disabled 
that target to make it a bit faster (from 1:30 to 30 mins), which would give 
faster feedback to the developers if something went wrong. There is still some 
work to be done as the entire master pipeline 
(http://jenkins.buildacloud.org/view/master-pipeline/) takes almost an hour. I 
would like that to go down to < 30 minutes for any commit, but that is a bit 
more work.

I've made a new job cloudstack-master-codecoverage that will do cobertura and 
findbugs on the entire sources (noredist and awsapi included). This job will 
run on a schedule (daily at the moment) to save resources and speed.

Cheers,

Hugo  

Re: [ANNOUNCE] New PMC member: Animesh Chaturvedi

[Hugo Trippaers]

Congrats Animesh!

Cheers,

Hugo

On 21 okt. 2013, at 20:01, Chip Childers  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked
> Animesh Chaturvedi to join the PMC and we are pleased to announce that they
> have accepted.
> 
> Join me in congratulating Animesh!
> 
> -The CloudStack PMC

Re: [MERGE] txn-refactor

[Hugo Trippaers]

+1 

Side note, you're doing some automated code cleanup as well. Pretty nice, but 
did you sync the cleanup settings with the ones Alex posted a while back? We 
wouldn't want conflicting autocleanup settings battling for supremacy. 

Sent from my iPhone

> On 22 okt. 2013, at 06:21, Darren Shepherd  
> wrote:
> 
> I plan to merge this wed morning unless I or others find issues.  
> 
> Darren
> 
>>> On Oct 17, 2013, at 3:05 PM, Darren Shepherd  
>>> wrote:
>>> 
>>> On Thu, Oct 17, 2013 at 12:59 PM, Hugo Trippaers  wrote:
>>> Maybe just mark start() as deprecated then. Would at least put a marker for 
>>> anybody writing new code that they should think again about using it.
>> 
>> Good idea.
>> 
>>> 
>>> A unit test would be really nice to have for this piece of code. Especially 
>>> now we know there will be changes is this area for some time to come. The 
>>> DB layer is at the core of CloudStack so a test is a real requirement here. 
>>> I know there is a bunch of stuff disabled, we decided long ago to fix those 
>>> tests when we would touch that bit of code, and you just hit the jackpot ;-)
>> 
>> I wrote some tests, I'll commit them in a bit.
>> 
>>> Did you have a look at the build link? The current build for your branch 
>>> appears broken. One test failure and a compile error as far as I can tell.
>> 
>> I had no clue that build-with-branch jenkins jobs existed!  That is
>> very useful.  How do I get an account to kick off jobs?  I do feel
>> stupid now looking at the build error.  I had some maven projects
>> disabled, so I forgot to update about 10 different projects.  I'll fix
>> those real quick and commit.
>> 
>> Darren

[MERGE] network-guru-orchestration into master

[Hugo Trippaers]

Hey guys,

This is something i had on my wish list for some time. The current way network 
gurus are handled is that each guru is asked to design a network and will 
decide by itself to either do it or don’t. Most gurus have sane checks on which 
types of networks it can handle, but we have seen issues there in the past.

With these changes the network orchestrator will check the capabilities of a 
guru and based on that ask one or more gurus to design the network. With this 
the power is where is should new, the network orchestrator. 

This also means that new networking plugins with gurus will have an easier 
integration, just list the capabilities. It will also save some database calls 
(once i clean out all canHandle functions) as gurus will have to lookup less to 
decide if they should to their job.

What do you guys think?

Current branch is tested with devcloud in a manual test, so there is more work 
to do there. I wanted to get some opinions while performing more tests.

Cheers,

Hugo

Re: Review Request 14549: Rename net.juniper.contrail to org.apache.cloudstack.network.contrail

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14549/#review27762
---


Hey Pedro,

Nice work, there is some serious effort in getting this all done.

However i'm just a bit concerned by the way the plugin is implemented. You are 
breaking away from some of the established patterns we already have in 
CloudStack. The existing SDN solutions more or less work the same way. They are 
added as a provider, they use an isolation type to determine if the guru should 
take action and they use the network offering model to determine when to take 
action. Also the general way of interacting southbound is through the agent 
system (CloudStack managers/elements and gurus decide what to do, the agent 
implementation decided how to do it). While your plugin seems to be fine from 
the functionality perspective, not using the established patterns will make it 
exceedingly hard to maintain this plugin and to keep supporting it from within 
CloudStack core. Can you explain why you did not use the established patterns?

You are not using the agent system for the interaction southbound, how would 
this plugin work with a cluster of CloudStack management servers? Currently in 
CloudStack the agent is a unique instance in the cluster that will receive 
instructions from the managers, how does this work with this plugin?

The guru is checking for a specific offering that is created by the plugin. I 
agree with Murali here that this is not the best way of doing things. You are 
enforcing choices on the administrator that he might want to make himself. Also 
this will conflict with the new capabilities system i'm putting into place 
where the network orchestrator will check if a certain combination of 
networking types can be supported by the guru. See the 
network-guru-orchestration branch on git for more information on that.

Cheers,

Hugo



plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
<https://reviews.apache.org/r/14549/#comment53940>

Why do you need the vmSpec.getUuid here and not the vm.getUuid which is 
already present. Then you won't have to pass the vmspec.



plugins/network-elements/juniper-contrail/pom.xml
<https://reviews.apache.org/r/14549/#comment53942>

I don't think we want to list organizations here. The only organization is 
Apache Software Foundation.



plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElementImpl.java
<https://reviews.apache.org/r/14549/#comment53945>

Are you actually supporting all these features in the current version of 
the code. I see a lot of code with just debug placeholders. To keep things 
clear for others reading the code you might want to limit your support for 
things that are actually implemented and remove placeholder functions.



plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElementImpl.java
<https://reviews.apache.org/r/14549/#comment53947>

Remove the TODO's if the code is done?



plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ManagementNetworkGuru.java
<https://reviews.apache.org/r/14549/#comment53952>

author tags should not be in apache code.


- Hugo Trippaers


On Oct. 23, 2013, 6:26 p.m., Pedro Marques wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14549/
> ---
> 
> (Updated Oct. 23, 2013, 6:26 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Rename net.juniper.contrail to org.apache.cloudstack.network.contrail.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/Network.java 49f380b 
>   client/pom.xml fd1f13a 
>   client/tomcatconf/commands.properties.in 0296de0 
>   client/tomcatconf/componentContext.xml.in df5b002 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  f16a6f5 
>   plugins/network-elements/juniper-contrail/pom.xml PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/api/command/CreateServiceInstanceCmd.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/api/response/ServiceInstanceResponse.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElement.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-con

Re: OVS integration broken in 4.2 & master

[Hugo Trippaers]

Hey Murali,

This has already been done by Nguyen (tuna), we just need to get his patches 
from the sdnextension branch into master soon.

Cheers,

Hugo


On 30 okt. 2013, at 08:11, Murali Reddy  wrote:

> OVS integration for GRE overlay tunnels is currently broken in both master 
> and 4.2. Till 4.1, Network Manager will loop through all the network elements 
> for NIC prepare and release so, OVS network element had chance to participate 
> in the NIC prepare/release operations. This behaviour in network orchestrator 
> is changed to loop through only network elements that are service providers 
> for the network which is right way to do, but OVS network element is not 
> called due to this. I am planning to fix it by making Ovs network element as 
> service provider for 'Connectivity' service. This is in consistence with 
> design of other SDN controllers integrated in CS. So, to use GRE isolation, 
> additional step is required to create a network offering with 'Ovs' as 
> connectivity service provider. Any concerns with this approach?
> 

Re: [EVENT] CloudStack Collaboration conference is in 3 weeks !! Register Today !!!

[Hugo Trippaers]

Sorry, missed that :D

Cheers,

Hugo
On 30 okt. 2013, at 09:21, Sebastien Goasguen  wrote:

> Hi folks,
> 
> CloudStack collaboration conference Europe is around the corner -three weeks-
> 
> We have put together a great agenda: http://www.cloudstackcollab.org
> And thanks to our sponsors the event is going to be terrific.
> 
> Register today to help us plan things even better.
> 
> Help us get the word out in your social networks, twitter handle is #CCCEU13
> 
> Cheers and see you all in Amsterdam,
> 
> -Sebastien

Re: OVS integration broken in 4.2 & master

[Hugo Trippaers]

We need to rabase it on latest master first.

I’ll see if i can do that cleanly.

Hugo

On 30 okt. 2013, at 09:55, Sebastien Goasguen  wrote:

> 
> On Oct 30, 2013, at 4:47 AM, Hugo Trippaers  wrote:
> 
>> Hey Murali,
>> 
>> This has already been done by Nguyen (tuna), we just need to get his patches 
>> from the sdnextension branch into master soon.
>> 
>> Cheers,
>> 
> 
> Yeah, actually can you start a [merge] thread on this, so it gets in 4.3 
> soon….
> 
>> Hugo
>> 
>> 
>> On 30 okt. 2013, at 08:11, Murali Reddy  wrote:
>> 
>>> OVS integration for GRE overlay tunnels is currently broken in both master 
>>> and 4.2. Till 4.1, Network Manager will loop through all the network 
>>> elements for NIC prepare and release so, OVS network element had chance to 
>>> participate in the NIC prepare/release operations. This behaviour in 
>>> network orchestrator is changed to loop through only network elements that 
>>> are service providers for the network which is right way to do, but OVS 
>>> network element is not called due to this. I am planning to fix it by 
>>> making Ovs network element as service provider for 'Connectivity' service. 
>>> This is in consistence with design of other SDN controllers integrated in 
>>> CS. So, to use GRE isolation, additional step is required to create a 
>>> network offering with 'Ovs' as connectivity service provider. Any concerns 
>>> with this approach?
>>> 
>> 
> 

Re: OVS integration broken in 4.2 & master

[Hugo Trippaers]

We need to rebase it on latest master first.

I’ll see if i can do that cleanly.

On 30 okt. 2013, at 09:55, Sebastien Goasguen  wrote:

> 
> On Oct 30, 2013, at 4:47 AM, Hugo Trippaers  wrote:
> 
>> Hey Murali,
>> 
>> This has already been done by Nguyen (tuna), we just need to get his patches 
>> from the sdnextension branch into master soon.
>> 
>> Cheers,
>> 
> 
> Yeah, actually can you start a [merge] thread on this, so it gets in 4.3 
> soon….
> 
>> Hugo
>> 
>> 
>> On 30 okt. 2013, at 08:11, Murali Reddy  wrote:
>> 
>>> OVS integration for GRE overlay tunnels is currently broken in both master 
>>> and 4.2. Till 4.1, Network Manager will loop through all the network 
>>> elements for NIC prepare and release so, OVS network element had chance to 
>>> participate in the NIC prepare/release operations. This behaviour in 
>>> network orchestrator is changed to loop through only network elements that 
>>> are service providers for the network which is right way to do, but OVS 
>>> network element is not called due to this. I am planning to fix it by 
>>> making Ovs network element as service provider for 'Connectivity' service. 
>>> This is in consistence with design of other SDN controllers integrated in 
>>> CS. So, to use GRE isolation, additional step is required to create a 
>>> network offering with 'Ovs' as connectivity service provider. Any concerns 
>>> with this approach?
>>> 
>> 
> 

Re: Wiki access

[Hugo Trippaers]

Done, added sadhu

Cheers,

Hugo 

On 30 okt. 2013, at 11:21, Suresh Sadhu  wrote:

> Please provide edit access:
> User name :sadhu
> 
> Regards
> sadhu
> 
> -Original Message-
> From: Parth Jagirdar [mailto:parth.jagir...@citrix.com] 
> Sent: 16 October 2013 00:28
> To: dev@cloudstack.apache.org
> Subject: RE: Wiki access
> 
> I need edit access too;
> 
> Username: parth
> 
> Thanks,
> .. Parth
> 
> 
> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org] 
> Sent: Tuesday, October 15, 2013 3:13 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Wiki access
> 
> On Tue, Oct 15, 2013 at 09:58:22AM +, Donal Lafferty wrote:
>> May I get access to edit pages as well?
>> 
>> username: dlafferty
> Done.
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

Re: [MERGE] network-guru-orchestration into master

[Hugo Trippaers]

On 30 okt. 2013, at 02:09, Darren Shepherd  wrote:

> First, I like the idea of consolidating logic.  I could see also
> implementing this as just an abstract base class that handles this
> common logic.  I'm not sure which approach I prefer.  Exactly what is
> the problem that you are trying to solve?  Without more details, I'd
> lean towards implementing this logic in an abstract base class that
> all NetworkGurus can choose to extend.
> 

Not as much a problem as a design choice. It is my intention to use 
capabilities to select the NetworkGuru instead of asking each network guru in 
turn if it wants to design the network. The idea here is that new network gurus 
only need to supply a list of capabilities to be integrated into cloudstack. 
Like i can handle isolation type X in advanced networks for traffic type Guest. 
The network orchestrator can make an informed decision on who to give the task 
(and warn if there is more than one capable)


> Darren
> 
> On Tue, Oct 29, 2013 at 9:42 AM, Hugo Trippaers  wrote:
>> Hey guys,
>> 
>> This is something i had on my wish list for some time. The current way 
>> network gurus are handled is that each guru is asked to design a network and 
>> will decide by itself to either do it or don’t. Most gurus have sane checks 
>> on which types of networks it can handle, but we have seen issues there in 
>> the past.
>> 
>> With these changes the network orchestrator will check the capabilities of a 
>> guru and based on that ask one or more gurus to design the network. With 
>> this the power is where is should new, the network orchestrator.
>> 
>> This also means that new networking plugins with gurus will have an easier 
>> integration, just list the capabilities. It will also save some database 
>> calls (once i clean out all canHandle functions) as gurus will have to 
>> lookup less to decide if they should to their job.
>> 
>> What do you guys think?
>> 
>> Current branch is tested with devcloud in a manual test, so there is more 
>> work to do there. I wanted to get some opinions while performing more tests.
>> 
>> Cheers,
>> 
>> Hugo

Re: [MERGE] network-guru-orchestration into master

[Hugo Trippaers]

On 30 okt. 2013, at 19:08, Darren Shepherd  wrote:

> I definitely don't want the setup to be done at a zone level.
Pretty strong words, i’m considering this a veto on any further discussion 
around this topic?

> Specifically, I'd like to get rid of the notion of basic and advanced
> zones which would mean that you could be mixing gurus in the same
> zone.  If anything, I'd say the simplest would be to just specify the
> Guru in the network offering.
> 
> I like the work that Hugo has done, but the implications of that
> change are 2 things.  First, we only want one guru to match.  If that
> is the case, then lets change the NetworkOrchestrator.setupNetwork()
> to just return one network.  I have a hard time understanding why you
> would want to return two or more.

Lets say that is a historical left over, there is no reason to return more than 
one network. The current method signature is still there, because nobody 
changed it yet. Feel free to submit a patch.

>  Even if the guru created two
> networks internally, only one should be return to the caller.  There's
> not a good way to invoke setupNetwork() and handle cases where more
> than one network comes back.

> 
> Second, we are saying the only way to choose a guru is based on
> networkType/trafficType/guestType/isolationmethods.  I think the core
> logic should be more flexible than that.  We can first check those 4
> items, and then if we find more than one guru that matches, use the
> best one (before what I said about adding canHandle to the interface).
> But the check shouldn't be only those four criteria.  Hugo's change
> does not strictly enforce that, but it is essentially implied.
Thats how it is currenty implemented, with the exception that we don’t know 
which is the best one. So we loop through the remaining gurus and the first one 
that responds with a network wins. It would be very hard to give a score to a 
guru.


> 
> After saying all that, if we just put the Guru in the network
> offering.  Would that work for everything?  That would be a really
> simple and explicit way to configure this all.

We need it to link to the physical network. The physical network is configured 
for a particular technology, usually out side cloudstack. Like configuring your 
hypervisors for Midonet or VMware NSX. You should not be able to mix different 
gurus on a physical network. The gurus are there to deal with the low-level 
network creation stuff. If anything, the gurus should be split into two 
different things. The first that deals with the isolation method (L2 
networking) set on the physical network and the second that deals with the L3 
stuff like how to assign IPs and such.

> 
> Darren

Hugo
> 
> 
> On Wed, Oct 30, 2013 at 10:31 AM, Alex Huang  wrote:
>> I agree with Hugo that the current way of ask NetworkGuru to decide itself 
>> is not desirable.  It makes absolute sense to change that but I wonder why 
>> do it through capabilities.  Why not just ask the system admin to choose 
>> when they setup the zone?   When I originally designed NetworkGuru, I 
>> figured there's a difference in the L2-L3 technology deployed and the 
>> network services (L4-L7) provided on top of it.  So I separated out 
>> NetworkGuru and NetworkElement.  However, I didn't think it's likely that 
>> there would be two or three different type of L2-L3 technologies deployed 
>> within the same zone.  I figured we can leave it to the system admin to just 
>> pick which set of NetworkGurus should be deployed in a certain zone and 
>> that's good enough.
>> 
>> I do think there should be more tie in between the NetworkElements and 
>> NetworkGurus.  For example, whether a certain NetworkElement can work with 
>> the L2-L3 technology deployed.
>> 
>> --Alex
>> 
>>> -Original Message-
>>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>>> Sent: Wednesday, October 30, 2013 10:11 AM
>>> To: dev@cloudstack.apache.org; Alex Huang; Chiradeep Vittal
>>> Subject: Re: [MERGE] network-guru-orchestration into master
>>> 
>>> I don't particular like saying that picking a Guru is based solely on that 
>>> criteria.
>>> It should be much looser than that.  If the problem you are trying to fix 
>>> is two
>>> Gurus implement the same network then we need to set back a bit.  I'd like
>>> Alex or Chiradeep to weigh in on this.  Currently setupNetwork returns a 
>>> list
>>> of networks that were created.  I've looked at the code and every single
>>> invocation to setupNetwork expects (and mostly hard code) a response of
>>> one network.
>>> 
&g

Reverting commit 5bcd8280fdd1e9039a6bf6c4c4fd43b8b49f938e

[Hugo Trippaers]

Hey Anthony,

I’ve reverted your commit with id 5bcd8280fdd1e9039a6bf6c4c4fd43b8b49f938e. It 
breaks packaging because the plugins are no longer actually called when you 
moved them to pluginManagement.

I know about the m2eclipse errors, but we need those maven plugins to do their 
work during the packaging phase even though they are not “supported” by eclipse 
m2e.

Cheers,

Hugo

RE: [ACS4.2.1] CLOUDSTACK-2804

[Hugo Trippaers]

Thanks for the reminder, I've closed the issue

From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
Sent: Thursday, October 31, 2013 6:27 AM
To: CloudStack Dev; Hugo Trippaers
Subject: [ACS4.2.1] CLOUDSTACK-2804

Hi Hugo,

   There are some commits in 
CLOUDSTACK-2804<https://issues.apache.org/jira/browse/CLOUDSTACK-2804>, will 
you know if this is fixed ?

-abhi

Re: [MERGE] network-guru-orchestration into master

[Hugo Trippaers]

On 31 okt. 2013, at 04:34, Marcus Sorensen  wrote:

> Here's a scenario... Lets say we currently have a zone deployed with Vlan
> isolation. There's nothing stopping us from running a vxlan isolation on
> the same hosts, even on the same physical interface. This is actually done
> in devcloud-kvm where public and mgmt traffic are selected by traffic label
> (which are tagged vlans), and guest traffic is handled by vxlan.
> 
> If one wanted to deprecate Vlan in favor of vxlan without a big zone
> shufflr it would be simple if isolation method were a property of network
> offering. I imagine other isolation offerings could also be deployed in
> tandem, even if it required multiple physical interfaces in the host.

Currently the system we have in place is indeed capable of running different 
isolation types on a host, it uses the physical network concept in cloudstack 
to determine which isolation type to use. This is mainly because the physical 
network also defines which tag or network interface label to use on the 
hypervisors.

I understand the case that it might be possible to combine different isolation 
types on physical networks, like the case you describe with vlan and vxlan. 
However in other cases it should not happen, like when nicira nvp is used which 
takes exclusive control of a traffic label or bridge on the hypervisor. As far 
as i understood the contrail implementation it actually takes control of the 
entire networking of a hypervisor, so its exclusive with any other isolation 
provider.

Within the database and (most of) the code it is already possible to set 
multiple isolation types on a physical network. That gives the admin the 
ability to link a certain physical interface/traffic label or bridge to a set 
of isolation types. For example cloudbr0 with NONE, VLAN and VXLAN and cloudbr1 
with STT. The offering system can be used to indicate which isolation provider 
to use for which particular virtual network.

Cheers,

Hugo


> On Wed, Oct 30, 2013 at 11:36 AM, Pedro Roque Marques
>  wrote:
>> 
>> Why ? That seems to me the most obvious way to do it.
>> There are different networking solutions: e.g. VLANs and overlays such as
> OpenContrail that assume an L3 switching topology.  For a deployment one
> would tend to choose a solution associated with the physical network.
> 
> Sure that would be simple.  The problem is that Zone also implies
> other things.  Secondary/Primary storage for example.  Zone puts other
> limitations on things.  So by tying networking to a zone you can get
> into the situation where somebody has a CloudStack installation, and
> they want to add OpenContrail.  If we tie it to the zone, that may
> mean that in order for them to use OpenContrail they may need to get
> another NFS secondary storage, primary storage, compute nodes, etc and
> then copy all the templates from one zone to another, etc, etc.
> 
> So currently you can't have Basic and Advanced networking in the same
> zone.  I think it should be possible.  Imagine I had a smaller
> dev/test cloud.  Today if I want basic and advance networking (because
> those are two distinict work loads), I have to have servers dedicated
> to each type.  So 10 for basic, 10 or advanced.  Now the networking
> under the hood for basic and advance can mix quite easily but just
> because we decided to implement it as it is today, I'm suddenly forced
> to managed two pools of physical resources, when it would have been
> must easier and more cost effective to have one pool.
> 
> I think this is general thing that should change with CloudStack over
> time.  Zone and Pod should not be so closely tied to network concepts.
> CloudStack should be capable of being looser for people who want more
> hybrid work loads.  We too easily say that a service provider is just
> going to choose one or the other so why support mixed configurations.
> But there are more people that could be using CloudStack but are
> turned off by the strict models and concepts that CloudStack enforces.
> I have to say I was one of those people.  CloudStack forced me to
> manage my infrastructure in a certain way that I didn't particularly
> care for.
> 
> Darren

Re: [MERGE] network-guru-orchestration into master

[Hugo Trippaers]

On 31 okt. 2013, at 03:48, Darren Shepherd  wrote:

> Its important to remember that the definition of a Network in
> CloudStack is quite purposefully very loose.  A network in the
> simplest terms is just a group of VMs.  A guru creates and manages
> that network.  A network is not strictly defined as a union of
> traffictype/isolationtype/networktype/guesttype.  So, for example,
> there need not be a 1-to-1 mapping between Guru and IsolationType.
> You should be able to have multiple gurus per any context.  That's the
> theory and vision.

I think that vision was put down somewhere before we entered the era of 
software defined networking. At the moment it is simply not true as long as the 
guru is responsible for creating the overlay networks there is a 1 on 1 
relation with the guru and the supported isolation types in several cases.

> 
> Now the reality is that the current selection logic of the guru in the
> orchestrator doesn't fully back up that vision because the selection
> logic too easily allows two Guru's to implement the same network.
> 
> So I think the current behavior of setupNetwork is flawed.  This
> change, I feel, muddies to a certain degree the definition of a
> network in CloudStack and attempts to say a network is strict union of
> traffic/isolation/network/guest-type.  If we merge this change, does
> it hurt anything?  No, its more just conceptual disagreement.  When I
> get to the point that I feel setupNetwork is limiting what I want to
> do, I'll propose a change.  Right now, I just accept that its not
> right in my mind.

I’ve fixed the definition of setupNetwork so the function returns a single 
network when called. This was already the effective behavior, but now its put 
down in code as well. I’ll push that change to the branch today.


> 
> So I'd have to say I'm neutral on this change.  I don't care too much
> either way as I think down the line this all needs to change.

Let’s find a moment to sit down at CCCEU and discuss this further. I have some 
ideas of where i want to go with the networking bit as well and it would be 
nice if we are more or less on the same page before we start working on it. 
Saying that you don’t care because you think its going to change it anyway 
isn’t really the best way to approach this.

> 
> Darren
> 
> On Wed, Oct 30, 2013 at 11:36 AM, Pedro Roque Marques
>  wrote:
>> 
>> On Oct 30, 2013, at 11:08 AM, Darren Shepherd  
>> wrote:
>> 
>>> I definitely don't want the setup to be done at a zone level.
>> 
>> Why ? That seems to me the most obvious way to do it.
>> There are different networking solutions: e.g. VLANs and overlays such as 
>> OpenContrail that assume an L3 switching topology.  For a deployment one 
>> would tend to choose a solution associated with the physical network.
>> 
>>> Specifically, I'd like to get rid of the notion of basic and advanced
>>> zones which would mean that you could be mixing gurus in the same
>>> zone.  If anything, I'd say the simplest would be to just specify the
>>> Guru in the network offering.
>> 
>> Basic and advanced zones is rather unhelpful, i agree. But you still can't 
>> Mix Guru's unless they can interoperate... The way for them to interop (i.e. 
>> minimum common denominator) is to connect at L3 in an router between zones.
>> 
>>> 
>>> I like the work that Hugo has done, but the implications of that
>>> change are 2 things.  First, we only want one guru to match.  If that
>>> is the case, then lets change the NetworkOrchestrator.setupNetwork()
>>> to just return one network.  I have a hard time understanding why you
>>> would want to return two or more.  Even if the guru created two
>>> networks internally, only one should be return to the caller.  There's
>>> not a good way to invoke setupNetwork() and handle cases where more
>>> than one network comes back.
>>> 
>>> Second, we are saying the only way to choose a guru is based on
>>> networkType/trafficType/guestType/isolationmethods.  I think the core
>>> logic should be more flexible than that.  We can first check those 4
>>> items, and then if we find more than one guru that matches, use the
>>> best one (before what I said about adding canHandle to the interface).
>>> But the check shouldn't be only those four criteria.  Hugo's change
>>> does not strictly enforce that, but it is essentially implied.
>>> 
>>> After saying all that, if we just put the Guru in the network
>>> offering.  Would that work for everything?  That would be a really
>>> simple an

note to devcloud users on db.properties.override

[Hugo Trippaers]

Heya,

With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the 
loading of the db.properties file, however this also affected the 
DatabaseCreator used by the deploydb procedure to refresh the database. 
Effectively the db.properies.override is ignored at the moment and the 
db.proeprties file in utils/conf/ will be used instead. We need to come up with 
a nice solution for this in the near future, but in the meantime make any 
custom setting there. Just don’t commit them ;-)

Cheers,

Hugo

Re: note to devcloud users on db.properties.override

[Hugo Trippaers]

On 31 okt. 2013, at 17:27, Darren Shepherd  wrote:

> This is fixed now.  Sorry about that.  I really do go through extra
> length to test my changes.  I'm finding it difficult to ensure quality
> because there is so much variation.  You have to test everything in so
> many contexts.  It shouldn't be like that I hope to help reduced the
> amount of variation in this platform.  This was part of why I made the
> db.properties change to begin with.  I wanted to change MacAddress to
> read from db.properties, but then I found out that that properties
> file is loaded in probably 10 different places in all slightly
> different ways.  Some places would decrypt, some wouldn't, some
> ignored if the file was not found, some would just throw a NPE.  So I
> consolidated all that code.

Nice! I like the consolidation :-)

Cheers,

Hugo

> 
> Darren
> 
> 
> On Thu, Oct 31, 2013 at 9:07 AM, Darren Shepherd
>  wrote:
>> Ugh, I see what I did now.  When I tested that code I changed the code
>> I didn't do a "mvn install" before running "mvn ... deploydb."  That's
>> annoying, now I want to figure out why maven doesn't pickup changes
>> unless I do an install.  So I effectively tested with the old code.
>> 
>> Darren
>> 
>> On Thu, Oct 31, 2013 at 8:52 AM, Darren Shepherd
>>  wrote:
>>> I'll fix that.  Gimme ten mintues.  I specifically looked at that code
>>> and thought I didn't change the behavior, but I guess I screwed it up.
>>> 
>>> Just a general comment.  There's too many ways to do the same thing in
>>> CloudStack.  Especially the database.  The way databases are setup for
>>> developers shouldn't be so different from production.  The way we
>>> manage the DB at the moment is so problematic in my mind.
>>> 
>>> Darren
>>> 
>>> 
>>> On Thu, Oct 31, 2013 at 7:18 AM, Hugo Trippaers  wrote:
>>>> Heya,
>>>> 
>>>> With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the 
>>>> loading of the db.properties file, however this also affected the 
>>>> DatabaseCreator used by the deploydb procedure to refresh the database. 
>>>> Effectively the db.properies.override is ignored at the moment and the 
>>>> db.proeprties file in utils/conf/ will be used instead. We need to come up 
>>>> with a nice solution for this in the near future, but in the meantime make 
>>>> any custom setting there. Just don’t commit them ;-)
>>>> 
>>>> Cheers,
>>>> 
>>>> Hugo

Re: Review Request 14549: Rename net.juniper.contrail to org.apache.cloudstack.network.contrail

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14549/#review27960
---


Just had a nice chat with Pedro on Skype. We ran through all the review remarks 
i posted and we agreed to a couple of minor changes and Pedro will submit an 
updated diff. 

I'm ok with the patch status as is and we will leave the concerns on the guru 
selection for a other patch. So I intend to "ship it" the patch when the new 
diff is in.

- Hugo Trippaers


On Oct. 31, 2013, 8:46 p.m., Pedro Marques wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14549/
> ---
> 
> (Updated Oct. 31, 2013, 8:46 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Rename net.juniper.contrail to org.apache.cloudstack.network.contrail.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/Network.java 49f380b 
>   client/pom.xml fd1f13a 
>   client/tomcatconf/commands.properties.in 0296de0 
>   client/tomcatconf/componentContext.xml.in df5b002 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  f16a6f5 
>   plugins/network-elements/juniper-contrail/pom.xml PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/api/command/CreateServiceInstanceCmd.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/api/response/ServiceInstanceResponse.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElement.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElementImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailGuru.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManager.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManagerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/DBSyncGeneric.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/EventUtils.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ManagementNetworkGuru.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ModelDatabase.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerDBSync.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerDBSyncImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerEventHandler.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerEventHandlerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceManager.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceManagerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceVirtualMachine.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/FloatingIpModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/FloatingIpPoolModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/InstanceIpModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelController.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/s

Re: Review Request 14549: Rename net.juniper.contrail to org.apache.cloudstack.network.contrail

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14549/#review28016
---

Ship it!


commit 6b5fab2f5cd939f64b5c9c1ee8d87ca8b6f6514d
Author: Pedro Marques 
Date:   Thu Oct 31 17:16:58 2013 -0700

OpenContrail network plugin

Signed-off-by: Hugo Trippaers 


- Hugo Trippaers


On Nov. 1, 2013, 12:19 a.m., Pedro Marques wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14549/
> ---
> 
> (Updated Nov. 1, 2013, 12:19 a.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Rename net.juniper.contrail to org.apache.cloudstack.network.contrail.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/Network.java 49f380b 
>   client/pom.xml 3e08a9a 
>   client/tomcatconf/commands.properties.in e92596c 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  3df28ed 
>   plugins/network-elements/juniper-contrail/pom.xml PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/api/command/CreateServiceInstanceCmd.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/api/response/ServiceInstanceResponse.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElement.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailElementImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailGuru.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManager.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManagerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/DBSyncGeneric.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/EventUtils.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ManagementNetworkGuru.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ModelDatabase.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerDBSync.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerDBSyncImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerEventHandler.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerEventHandlerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceManager.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceManagerImpl.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServiceVirtualMachine.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/FloatingIpModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/FloatingIpPoolModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/InstanceIpModel.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelController.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObject.java
>  PRE-CREATION 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObjectBase.java
>  PRE-CREATION 

Re: [ANNOUNCE] New Committer: Nguyen Anh Tu

[Hugo Trippaers]

Congrats Tuna :-)


Cheers,

Hugo

On 4 nov. 2013, at 11:12, Daan Hoogland  wrote:

> welcome Nguyen.
> 
> On Mon, Nov 4, 2013 at 10:02 AM, Sebastien Goasguen  wrote:
>> Well done Nguyen !
>> 
>> -Sebastien
>> 
>> On 4 Nov 2013, at 09:33, Prasanna Santhanam  wrote:
>> 
>>> The Project Management Committee (PMC) for Apache CloudStack has asked 
>>> Nguyen
>>> Anh Tu to become a committer and we are pleased to announce that they have
>>> accepted.
>>> 
>>> Being a committer allows many contributors to contribute more autonomously. 
>>> For
>>> developers, it makes it easier to submit changes and eliminates the need to
>>> have contributions reviewed via the patch submission process. Whether
>>> contributions are development-related or otherwise, it is a recognition of a
>>> contributor's participation in the project and commitment to the project and
>>> the Apache Way.
>>> 
>>> Please join me in congratulating Nguyen!
>>> 
>>> --
>>> Prasanna.,
>>> on behalf of the Apache CloudStack PMC
>>> 
>>> 
>>> Powered by BigRock.com
>>> 

checkstyle

[Hugo Trippaers]

Hey,

Just added a very basic checkstyle configuration to maven. The configuration 
file is in parents/checkstyle and it checks just a few very basic things, like 
trailing whitespace and tabs where there should be spaces.

I’ve enabled it for a single plugin to just the impact on build time and the 
amount of generated errors. Quite considerable, but i hope other parts of the 
code are better ;-)

You can enable check style for your plugin by adding the following to your 
build plugins config in maven:

  
org.apache.maven.plugins
maven-checkstyle-plugin
${cs.checkstyle.version}

  
org.apache.cloudstack
checkstyle
0.0.1-SNAPSHOT
  


  
process-sources

  check

  


  true
  tooling/checkstyle.xml
  true
  true
  ${project.basedir}
  **\/*.java,**\/*.xml,**\/*.ini,**\/*.sh,**\/*.bat
  **\/target\/,**\/bin\/

  


For now its voluntary, but i would like your opinion on making this a mandatory 
part of the build process. Meaning a compile with not succeed when check style 
reports errors.

Cheers,

Hugo

Re: checkstyle

[Hugo Trippaers]

Hey John,

That would be my idea.

Make it mandatory for new (maven) projects coming into the code base and slowly 
start working on fixing the existing projects.  The current checkstyle setting 
is very relaxed, just a few basic checks. Stuff that we could technically fix 
with a few well written regular expressions even.  Over time we can start 
implementing parts of our code style in the checkstyle config, but that is long 
term planning.

Cheers,

Hugo

On 4 nov. 2013, at 16:28, John Kinsella  wrote:

> I think it'd be fairly painful to make it mandatory - maybe see if we can set 
> that as a goal for 6 months out?
> 
> On Nov 4, 2013, at 6:29 AM, Hugo Trippaers 
> mailto:h...@trippaers.nl>>
> wrote:
> 
> Hey,
> 
> Just added a very basic checkstyle configuration to maven. The configuration 
> file is in parents/checkstyle and it checks just a few very basic things, 
> like trailing whitespace and tabs where there should be spaces.
> 
> I’ve enabled it for a single plugin to just the impact on build time and the 
> amount of generated errors. Quite considerable, but i hope other parts of the 
> code are better ;-)
> 
> You can enable check style for your plugin by adding the following to your 
> build plugins config in maven:
> 
> 
>   org.apache.maven.plugins
>   maven-checkstyle-plugin
>   ${cs.checkstyle.version}
>   
> 
>   org.apache.cloudstack
>   checkstyle
>   0.0.1-SNAPSHOT
> 
>   
>   
> 
>   process-sources
>   
> check
>   
> 
>   
>   
> true
> tooling/checkstyle.xml
> true
> true
> ${project.basedir}
> **\/*.java,**\/*.xml,**\/*.ini,**\/*.sh,**\/*.bat
> **\/target\/,**\/bin\/
>   
> 
> 
> 
> For now its voluntary, but i would like your opinion on making this a 
> mandatory part of the build process. Meaning a compile with not succeed when 
> check style reports errors.
> 
> Cheers,
> 
> Hugo
> 
> Stratosec<http://stratosec.co/> - Compliance as a Service
> o: 415.315.9385
> @johnlkinsella<http://twitter.com/johnlkinsella>
> 

Coverity static code analysis

[Hugo Trippaers]

Hey all,

At CloudOpen in Edinburgh i joined a presentation on Coverity, a static code 
analysis tool. Some of you may have heard of it already, it is famous for doing 
the code analysis on the Linux kernel for quite some years already. They added  
support for the java language quite a while back. The presenter dropped by our 
CloudStack booth and we had a nice chat on static code analysis. 

You might have guessed the next step, i added CloudStack to the Coverity 
scanning service at scan.coverity.com: http://scan.coverity.com/projects/943.
 - 1.044.609 lines of code
 - 6.70 defect density
 - 6997 outstanding defects

The reasoning is obviously that anything that will help us improve quality 
should be considered. However just adding the CloudStack sources to the scan 
isn’t going to solve anything. For that we all need to pitch in an help out 
with getting the scan results triaged, assigned and fixed. So signup en-masse 
and go fix ;-)

Note to new and aspiring CloudStack developers, don’t know where to start but 
you want to help out? This is a great way to get to know the code and the 
community. Have a look at one of the open items on Coverity, fix it and submit 
it for review at reviews.apache.org. 

Cheers,

Hugo

Re: checkstyle

[Hugo Trippaers]

The search-fu is weak in this one..

Did you ever get to commit that file Donal? I’d be very much interested :-)

Cheers,

Hugo

On 4 nov. 2013, at 17:48, Donal Lafferty  wrote:

> How does it compare to previous versions for CloudStack?  E.g. 
> http://markmail.org/message/yz6qa2v47cdeic4d
> 
> 
>> -Original Message-
>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
>> Sent: 04 November 2013 14:30
>> To: dev@cloudstack.apache.org
>> Subject: checkstyle
>> 
>> Hey,
>> 
>> Just added a very basic checkstyle configuration to maven. The configuration
>> file is in parents/checkstyle and it checks just a few very basic things, 
>> like
>> trailing whitespace and tabs where there should be spaces.
>> 
>> I've enabled it for a single plugin to just the impact on build time and the
>> amount of generated errors. Quite considerable, but i hope other parts of
>> the code are better ;-)
>> 
>> You can enable check style for your plugin by adding the following to your
>> build plugins config in maven:
>> 
>>  
>>org.apache.maven.plugins
>>maven-checkstyle-plugin
>>${cs.checkstyle.version}
>>
>>  
>>org.apache.cloudstack
>>checkstyle
>>0.0.1-SNAPSHOT
>>  
>>
>>
>>  
>>process-sources
>>
>>  check
>>
>>  
>>
>>
>>  true
>>  tooling/checkstyle.xml
>>  true
>>  true
>>  ${project.basedir}
>> 
>> **\/*.java,**\/*.xml,**\/*.ini,**\/*.sh,**\/*.bat
>>  **\/target\/,**\/bin\/
>>
>>  
>> 
>> 
>> For now its voluntary, but i would like your opinion on making this a
>> mandatory part of the build process. Meaning a compile with not succeed
>> when check style reports errors.
>> 
>> Cheers,
>> 
>> Hugo

Re: Wiki access

[Hugo Trippaers]

I just checked and your permissions were already setup: Sowmya Krishnan 
(sowmyak)

Cheers,

Hugo


On 5 nov. 2013, at 05:27, Sowmya Krishnan  wrote:

> sowmyak

[JENKINS] Preparing for the 4.3 branch

[Hugo Trippaers]

I’ve setup all the jenkins jobs for the release branch and a pipeline view.

When the branch is cut we only need to enable the jobs.

http://jenkins.buildacloud.org/view/4.3/
http://jenkins.buildacloud.org/view/cloudstack-4.3-pipeline/


Cheers,

Hugo

Re: Review Request 15264: Fix for 1125389 RV: Bad use of return value

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15264/#review28264
---

Ship it!


commit 56070c644b026003b155bdb69b356a286e122a46
Author: wilderrodrigues 
Date:   Wed Nov 6 14:18:31 2013 +0100

Fix for 1125389 RV: Bad use of return value - make sure the replace call is 
done after replaceAll and the correct value is returned

Signed-off-by: Hugo Trippaers 


- Hugo Trippaers


On Nov. 6, 2013, 2:08 p.m., Wilder Rodrigues wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15264/
> ---
> 
> (Updated Nov. 6, 2013, 2:08 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Bugs: 1125389
> https://issues.apache.org/jira/browse/1125389
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> In 
> org.?apache.?cloudstack.?network.?contrail.?management.?ContrailManagerImpl.?getPhysicalNetworkName(com.?cloud.?network.?dao.?PhysicalNetworkVO):
>  The return value of this method should be checked. (From FindBugs™ 
> description) (CWE-440)
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ContrailManagerImpl.java
>  ae9bba9 
> 
> Diff: https://reviews.apache.org/r/15264/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Wilder Rodrigues
> 
>

Re: Review Request 15298: Fix for issues on Coverity related to IDs 1125383 [82, 80, 79, 78, 77, 76, 75, 74]

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15298/#review28357
---



plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObject.java
<https://reviews.apache.org/r/15298/#comment55184>

Can you replace the tabs with spaces please?


- Hugo Trippaers


On Nov. 7, 2013, 7:24 a.m., Wilder Rodrigues wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15298/
> ---
> 
> (Updated Nov. 7, 2013, 7:24 a.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Bugs: 1125374, 1125375, 1125376, 1125377, 1125378, 1125379, 1125380, 1125382, 
> and 1125383
> https://issues.apache.org/jira/browse/1125374
> https://issues.apache.org/jira/browse/1125375
> https://issues.apache.org/jira/browse/1125376
> https://issues.apache.org/jira/browse/1125377
> https://issues.apache.org/jira/browse/1125378
> https://issues.apache.org/jira/browse/1125379
> https://issues.apache.org/jira/browse/1125380
> https://issues.apache.org/jira/browse/1125382
> https://issues.apache.org/jira/browse/1125383
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Several bugs reported on Coverity have been fixed on this path. The ID are: 
> Fix for issues on Coverity related to IDs 1125383, 1125382, 1125380, 1125379, 
> 1125378, 1125377, 1125376, 1125375, 1125374.
> 
> Those bugs are related to classes not implementing Serializable, nox 
> overriding the equals and/or hashCode methods and with empty finalize method.
> 
> For the bug 1125376, although it has been submitted in a previous patch, 
> there was a typo on the return key word, which contained a "s".
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerDBSyncImpl.java
>  8cb4e8d 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerEventHandlerImpl.java
>  455e601 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObject.java
>  71d28ac 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObjectBase.java
>  f22c7c5 
> 
> Diff: https://reviews.apache.org/r/15298/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Wilder Rodrigues
> 
>

Re: Review Request 15298: Fix for issues on Coverity related to IDs cv_1125383 [82, 80, 79, 78, 77, 76, 75, 74]

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15298/#review28358
---

Ship it!


commit c06d8a750c75f500fa29479c0aec58eb7fcea2ba
Author: wilderrodrigues 
Date:   Thu Nov 7 09:22:43 2013 +0100

Fix for issues on Coverity related to IDs cv_1125383, cv_1125382, 
cv_1125380, cv_1125379, cv_1125378, cv_1125377, cv_1125376, cv_1125375, 
cv_1125374.

Those bugs are related to classes not implementing Serializable, nox 
overriding the equals and/or hashCode methods and with empty finalize method.

Signed-off-by: Hugo Trippaers 


- Hugo Trippaers


On Nov. 7, 2013, 8:25 a.m., Wilder Rodrigues wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15298/
> ---
> 
> (Updated Nov. 7, 2013, 8:25 a.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Several bugs reported on Coverity have been fixed on this path. The ID are: 
> Fix for issues on Coverity related to IDs cv_1125383, cv_1125382, cv_1125380, 
> cv_1125379, cv_1125378, cv_1125377, cv_1125376, cv_1125375, cv_1125374.
> 
> Those bugs are related to classes not implementing Serializable, nox 
> overriding the equals and/or hashCode methods and with empty finalize method.
> 
> For the bug cv_1125376, although it has been submitted in a previous patch, 
> there was a typo on the return key word, which contained a "s".
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerDBSyncImpl.java
>  8cb4e8d 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ServerEventHandlerImpl.java
>  455e601 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObject.java
>  71d28ac 
>   
> plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/ModelObjectBase.java
>  f22c7c5 
> 
> Diff: https://reviews.apache.org/r/15298/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Wilder Rodrigues
> 
>

Re: Review Request 15296: CLOUDSTACK-5067 Bugfix: two NICs connected to Public network exist in VR

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15296/#review28361
---

Ship it!


commit 494ccd821d711a2957531d1c33274ed293e4d925
Author: ynojima 
Date:   Wed Nov 6 11:02:56 2013 -0700

Bugfix: VR has double NICs connected to Public network

replace vlanid wih broadcast uri to support vxlan to identify whether id is 
VLAN ID or VNI

Signed-off-by: ynojima 
Signed-off-by: Hugo Trippaers 


- Hugo Trippaers


On Nov. 7, 2013, 1:11 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15296/
> ---
> 
> (Updated Nov. 7, 2013, 1:11 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Marcus Sorensen, Hugo 
> Trippaers, and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-5067
> https://issues.apache.org/jira/browse/CLOUDSTACK-5067
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is a patch to fix the bug "CLOUDSTACK-5067 Bugfix: two NICs connected to 
> Public network exist in VR".
> 
> It seems it is caused by wrong handling of IpAssocCommand.
> 
> IpAssocCommand is processed inappropriately in the method 
> "LibvirtComputingResource#execute(IpAssocCommand)".
> 
> It hotplugs unnecessary vNIC by mistake.
> https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L2049
> 
> It is caused by isolation method notation mismatch in this line.
> https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L2047
> 
> It expects isolation method is expressed in broadcast uri style like 
> "vlan://1234", "vlan://untagged", but "untagged" is passed.
> https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L2033
> 
> FYI: Notation change is conducted in this commit.
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java;h=74f02c0c639d125f435b3b3f278fe3985f09c7ca;hp=203587a06f63f23d487ae65dcf5c397cd2702166;hb=2614b00c;hpb=62b0ad03c871c7100433b39593a82d393879124e
> 
> Further, current code cannot retrieve VNI(VXLAN ID) from bridge name. This 
> patch extends getVlanIdFromBridge to getBroadcastUriFromBridge to support 
> vxlan.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  e3f60f2 
> 
> Diff: https://reviews.apache.org/r/15296/diff/
> 
> 
> Testing
> ---
> 
> I deployed VR, and confirmed it has one NIC connected to Public network.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 15304: Added installation of marvin along with packaging to mvn build

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15304/#review28364
---


I'm not sure this is a good idea. The install target doesn't actually install 
cloudstack. It "installs" the generated artifacts into the local maven 
repository, but it does't make any changes to the machine itself.

Adding this install procedure would cause our compile phase to make actual 
changes to the developers machine. Especially with multiple versions this might 
cause unintended behavior. Especially as the versions numbering of Marvin is 
not inline with the cloudstack code base.



tools/marvin/pom.xml
<https://reviews.apache.org/r/15304/#comment55185>

How do we ensure it also works for people that use easy_install instead of 
pip?


- Hugo Trippaers


On Nov. 7, 2013, 10:11 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15304/
> ---
> 
> (Updated Nov. 7, 2013, 10:11 a.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-5073
> https://issues.apache.org/jira/browse/CLOUDSTACK-5073
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Currently, we dont install the Marvin packages with default mvn install. As 
> part of this command currently, we just source 
> distribute the Marvin. For marvin,We assume user to have run its own 
> installation of packages post distribution. 
> This way, some times if any new addition of package changes happens, user has 
> to explicitly run installation of marvin. 
> If not installed,the changes are not available to tests and other code. With 
> this change, we package and 
> install them as well
> 
> 
> Diffs
> -
> 
>   tools/marvin/pom.xml 0869248 
> 
> Diff: https://reviews.apache.org/r/15304/diff/
> 
> 
> Testing
> ---
> 
> Tested that installation works post packaging
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

[JENKINS] Issues resolved

[Hugo Trippaers]

Heya,

The builds were stuck because the system ran out of diskspace. Cleaned some of 
the unused job folders to get some space back.


Cheers,

Hugo

Re: uploading to maven repository

[Hugo Trippaers]

Hey Alex,

That is indeed the right step to take.

If you need any help with this let me know.

Cheers,

Hugo


On 12 nov. 2013, at 17:04, Alex Huang  wrote:

> Hi all,
> 
> I have a chance to convince xenserver to upload their java stubs to maven so 
> that we don't have to keep a copy of it in ours source code.  They're stuck 
> on the whole upload process as they've never dealt with maven before.  Is 
> there anyone who can walk me through how to do it?
> 
> Reading the maven guide[1], it seems to easiest would be to just upload the 
> artifact[2].  Is that the right approach?  
> 
> Thanks.
> 
> --Alex
> [1] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> [2] 
> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository

Fwd: New Defects reported by Coverity Scan for cloudstack

[Hugo Trippaers]

Forward as the mail to the list is not setup yet.

Sent from my iPhone

Begin forwarded message:

> From: scan-ad...@coverity.com
> Date: 15 november 2013 13:47:59 CET
> Subject: New Defects reported by Coverity Scan for cloudstack
> 
> 
> Hi,
> 
> 
> Please find the latest report on new defect(s) introduced to cloudstack found 
> with Coverity Scan.
> 
> Defect(s) Reported-by: Coverity Scan
> Showing 7 of 7 defect(s)
> 
> 
> ** CID 1128965:  Missing call to superclass  (CALL_SUPER)
> /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/MockSource.java:
>  49 in streamer.MockSource.handleEvent(streamer.Event, streamer.Direction)()
> 
> ** CID 1128964:  Missing call to superclass  (CALL_SUPER)
> /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/FakeSink.java: 
> 45 in streamer.FakeSink.handleEvent(streamer.Event, streamer.Direction)()
> 
> ** CID 1128966:  Explicit null dereferenced  (FORWARD_NULL)
> /server/src/com/cloud/network/NetworkServiceImpl.java: 3553 in 
> com.cloud.network.NetworkServiceImpl.addTrafficTypeToPhysicalNetwork(java.lang.Long,
>  java.lang.String, java.lang.String, java.lang.String, java.lang.String, 
> java.lang.String, java.lang.String, java.lang.String)()
> 
> ** CID 1128967:  Unguarded write  (GUARDED_BY_VIOLATION)
> /plugins/network-elements/palo-alto/src/com/cloud/network/resource/PaloAltoResource.java:
>  246 in 
> com.cloud.network.resource.PaloAltoResource.configure(java.lang.String, 
> java.util.Map)()
> 
> ** CID 1128968:  Using invalid iterator  (INVALIDATE_ITERATOR)
> /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/BaseElement.java:
>  149 in streamer.BaseElement.poll(boolean)()
> 
> ** CID 1128969:  Failure to restore non-local value  (MISSING_RESTORE)
> /server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java: 1194 in 
> com.cloud.network.lb.LoadBalancingRulesManagerImpl.assignCertToLoadBalancer(long,
>  java.lang.Long)()
> 
> ** CID 1128970:  Dereference null return value  (NULL_RETURNS)
> /services/console-proxy-rdp/rdpconsole/src/main/java/streamer/BaseElement.java:
>  414 in streamer.BaseElement.main(java.lang.String[])()
> 
> 
> 
> 
> 
> To view the defects in Coverity Scan visit, http://scan.coverity.com
> 
> To unsubscribe from the email notification for new defects, 
> http://scan5.coverity.com/cgi-bin/unsubscribe.py
> 
> 
> 

SDN compat matrix

[Hugo Trippaers]

Hey guys,

I’m building the compatibility matrix for our SDN plugins to use in my 
presentation for CCCEU13. I think i got everything in there, but would like to 
check it against your combined knowledge:

GRE isolation
supports L2 isolation
XenServer supported since pre ACS
KVM supported since pre ACS
(not taking son extensions branch into account yet)
VXLAN
supports L2 isolation
KVM supported since master (4.3)
Nicira NVP
supports L2 isolation
supports L3 NAT function since 4.1
supports VPC networks
XenServer supported since 4.0
KVM supported since 4.1
VMware supported since 4.2
Midokura
supports L2 isolation
supports L3 NAT, DHCP, Firewall
supports VPC networks
KVM supported since 4.2
Stratosphere
supports L2 isolation
KVM supported since 4.2
Contrail
supports L2 isolation
supports L3 NAT, DHCP
Xenserver supported since master
KVM supported since master


Anything i forgot here?

Cheers,

Hugo

Re: SDN compat matrix

[Hugo Trippaers]

Thanks for the feedback guys.

I’ve put the updates matrix here on the wiki. 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Compatibility+Matrices

Cheers,

Hugo


On 18 nov. 2013, at 08:01, Pedro Roque Marques  
wrote:

> Hugo,
> Small correction bellow...
> 
> On Nov 17, 2013, at 2:40 AM, Hugo Trippaers  wrote:
> 
>> Hey guys,
>> 
>> I’m building the compatibility matrix for our SDN plugins to use in my 
>> presentation for CCCEU13. I think i got everything in there, but would like 
>> to check it against your combined knowledge:
>> 
>> GRE isolation
>>  supports L2 isolation
>>  XenServer supported since pre ACS
>>  KVM supported since pre ACS
>>  (not taking son extensions branch into account yet)
>> VXLAN
>>  supports L2 isolation
>>  KVM supported since master (4.3)
>> Nicira NVP
>>  supports L2 isolation
>>  supports L3 NAT function since 4.1
>>  supports VPC networks
>>  XenServer supported since 4.0
>>  KVM supported since 4.1
>>  VMware supported since 4.2
>> Midokura
>>  supports L2 isolation
>>  supports L3 NAT, DHCP, Firewall
>>  supports VPC networks
>>  KVM supported since 4.2
>> Stratosphere
>>  supports L2 isolation
>>  KVM supported since 4.2
>> Contrail
>>  supports L2 isolation
>>  supports L3 NAT, DHCP
>>  Xenserver supported since master
>>  KVM supported since master
> 
> For Contrail KVM support is not there yet...; it does support a distributed 
> router replacing the domain router for traffic that traverses guest networks.
> 
>> 
>> 
>> Anything i forgot here?
>> 
>> Cheers,
>> 
>> Hugo

[PATCH][ACS41] Update Nicira NVP api to support NVP version 3.x.x

[Hugo Trippaers]

Hey guys,

I pushed commit 4e090796408152af5c06ce72f346ee9ea5d4d404 to master. This commit 
supports the changes to the NVP api introduced in version 3.x.x

I'm a bit hesitant to request this a this time in the 4.1 release cycle. 
However I decided to request it because this is a new feature (SourceNat, 
PortFowarding and StaticNat support) that we are shipping with the 4.1 release. 
Without this patch the feature would be pretty much useless as most people 
would have upgraded their Nicira stacks to a more recent version and new users 
will probably start with the new version. Shipping a new feature that will only 
work on older external devices seems rather pointless.

So is this ok to pull into 4.1?


Testing done:

Jenkins Testrun
RPM packaging
NVP QA: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Nicira+NVP

Cheers,

Hugo

RE: [PATCH][ACS41] Update Nicira NVP api to support NVP version 3.x.x

[Hugo Trippaers]

Thanks Chip!

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Wednesday, May 22, 2013 3:40 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PATCH][ACS41] Update Nicira NVP api to support NVP version
> 3.x.x
> 
> On Wed, May 22, 2013 at 09:58:12AM +, Hugo Trippaers wrote:
> > Hey guys,
> >
> > I pushed commit 4e090796408152af5c06ce72f346ee9ea5d4d404 to master.
> This commit supports the changes to the NVP api introduced in version 3.x.x
> >
> > I'm a bit hesitant to request this a this time in the 4.1 release cycle.
> However I decided to request it because this is a new feature (SourceNat,
> PortFowarding and StaticNat support) that we are shipping with the 4.1
> release. Without this patch the feature would be pretty much useless as
> most people would have upgraded their Nicira stacks to a more recent
> version and new users will probably start with the new version. Shipping a
> new feature that will only work on older external devices seems rather
> pointless.
> >
> > So is this ok to pull into 4.1?
> >
> >
> > Testing done:
> >
> > Jenkins Testrun
> > RPM packaging
> > NVP QA:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Nicira+NVP
> >
> > Cheers,
> >
> > Hugo
> >
> 
> Done

Re: Nicira NVP + CloudStack 4.1

[Hugo Trippaers]

Hey Chip,

I still need to update the nvp plugin guide. It's a bit outdated and the new 
features are not in there yet.

Also the admin guide makes no mention of SDN support at all.

Guess I have some work to do there as well. I'll get to it ASAP.

Cheers,

Hugo 

Sent from my iPhone

On 22 mei 2013, at 20:13, Chip Childers  wrote:

> Hugo,
> 
> Was the doc updated for the new 4.1 features?
> 
> -chip
> 
> On Wed, May 22, 2013 at 01:59:49PM +, Kimihiko Kitase wrote:
>> Hello
>> 
>> Are there setup guide for the configuration of Nicira NVP and CloudStack 4.1?
>> 
>> Thanks
>> Kimi
>> 

RE: Nicira NVP + CloudStack 4.1

[Hugo Trippaers]

Kimihiko-san,

There is the setup guide in the CloudStack documentation 
(http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.0-incubating/html/CloudStack_Nicira_NVP_Guide/index.html)
 . It is a bit outdated and I will try to improve it. It doesn't list the new 
layer 3 features present in 4.1. 

There is also a video on how to setup CloudStack with Nicira NVP at 
http://www.youtube.com/watch?v=F-FgHni7W34

Cheers,

Hugo

> -Original Message-
> From: Kimihiko Kitase [mailto:kimihiko.kit...@citrix.co.jp]
> Sent: Wednesday, May 22, 2013 4:00 PM
> To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
> Subject: Nicira NVP + CloudStack 4.1
> 
> Hello
> 
> Are there setup guide for the configuration of Nicira NVP and CloudStack 4.1?
> 
> Thanks
> Kimi

RE: Nicira NVP + CloudStack 4.1

[Hugo Trippaers]

I've updated the documentation.

Chip, can you pull commit 1201d623a7091517a1e26bc4b82c5daeea3c155f into 4.1?  
It's just doc updates.

The Jenkins build is here 
http://jenkins.cloudstack.org/view/master/job/build-docs-niciranvp-master/


(And this time I did do the rat check ;-) )

Hugo

> -Original Message-
> From: Hugo Trippaers [mailto:trip...@gmail.com]
> Sent: Wednesday, May 22, 2013 11:03 PM
> To: Chip Childers
> Cc: dev@cloudstack.apache.org; h...@apache.org
> Subject: Re: Nicira NVP + CloudStack 4.1
> 
> Hey Chip,
> 
> I still need to update the nvp plugin guide. It's a bit outdated and the new
> features are not in there yet.
> 
> Also the admin guide makes no mention of SDN support at all.
> 
> Guess I have some work to do there as well. I'll get to it ASAP.
> 
> Cheers,
> 
> Hugo
> 
> Sent from my iPhone
> 
> On 22 mei 2013, at 20:13, Chip Childers  wrote:
> 
> > Hugo,
> >
> > Was the doc updated for the new 4.1 features?
> >
> > -chip
> >
> > On Wed, May 22, 2013 at 01:59:49PM +, Kimihiko Kitase wrote:
> >> Hello
> >>
> >> Are there setup guide for the configuration of Nicira NVP and CloudStack
> 4.1?
> >>
> >> Thanks
> >> Kimi
> >>

RE: Build failed in Jenkins: cloudstack-rat-41 #331

[Hugo Trippaers]

/me makes a mental note, more beer for Chip at CCC

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Wednesday, May 22, 2013 7:33 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Build failed in Jenkins: cloudstack-rat-41 #331
> 
> Fixed the Nicira files causing the error.
> 
> On Wed, May 22, 2013 at 04:50:18PM +, Apache Jenkins Server wrote:
> > See 
> >
> > Changes:
> >
> > [chip.childers] Update the Logical Router NatRules to be compatible
> > with the NVP 3.x.x
> >
> > [chipchilders] Corrected mailing list addresses in the release notes
> >
> > [chipchilders] CLOUDSTACK-2516: Documenting the required
> > components.xml change to deal
> >
> > --
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Started by an SCM change
> > Building remotely on ubuntu1 in workspace
> > 
> > Checkout:cloudstack-rat-41 /
> >  -
> > hudson.remoting.Channel@49556a62:ubuntu1
> > Using strategy: Default
> > Last Built Revision: Revision 8a9206fd28872dd436b22b847e93466f06e043bc
> > (origin/4.1) Fetching changes from 1 remote Git repository Fetching
> > upstream changes from
> > https://git-wip-us.apache.org/repos/asf/cloudstack.git
> > Commencing build of Revision
> bf8b09834fbeb0e67bdf52299ed2d0812844b665
> > (origin/4.1) Checking out Revision
> > bf8b09834fbeb0e67bdf52299ed2d0812844b665 (origin/4.1)
> > [cloudstack-rat-41] $ /bin/bash -xe /tmp/hudson827275774181797349.sh
> > + /home/jenkins/tools/maven/latest2/bin/mvn
> > + --projects=org.apache.cloudstack:cloudstack
> > + org.apache.rat:apache-rat-plugin:0.8:check
> > [INFO] Scanning for projects...
> > [INFO]
> > --
> > --
> > [INFO] Building Apache CloudStack
> > [INFO]task-segment: [org.apache.rat:apache-rat-plugin:0.8:check]
> > [INFO]
> > --
> > -- [INFO] [apache-rat:check {execution: default-cli}] [INFO] Exclude:
> > CHANGES [INFO] Exclude: INSTALL.md [INFO] Exclude: .idea/ [INFO]
> > Exclude: *.log [INFO] Exclude: **/*.patch [INFO] Exclude:
> > **/.classpath [INFO] Exclude: **/.project [INFO] Exclude: **/*.iml
> > [INFO] Exclude: **/.settings/** [INFO] Exclude: .metadata/** [INFO]
> > Exclude: .git/** [INFO] Exclude: .gitignore [INFO] Exclude: **/*.crt
> > [INFO] Exclude: **/*.csr [INFO] Exclude: **/*.key [INFO] Exclude:
> > **/authorized_keys [INFO] Exclude: **/*.war [INFO] Exclude: **/*.mar
> > [INFO] Exclude: **/*.jar [INFO] Exclude: **/*.iso [INFO] Exclude:
> > **/*.tgz [INFO] Exclude: **/*.zip [INFO] Exclude: **/target/** [INFO]
> > Exclude: **/.vagrant [INFO] Exclude: build/build.number [INFO]
> > Exclude: console-proxy/js/jquery.js [INFO] Exclude: debian/compat
> > [INFO] Exclude: debian/control [INFO] Exclude: debian/dirs [INFO]
> > Exclude: debian/rules [INFO] Exclude:
> > deps/XenServerJava/src/com/xensource/xenapi/*.java
> > [INFO] Exclude: deps/XenServerJava/BSD [INFO] Exclude:
> > deps/XenServerJava/Makefile [INFO] Exclude:
> > dist/console-proxy/js/jquery.js [INFO] Exclude:
> > scripts/vm/systemvm/id_rsa.cloud [INFO] Exclude:
> > tools/devcloud/basebuild/puppet-devcloudinitial/files/network.conf
> > [INFO] Exclude: tools/appliance/definitions/systemvmtemplate/base.sh
> > [INFO] Exclude:
> > tools/appliance/definitions/systemvmtemplate/cleanup.sh
> > [INFO] Exclude:
> > tools/appliance/definitions/systemvmtemplate/definition.rb
> > [INFO] Exclude:
> > tools/appliance/definitions/systemvmtemplate/preseed.cfg
> > [INFO] Exclude:
> > tools/appliance/definitions/systemvmtemplate/zerodisk.sh
> > [INFO] Exclude:
> > tools/devcloud/src/deps/boxes/basebox-build/definition.rb
> > [INFO] Exclude:
> > tools/devcloud/src/deps/boxes/basebox-build/preseed.cfg
> > [INFO] Exclude: ui/lib/flot/jquery.colorhelpers.js
> > [INFO] Exclude: ui/lib/flot/jquery.flot.crosshair.js
> > [INFO] Exclude: ui/lib/flot/jquery.flot.fillbetween.js
> > [INFO] Exclude: ui/lib/flot/jquery.flot.image.js [INFO] Exclude:
> > ui/lib/flot/jquery.flot.js [INFO] Exclude:
> > ui/lib/flot/jquery.flot.navigate.js
> > [INFO] Exclude: ui/lib/flot/jquery.flot.pie.js [INFO] Exclude:
> > ui/lib/flot/jquery.flot.resize.js [INFO] Exclude:
> > ui/lib/flot/jquery.flot.selection.js
> > [INFO] Exclude: ui/lib/flot/jquery.flot.stack.js [INFO] Exclude:
> > u

Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent ovs aware

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11428/#review21052
---

Ship it!


Ship It!

- Hugo Trippaers


On May 27, 2013, 1:46 a.m., Hiroaki Kawai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11428/
> ---
> 
> (Updated May 27, 2013, 1:46 a.m.)
> 
> 
> Review request for cloudstack, Sheng Yang and Hugo Trippaers.
> 
> 
> Description
> ---
> 
> Ovs brcompat will be obsolete, so if network.bridge.type was
> set to openvswitch, we'll use ovs command explicitly.
> 
> 
> This addresses bug CLOUDSTACK-2327.
> 
> 
> Diffs
> -
> 
>   agent/bindir/cloud-setup-agent.in 5e2ba09 
>   python/lib/cloudutils/globalEnv.py 94d981f 
>   python/lib/cloudutils/networkConfig.py b6b729a 
>   python/lib/cloudutils/serviceConfig.py 1e32d0f 
> 
> Diff: https://reviews.apache.org/r/11428/diff/
> 
> 
> Testing
> ---
> 
> Tested with my local machines. 
> - create .rpm, .deb
> - install it (CentOS 6.4 and Ubuntu 13.04)
> - add the computing node in management server
> 
> 
> Thanks,
> 
> Hiroaki Kawai
> 
>

Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent ovs aware

[Hugo Trippaers]

> On May 27, 2013, 7:21 a.m., Hugo Trippaers wrote:
> > Ship It!

Looking good, you can commit it yourself right?


- Hugo


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11428/#review21052
---


On May 27, 2013, 1:46 a.m., Hiroaki Kawai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11428/
> ---
> 
> (Updated May 27, 2013, 1:46 a.m.)
> 
> 
> Review request for cloudstack, Sheng Yang and Hugo Trippaers.
> 
> 
> Description
> ---
> 
> Ovs brcompat will be obsolete, so if network.bridge.type was
> set to openvswitch, we'll use ovs command explicitly.
> 
> 
> This addresses bug CLOUDSTACK-2327.
> 
> 
> Diffs
> -
> 
>   agent/bindir/cloud-setup-agent.in 5e2ba09 
>   python/lib/cloudutils/globalEnv.py 94d981f 
>   python/lib/cloudutils/networkConfig.py b6b729a 
>   python/lib/cloudutils/serviceConfig.py 1e32d0f 
> 
> Diff: https://reviews.apache.org/r/11428/diff/
> 
> 
> Testing
> ---
> 
> Tested with my local machines. 
> - create .rpm, .deb
> - install it (CentOS 6.4 and Ubuntu 13.04)
> - add the computing node in management server
> 
> 
> Thanks,
> 
> Hiroaki Kawai
> 
>

RE: Review Request: CLOUDSTACK-2327: make cloud-setup-agent ovs aware

[Hugo Trippaers]

> -Original Message-
> From: Hiroaki KAWAI [mailto:ka...@stratosphere.co.jp]
> Sent: Wednesday, May 29, 2013 8:39 AM
> To: Sheng Yang
> Cc: Hugo Trippaers; cloudstack
> Subject: Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent
> ovs aware
> 
> (2013/05/29 15:26), Sheng Yang wrote:
> > One more reason was to allow people use native bridging
> > even one has accidentally installed openvswitch package.
> >
> >
> > Bridge created on ovs is different from bridge created on native linux
> > bridge. For later, ovs-vsctl shouldn't show any bridge/switch(e.g.
> > cloudbr0), but brctl would. And I remember they're probably
> > exclusive(openvswitch kernel module vs bridge module)?
> 
> Without brcompat, brctl would not show ovs bridges.
> bridge and openvswitch do coexist.
> With brcompat, we must use exclusively, but brcompat is obsolete now..

With brcomcat the linux bridge module must still be disabled. However the old 
bridge tools will still work but use the openvswitch underneath, it's really 
just a compatibility layer.

> 
> > I think you're suggesting making it more few setup steps
> > for enabling ovs. And I completly agree with it. So we might
> > need some more improvements here...
> >
> >
> > In fact, I am thinking about preconfigured ovs environment(KVM or Xen).
> > I think openvswitch enabling shouldn't be part of work of
> > cloudstack(e.g. it's not a part of adding XenServer host). For KVM,
> > user can loaded openvswitch module(without brcompat module), unload
> > bridge module, and start openvswitch service to enable ovs. We should
> > add some steps in manual for that.
> >
> > I am agree we need more investigation here, to find a proper way tell
> > if user want to use ovs or not.

That's tricky.  I usually check if the openvswitch kernel module is loaded in 
the system, but it could be statically compile into the kernel. Using ovs-vsctl 
is also a possibility, but might hang if the database is not present and in 
general only reports if the userland binaries are installed.

> 
> I'm ok for changing the default to ovs (adding dependency in packages).

I'm fine with this too. I didn't do it for backwards compatibility and to 
prevent problems with existing setup. I think it's perfectly fine to make ovs 
the default with the next release. Then we have one release (4.1) where people 
can play with the ovs integration on KVM and in the next release it's enabled 
by default. However I think we should not force the installation of the 
openvswitch on users when we install cloudstack-agent. That is something that 
should be done by sysadmins. Just like we don't force the installation of kvm 
virtualization tools. However we should tell the user that openvswitch support 
is not enabled on the system and that it is a requirement.

> 
> 

RE: IRC Meeting Tomorrow? (Wednesday, May 29)

[Hugo Trippaers]

Hey Joe,

Wednesday is not working for me, I have a recurring appointment on Wednesday 
evenings. However should time permit I will join, I think it's a useful 
addition to the discussions going on here on dev.

Cheers,

Hugo

> -Original Message-
> From: Joe Brockmeier [mailto:j...@zonker.net]
> Sent: Tuesday, May 28, 2013 4:44 PM
> To: dev@cloudstack.apache.org
> Subject: IRC Meeting Tomorrow? (Wednesday, May 29)
> 
> Hey all,
> 
> The regular scheduled time for the weekly IRC meeting is 17:00 UTC
> tomorrow. We've had really low turnouts for the last month or so.
> Instead of sending a reminder, I wanted to ping the list and see whether we
> had enough interest to sustain the meeting time.
> 
> Thoughts, suggestions, comments, flames?
> 
> Best,
> 
> jzb
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/

RE: [VOTE] Release Apache CloudStack 4.1.0 (fifth round)

[Hugo Trippaers]

+1 (binding)

Tested:
* Upgrade empty 4.0.2 database to 4.1.0, Start management
* Upgrade existing live 4.0.2 database to 4.1.0, Start management
* Clean install database 4.1.0, Start management

* Setup advanced zone with XenServer and Nicira NVP
* Deploy host in Nicira L2 network
* Deploy host in Nicira L2 network with Nicira L3 StaticNat, SourceNat and 
PortForwarding
* Create VPC using Nicira L2
* Deploy host in VPC net no LB
* Deploy host in VPC net

* Start usage server, check logging

Cheers,

Hugo

> -Original Message-
> From: Edison Su [mailto:edison...@citrix.com]
> Sent: Wednesday, May 29, 2013 3:14 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Release Apache CloudStack 4.1.0 (fifth round)
> 
> +1, tested on the same environment and at the same time.
> 
> > -Original Message-
> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > Sent: Tuesday, May 28, 2013 6:08 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE] Release Apache CloudStack 4.1.0 (fifth round)
> >
> > +1
> >
> > Tested with Management Sever on CentOS 6.4 and Xen
> >
> > > -Original Message-
> > > From: Chip Childers [mailto:chip.child...@sungard.com]
> > > Sent: Tuesday, May 28, 2013 6:48 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: [VOTE] Release Apache CloudStack 4.1.0 (fifth round)
> > >
> > > Hi All,
> > >
> > > I've created a 4.1.0 release, with the following artifacts up for a
> > > vote.
> > >
> > > The changes from round 4 are related to DEB packaging, some
> > > translation strings, and a functional patch to make bridge type
> > > optional during the agent setup (for backward compatibility).
> > >
> > > Git Branch and Commit SH:
> > > https://git-wip-
> > > us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1
> > > Commit: a5214bee99f6c5582d755c9499f7d99fd7b5b701
> > >
> > > List of changes:
> > > https://git-wip-
> > >
> >
> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1
> > >
> > > Source release (checksums and signatures are available at the same
> > > location):
> > > https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/
> > >
> > > PGP release keys (signed using A99A5D58):
> > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > >
> > > Testing instructions are here:
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr
> > > oc
> > > edure
> > >
> > > Vote will be open for 72 hours.
> > >
> > > For sanity in tallying the vote, can PMC members please be sure to
> > > indicate "(binding)" with their vote?
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)

Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent ovs aware

[Hugo Trippaers]

Sent from my iPhone

On 29 mei 2013, at 22:29, "Sheng Yang" 
mailto:sh...@yasker.org>> wrote:

On Wed, May 29, 2013 at 12:09 AM, Hugo Trippaers 
mailto:htrippa...@schubergphilis.com>> wrote:


> -Original Message-
> From: Hiroaki KAWAI 
> [mailto:ka...@stratosphere.co.jp<mailto:ka...@stratosphere.co.jp>]
> Sent: Wednesday, May 29, 2013 8:39 AM
> To: Sheng Yang
> Cc: Hugo Trippaers; cloudstack
> Subject: Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent
> ovs aware
>
> (2013/05/29 15:26), Sheng Yang wrote:
> > One more reason was to allow people use native bridging
> > even one has accidentally installed openvswitch package.
> >
> >
> > Bridge created on ovs is different from bridge created on native linux
> > bridge. For later, ovs-vsctl shouldn't show any bridge/switch(e.g.
> > cloudbr0), but brctl would. And I remember they're probably
> > exclusive(openvswitch kernel module vs bridge module)?
>
> Without brcompat, brctl would not show ovs bridges.
> bridge and openvswitch do coexist.
> With brcompat, we must use exclusively, but brcompat is obsolete now..

With brcomcat the linux bridge module must still be disabled. However the old 
bridge tools will still work but use the openvswitch underneath, it's really 
just a compatibility layer.

If they're able to coexisted(no brcompat module), then we should able to look 
into both ovs-vsctl(if it's not hang...) and brctl, to find the bridge user 
want to program. I don't think user can configure e.g. cloudbr0 on the both.

Actually you can :-(. This leads to all sorts of strange problems. Bridge and 
openvswitch can't coexist.



>
> > I think you're suggesting making it more few setup steps
> > for enabling ovs. And I completly agree with it. So we might
> > need some more improvements here...
> >
> >
> > In fact, I am thinking about preconfigured ovs environment(KVM or Xen).
> > I think openvswitch enabling shouldn't be part of work of
> > cloudstack(e.g. it's not a part of adding XenServer host). For KVM,
> > user can loaded openvswitch module(without brcompat module), unload
> > bridge module, and start openvswitch service to enable ovs. We should
> > add some steps in manual for that.
> >
> > I am agree we need more investigation here, to find a proper way tell
> > if user want to use ovs or not.

That's tricky.  I usually check if the openvswitch kernel module is loaded in 
the system, but it could be statically compile into the kernel. Using ovs-vsctl 
is also a possibility, but might hang if the database is not present and in 
general only reports if the userland binaries are installed.

I think "ovs-vsctl show"should report error if db is not existed rather than 
hang?

It tries to open the database and keeps on trying for some time. I haven't 
checked the sources yet but it appears to keep trying for some time.


>
> I'm ok for changing the default to ovs (adding dependency in packages).

I'm fine with this too. I didn't do it for backwards compatibility and to 
prevent problems with existing setup. I think it's perfectly fine to make ovs 
the default with the next release. Then we have one release (4.1) where people 
can play with the ovs integration on KVM and in the next release it's enabled 
by default. However I think we should not force the installation of the 
openvswitch on users when we install cloudstack-agent. That is something that 
should be done by sysadmins. Just like we don't force the installation of kvm 
virtualization tools. However we should tell the user that openvswitch support 
is not enabled on the system and that it is a requirement.

Agree on not install automatically. Admin should do that. But change default to 
ovs seems a big step for now, we didn't know enough of ovs I think, e.g. 
scalability, stability.  I think it would need more time...

In terms of stability and scalability I'm not worried at all. I've met some of 
the guys working on it and the amount of work on performance is amazing. In 
xencenter it is working really well and we out did most of our performance 
benchmarks.

Openvswitch is becoming a standard in many cloud implementations I think. If we 
integrate it completely now we will be ready for upcoming changes like vxlan 
etc.

But I agree we need to understand it very well ourselves too. I'm using it on a 
daily basis now, but not everyone is.


--Sheng

>
>

RE: Review Request: CLOUDSTACK-2327: make cloud-setup-agent ovs aware

[Hugo Trippaers]

I've put my installation procedure here: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/KVM+with+OpenVSwitch

Please edit and adapt where needed :D

> -Original Message-
> From: Hiroaki KAWAI [mailto:ka...@stratosphere.co.jp]
> Sent: Thursday, May 30, 2013 9:37 AM
> To: Sheng Yang
> Cc: Hugo Trippaers; cloudstack
> Subject: Re: Review Request: CLOUDSTACK-2327: make cloud-setup-agent
> ovs aware
> 
> (2013/05/30 15:56), Sheng Yang wrote:
> -snip-
> > BTW, I cannot figure out a way to automatically configure OVS on
> > Ubuntu
> > when booting up. it seems /etc/network/interfaces file doesn't know
> > about OVS.
> >
> >
> > The syntax is described in
> > /usr/share/doc/openvswitch-__switch/README.Debian
> > I'm encoutering the boot process issue, too. The master or
> > v1.10.0 ovs-vswitchd startup scripts would work because
> > it scans the interfaces file for allow-ovs and hooks ifup.
> > The version of ovs in ubuntu is v1.9.0 and the script
> > does not kick ifup.
> > I ported the v1.10.0 init script into running ubuntu,
> > then it starting up the interface in boot looks ok.
> >
> >
> > It's strange that ubuntu 13.04 support openvswitch but not auto
> > configuration. Do we want to open a ubuntu bug for that?
> 
> +1, and/or openvswitch 1.9.0 backporting (as upstream first)
> 
+1

RE: [PROPOSAL][ACS4.2] Stratosphere SDN platform plugin

[Hugo Trippaers]

+1

The more SDN providers we support the better.

I say go for it!

:-)

Cheers,

Hugo

> -Original Message-
> From: Hiroaki KAWAI [mailto:ka...@stratosphere.co.jp]
> Sent: Thursday, May 30, 2013 9:23 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL][ACS4.2] Stratosphere SDN platform plugin
> 
> Thank you for comment,
> 
> SSP is an SDN controller that creates L2 virtual network backed by vxlan. In
> cloudstack, the service will shows as "connectivity" networking service
> provider.
> I'm sorry that the description is so short, I've asked my colleage to fill up 
> the
> docs.
> 
> 
> (2013/05/30 15:12), Chiradeep Vittal wrote:
> > The proposal is rather thin. There is no explanation as to what SSP
> > is, what technology it uses (vlan?), what L2-L7 features will be supported.
> >
> > We are at the end of month 4 of the 4.2 release cycle.
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> >
> > On June 1, the 4.3 release cycle will open up.
> >
> > On 5/29/13 10:04 PM, "Hiroaki KAWAI"  wrote:
> >
> >> Hi all,
> >> # I think it is still ok to raise a proposal now...
> >>
> >> I would like to add a new feature to support "Stratosphere SDN
> >> platform" for guest networks in cloudstack advanced networking.
> >>
> >> jira : https://issues.apache.org/jira/browse/CLOUDSTACK-2756
> >>
> >> draft document on cwiki :
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Stratosphere+S
> >> SP+Ne
> >> twork+Plugin
> >>
> >> Please review.
> >>
> >> Thanks,
> >>
> >> ---
> >> Hiroaki KAWAI
> >

Re: Review Request: generalisation of network code (needed for CLOUDSTACK-1532)

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10970/#review21191
---


Daan,

I noticed quite a few tabs in your patch. The CloudStack standard is to use 
spaces instead of tabs. Can you change the patch to fix this?

Other comments below.

Can you explain what tests you executed to test the existing vlan functionality 
(besides the unittests)?



api/src/com/cloud/network/Networks.java
<https://reviews.apache.org/r/10970/#comment44007>

Why not use value.getScheme() != null ?



core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java
<https://reviews.apache.org/r/10970/#comment44008>

Dead code can be removed.



server/src/com/cloud/api/ApiResponseHelper.java
<https://reviews.apache.org/r/10970/#comment44009>

Does this have anything to do anything with your changes?



server/src/com/cloud/api/ApiResponseHelper.java
<https://reviews.apache.org/r/10970/#comment44010>

Why did this need to go?



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/10970/#comment44011>

Is this split covered in your code?



server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
<https://reviews.apache.org/r/10970/#comment44012>

Did you answer this question? Why it it here?


- Hugo Trippaers


On May 28, 2013, 9:43 a.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10970/
> ---
> 
> (Updated May 28, 2013, 9:43 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy, Hugo Trippaers, and Chiradeep 
> Vittal.
> 
> 
> Description
> ---
> 
> converting vlan id to uri to support a broader range of networks in for 
> instance vpc gateway connections
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/IpAddressTO.java 82c7d99 
>   api/src/com/cloud/agent/api/to/NetworkTO.java 3edd4c0 
>   api/src/com/cloud/network/NetworkService.java 59702a2 
>   api/src/com/cloud/network/Networks.java 5aede05 
>   api/src/com/cloud/network/vpc/PrivateIp.java eb68433 
>   api/src/com/cloud/network/vpc/StaticRouteProfile.java 54aa6e4 
>   api/src/com/cloud/network/vpc/VpcGateway.java 5d278e9 
>   api/src/com/cloud/network/vpc/VpcService.java 7a444c0 
>   
> api/src/org/apache/cloudstack/api/command/admin/vpc/CreatePrivateGatewayCmd.java
>  22dfb9e 
>   api/src/org/apache/cloudstack/api/response/PrivateGatewayResponse.java 
> c5c7df5 
>   
> core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
> 8b996d1 
>   engine/schema/src/com/cloud/network/vpc/VpcGatewayVO.java 7df2dfd 
>   
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetaNetworkGuru.java
>  6d14e3f 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  b897df2 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  f979cfe 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java
>  eac3248 
>   plugins/hypervisors/ovm/src/com/cloud/ovm/hypervisor/OvmResourceBase.java 
> a626e31 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  630d1b4 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  4680fde 
>   
> plugins/network-elements/cisco-vnmc/test/com/cloud/network/element/CiscoVnmcElementTest.java
>  a16733b 
>   
> plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java
>  1733712 
>   
> plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
>  fd065d5 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  c0d4599 
>   
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsTunnelManagerImpl.java
>  b1ecaac 
>   server/src/com/cloud/api/ApiResponseHelper.java 89739cf 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 214e292 
>   server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java 9d24e47 
>   server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java 
> f93bf7a 
>   server/src/com/cloud/network/ExternalLoadBalancerUsageManagerImpl.java 
> 2c8031c 
>   server/src/com/cloud/network/NetworkManager.java 05bc26e 
>   server/src/com/cloud/network/NetworkManagerImpl.java 254510b 
>   server/src/com/cloud/network/Net