date:20141024

Lucian, did you make a ticket for this? It seems a blocker bug to me!

On Fri, Oct 24, 2014 at 1:28 AM, Nux! n...@li.nux.ro wrote:
 Ok, so how I solved it:

 Followed the upgrade procedure to the letter, but before running 
 cloudstack-sysvmadm to upgrade my sytemvms I have replaced the QCOW2 file in 
 the secondary storage with a modified template in which I copied 
 /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh (and made 
 it immutable, just to make sure it doesn't go anywhere) ...

 After that I ran nohup cloudstack-sysvmadm -d IPaddress -u cloud -p password 
 -a  sysvm.log 21 

 Ugly, but it works. Thanks for helping me understand where the problem is 
 exactly..

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Daan Hoogland daan.hoogl...@gmail.com
 To: dev dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 14:43:45
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed: 
 /opt/cloud/bin/createipAlias.sh

 Jayapal, this was fixed but not in 4.4. why? and why does Lucian not
 hit it in 4.3 that contains the same error?

 On Wed, Oct 22, 2014 at 2:22 PM, Nux! n...@li.nux.ro wrote:
 Ok, you lost me. So what do I need to modify to correct this?

 Would customising the sysvm template and symlinking
 /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh solve the
 issue?

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 13:18:05
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed:
 /opt/cloud/bin/createipAlias.sh

 Hi Nux,

 The problem is not from the template.
 The file in the systemvm.iso has correct file name.
 VR config feature is referred it as incorrect.

 Thanks,
 Jayapal
 On 22-Oct-2014, at 5:18 PM, Nux! n...@li.nux.ro wrote:

 Daan,

 It may be old, but I don't see the problem with the 4.3.0 sysvm tmpl 
 (that I am
 still using, even with 4.3.1).

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Daan Hoogland daan.hoogl...@gmail.com
 To: dev dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 11:40:09
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 /opt/cloud/bin/createipAlias.sh

 Just checked,

 It is fixed in 4.5 but wasn't backported into 4.4. It is old code and
 the problem is in 4.3 as well.

 On Wed, Oct 22, 2014 at 9:39 AM, Nux! n...@li.nux.ro wrote:
 Jayapal,

 Thanks, but why are we releasing a faulty systemvm template? Can't we 
 upload a
 new one without the typo?

 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 05:52:14
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 /opt/cloud/bin/createipAlias.sh

 Hi Nux,

 There is spelling mistake 'i' instead of 'I' in the file name 
 'createipAlias.sh'

 Work around is in VR change createIpAlias.sh - createipAlias.sh
 Observe the MS log once the VR entered into Running state stop the MS 
 so that VR
 won't be destroyed.
 Now go to VR and change the file name.

 This issue got fixed in 4.5 CLOUDSTACK-7246

 Thanks,
 Jayapal
 On 22-Oct-2014, at 6:03 AM, Nux! n...@li.nux.ro wrote:

 Hi,

 I almost upgraded from 4.3.1 to 4.4.1, everything went smoothly 
 except the VR
 upgrade (the other sysvms are fine). It will not upgrade, even if I 
 delete it
 and create another, same story:

 On the agent I see:

 2014-10-22 01:17:17,857 DEBUG [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) Executing:
 /usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh 
 vr_cfg.sh
 169.254.1.228 -c 
 /var/cache/cloud/VR-5109f323-dc37-4af2-b75d-41dd65acbf93.cfg
 2014-10-22 01:17:17,934 DEBUG [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) Exit value is 1
 2014-10-22 01:17:17,934 DEBUG [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) VR config: execution failed:
 /opt/cloud/bin/createipAlias.sh
 289:10.13.208.78:255.255.255.248-224:10.187.71.194:255.255.255.192-, 
 check
 /var/log/cloud.log in VR for details

 But the VR is being destroyed and I cannot investigate the 
 /var/log/cloud.log
 ...


 On the management log:

 Unable to start instance due to Unable to start 
 VM[DomainRouter|r-443-VM] due to
 error in finalizeStart, not retrying
 more here http://pastebin.com/raw.php?i=fY7v8Sak

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!

Re: [PROPOSAL] Move to github PR only during moratorium on commit

On Fri, Oct 24, 2014 at 1:30 AM, Animesh Chaturvedi
animesh.chaturv...@citrix.com wrote:

 I sttrongly disagree with Animesh here and think Rohit is overlooking a
 simple fact. At the moment the branches are for 'stabalizing'.
 Fixing on master first is in direct contradiction with that.

 We have not been stabalizing 4.4. it contains bug that have during the
 release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't
 have been allowed to happen.
 [Animesh] Clearly we have disagreement. To avoid the issue that you mention 
 David had created forward branch for 4.2 and I found it useful and continued 
 with that approach in 4.3. With forward branch which are really staging it 
 was a simple merge of forward back to release branch. The other approach of 
 merging release branch into master work as well but in my opinion keeping 
 master as the default branch (with protection of course ) is simpler to 
 understand and creates less confusion


I abandoned that approach as cherry-picking started to give
complicated conflicts that I could not resolve. Also one particular
conflict, the one in the db upgrade script, kept coming back. This has
cost me a lot of time for work that was not there to begin with. Hence
my big aversion of the forward branches.


-- 
Daan

Re: [PROPOSAL] Move to github PR only during moratorium on commit

Mike, Why have everybody work on the same branch. people can work on
their own branch and when they are done they can rebase on the tip see
ci success and then merge. The problem with forward branches is
abandoned work or work that for some reason shouldn't go in 'this'
release. it will remain there.

On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
 Are we talking about something like what I drew up here?:

 http://i.imgur.com/UgPtJGY.png

 In this scheme, the -forward branches are the ones you can directly commit
 to while their peers without the -forward are the ones that code gets
 merged to from its corresponding -forward branch.

 CI is performed on the -forward branches before any merging takes place.

 The merge recorded concept I put in the diagram refers to the situation
 where you have a commit on a branch like 4.5, but you do NOT want it to
 move forward to master.

 I don't know if Git has such a concept, but SVN calls this kind of a
 merge merge recording. Merge recording essentially means you do not want
 those changes brought forward to the specified branch (not now and not with
 future merges other people or yourself may do).



 On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi 
 animesh.chaturv...@citrix.com wrote:



  -Original Message-
  From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
  Sent: Thursday, October 23, 2014 1:31 AM
  To: dev
  Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
  commit
 
  On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav
  rohit.ya...@shapeblue.com wrote:
   Hi,
  
   On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
  animesh.chaturv...@citrix.com wrote:
  ...
   The approach for fixing issues in release branch first and master
 later is
  not practical as we may miss out commits not made into master and future
  release regressing without the fixes.
  
   By the same logic, if we fix by default on master only, the release
 branch
  may miss out commits.
 
  I sttrongly disagree with Animesh here and think Rohit is overlooking a
  simple fact. At the moment the branches are for 'stabalizing'.
  Fixing on master first is in direct contradiction with that.
 
  We have not been stabalizing 4.4. it contains bug that have during the
  release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't
  have been allowed to happen.
 [Animesh] Clearly we have disagreement. To avoid the issue that you
 mention David had created forward branch for 4.2 and I found it useful and
 continued with that approach in 4.3. With forward branch which are really
 staging it was a simple merge of forward back to release branch. The other
 approach of merging release branch into master work as well but in my
 opinion keeping master as the default branch (with protection of course )
 is simpler to understand and creates less confusion




 --
 *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*™*



-- 
Daan

Re: commits on 4.5

On Fri, Oct 24, 2014 at 8:36 AM, Leo Simons lsim...@schubergphilis.com wrote:
 Hey Mike,

 In git you accomplish these kinds of things with merge strategies. There’s a 
 lot to choose from. What you’re describing sounds a bit like a variant on the 
 “theirs” strategy.
...
doh, will give it another spin. I used 'ours' instead or 'recursive -X
ours'. I think that is what we want except in Mikes usecase where we
would, knowing that there is only this commit to ignore, use 'ours'.


-- 
Daan

Re: 431 to 441, VR upgrade fails with VR config: execution failed: /opt/cloud/bin/createipAlias.sh

Yep, https://issues.apache.org/jira/browse/CLOUDSTACK-7781

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Daan Hoogland daan.hoogl...@gmail.com
 To: dev dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 08:03:59
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed: 
 /opt/cloud/bin/createipAlias.sh

 Lucian, did you make a ticket for this? It seems a blocker bug to me!
 
 On Fri, Oct 24, 2014 at 1:28 AM, Nux! n...@li.nux.ro wrote:
 Ok, so how I solved it:

 Followed the upgrade procedure to the letter, but before running
 cloudstack-sysvmadm to upgrade my sytemvms I have replaced the QCOW2 file in
 the secondary storage with a modified template in which I copied
 /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh (and made 
 it
 immutable, just to make sure it doesn't go anywhere) ...

 After that I ran nohup cloudstack-sysvmadm -d IPaddress -u cloud -p 
 password -a
  sysvm.log 21 

 Ugly, but it works. Thanks for helping me understand where the problem is
 exactly..

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Daan Hoogland daan.hoogl...@gmail.com
 To: dev dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 14:43:45
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed:
 /opt/cloud/bin/createipAlias.sh

 Jayapal, this was fixed but not in 4.4. why? and why does Lucian not
 hit it in 4.3 that contains the same error?

 On Wed, Oct 22, 2014 at 2:22 PM, Nux! n...@li.nux.ro wrote:
 Ok, you lost me. So what do I need to modify to correct this?

 Would customising the sysvm template and symlinking
 /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh solve 
 the
 issue?

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 13:18:05
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 /opt/cloud/bin/createipAlias.sh

 Hi Nux,

 The problem is not from the template.
 The file in the systemvm.iso has correct file name.
 VR config feature is referred it as incorrect.

 Thanks,
 Jayapal
 On 22-Oct-2014, at 5:18 PM, Nux! n...@li.nux.ro wrote:

 Daan,

 It may be old, but I don't see the problem with the 4.3.0 sysvm tmpl 
 (that I am
 still using, even with 4.3.1).

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Daan Hoogland daan.hoogl...@gmail.com
 To: dev dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 11:40:09
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 /opt/cloud/bin/createipAlias.sh

 Just checked,

 It is fixed in 4.5 but wasn't backported into 4.4. It is old code and
 the problem is in 4.3 as well.

 On Wed, Oct 22, 2014 at 9:39 AM, Nux! n...@li.nux.ro wrote:
 Jayapal,

 Thanks, but why are we releasing a faulty systemvm template? Can't we 
 upload a
 new one without the typo?

 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 05:52:14
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 /opt/cloud/bin/createipAlias.sh

 Hi Nux,

 There is spelling mistake 'i' instead of 'I' in the file name 
 'createipAlias.sh'

 Work around is in VR change createIpAlias.sh - createipAlias.sh
 Observe the MS log once the VR entered into Running state stop the MS 
 so that VR
 won't be destroyed.
 Now go to VR and change the file name.

 This issue got fixed in 4.5 CLOUDSTACK-7246

 Thanks,
 Jayapal
 On 22-Oct-2014, at 6:03 AM, Nux! n...@li.nux.ro wrote:

 Hi,

 I almost upgraded from 4.3.1 to 4.4.1, everything went smoothly 
 except the VR
 upgrade (the other sysvms are fine). It will not upgrade, even if I 
 delete it
 and create another, same story:

 On the agent I see:

 2014-10-22 01:17:17,857 DEBUG [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) Executing:
 /usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh 
 vr_cfg.sh
 169.254.1.228 -c 
 /var/cache/cloud/VR-5109f323-dc37-4af2-b75d-41dd65acbf93.cfg
 2014-10-22 01:17:17,934 DEBUG [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) Exit value is 1
 2014-10-22 01:17:17,934 DEBUG [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) VR config: execution failed:
 /opt/cloud/bin/createipAlias.sh
 289:10.13.208.78:255.255.255.248-224:10.187.71.194:255.255.255.192-,
  check
 /var/log/cloud.log in VR for details

 But the VR is being destroyed and I cannot investigate the 
 /var/log/cloud.log
 ...


 On the

Re: 431 to 441, VR upgrade fails with VR config: execution failed: /opt/cloud/bin/createipAlias.sh

thanks for walking the bleeding edge on this, Nux!

On Fri, Oct 24, 2014 at 10:32 AM, Nux! n...@li.nux.ro wrote:
 Yep, https://issues.apache.org/jira/browse/CLOUDSTACK-7781

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Daan Hoogland daan.hoogl...@gmail.com
 To: dev dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 08:03:59
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed: 
 /opt/cloud/bin/createipAlias.sh

 Lucian, did you make a ticket for this? It seems a blocker bug to me!

 On Fri, Oct 24, 2014 at 1:28 AM, Nux! n...@li.nux.ro wrote:
 Ok, so how I solved it:

 Followed the upgrade procedure to the letter, but before running
 cloudstack-sysvmadm to upgrade my sytemvms I have replaced the QCOW2 file in
 the secondary storage with a modified template in which I copied
 /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh (and 
 made it
 immutable, just to make sure it doesn't go anywhere) ...

 After that I ran nohup cloudstack-sysvmadm -d IPaddress -u cloud -p 
 password -a
  sysvm.log 21 

 Ugly, but it works. Thanks for helping me understand where the problem is
 exactly..

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Daan Hoogland daan.hoogl...@gmail.com
 To: dev dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 14:43:45
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed:
 /opt/cloud/bin/createipAlias.sh

 Jayapal, this was fixed but not in 4.4. why? and why does Lucian not
 hit it in 4.3 that contains the same error?

 On Wed, Oct 22, 2014 at 2:22 PM, Nux! n...@li.nux.ro wrote:
 Ok, you lost me. So what do I need to modify to correct this?

 Would customising the sysvm template and symlinking
 /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh solve 
 the
 issue?

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 13:18:05
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 /opt/cloud/bin/createipAlias.sh

 Hi Nux,

 The problem is not from the template.
 The file in the systemvm.iso has correct file name.
 VR config feature is referred it as incorrect.

 Thanks,
 Jayapal
 On 22-Oct-2014, at 5:18 PM, Nux! n...@li.nux.ro wrote:

 Daan,

 It may be old, but I don't see the problem with the 4.3.0 sysvm tmpl 
 (that I am
 still using, even with 4.3.1).

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Daan Hoogland daan.hoogl...@gmail.com
 To: dev dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 11:40:09
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 /opt/cloud/bin/createipAlias.sh

 Just checked,

 It is fixed in 4.5 but wasn't backported into 4.4. It is old code and
 the problem is in 4.3 as well.

 On Wed, Oct 22, 2014 at 9:39 AM, Nux! n...@li.nux.ro wrote:
 Jayapal,

 Thanks, but why are we releasing a faulty systemvm template? Can't we 
 upload a
 new one without the typo?

 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 From: Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Sent: Wednesday, 22 October, 2014 05:52:14
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 /opt/cloud/bin/createipAlias.sh

 Hi Nux,

 There is spelling mistake 'i' instead of 'I' in the file name 
 'createipAlias.sh'

 Work around is in VR change createIpAlias.sh - createipAlias.sh
 Observe the MS log once the VR entered into Running state stop the 
 MS so that VR
 won't be destroyed.
 Now go to VR and change the file name.

 This issue got fixed in 4.5 CLOUDSTACK-7246

 Thanks,
 Jayapal
 On 22-Oct-2014, at 6:03 AM, Nux! n...@li.nux.ro wrote:

 Hi,

 I almost upgraded from 4.3.1 to 4.4.1, everything went smoothly 
 except the VR
 upgrade (the other sysvms are fine). It will not upgrade, even if I 
 delete it
 and create another, same story:

 On the agent I see:

 2014-10-22 01:17:17,857 DEBUG 
 [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) Executing:
 /usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh 
 vr_cfg.sh
 169.254.1.228 -c 
 /var/cache/cloud/VR-5109f323-dc37-4af2-b75d-41dd65acbf93.cfg
 2014-10-22 01:17:17,934 DEBUG 
 [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) Exit value is 1
 2014-10-22 01:17:17,934 DEBUG 
 [kvm.resource.LibvirtComputingResource]
 (agentRequest-Handler-5:null) VR config: execution failed:
 /opt/cloud/bin/createipAlias.sh
 289:10.13.208.78:255.255.255.248-224:10.187.71.194:255.255.255.192-,
  check

Re: UI: where has Acquire new IP button disappeared?

Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7782 for this.

Anyone knows who we can bug for a fix?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Nux! n...@li.nux.ro
 To: dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 00:32:55
 Subject: UI: where has Acquire new IP button disappeared?

 Hi,
 
 Only now I notice that the option in the NIC tab of a VM (Basic/Adv+SG) no
 longer has the Acquire secondary button, nor does it list the Secondary IPs.
 I can set and see the extra IPs in cloudmonkey though if I run:
 
 add iptonic nicid=XXX
 list nics nicid=XXX virtualmachineid=XXX
 
 
 This is not OK ... alas I notice it too late. Promise to test more next 
 release.
 
 Any way I can get that back? I have people using the UI who rely on this
 feature.
 
 Lucian
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro

(rolling) upgrade of redundant virtual router

H,

I the present code a vr is updates as follows:

// 1) Shutdown all the elements and cleanup all the rules.
Don't allow to shutdown network in intermediate
// states - Shutdown and Implementing

// 2) Only after all the elements and rules are shutdown
properly, update the network VO
// get updated network

   // 3) Implement the elements and rules again

// 4) if network has been upgraded from a non persistent ntwk
offering to a persistent ntwk offering,
// implement the network if its not already

This means that for a redundant router vm both sides are brought down
before upgrade of the db entries is done. This is not acceptable for
mission critical environments such as our clients at Schuberg Philis
have. I am to concoct a way around this and will have my sweet time at
it. I am also willing to share this time with anyone that has thoughts
and particularly concerns on the issue.

To get to this point I extracted as much as I could from the
updateNetwork method in NetworkServiceImpl. The results are in
hotfix/CLOUDSTACK-7776. I plan to merge this before working on the
actual fix but after I am convinced that I re-factored it enough and
as much as possible. Please have a look if you dare to/enjoy it.

-- 
Daan

Fixing SystemVM builds

2014-10-24 Thread Rohit Yadav

Hi,

On jenkins.buildacloud.org, the last successful builds for systemvm template 
build jobs was 20-22 days ago. Can anyone give me either access to the infra so 
I can help debug and fix it, or people who have access help fix it? Thanks.

The common issue is that it takes a lot of time to copy the isos and it 
timeouts, or there is some server error.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design  Buildhttp://shapeblue.com/iaas-cloud-design-and-build//
CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/
CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/
CloudStack Infrastructure 
Supporthttp://shapeblue.com/cloudstack-infrastructure-support/
CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England  Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: (rolling) upgrade of redundant virtual router

At first glance it seems that we need is to

- shutdown one side
- update the vo
- restart the one side
- shutdown the other side
- restart the other side

Somehow this seems to be too simple. the shutdown elements works in a
generic way while my use case only applies to the virtual router and
not to other providers. In fact the network may have a redundant
virtual router and some other providers for which redundant makes no
sense or that have their only redundancy mechs, right?

On Fri, Oct 24, 2014 at 10:43 AM, Daan Hoogland daan.hoogl...@gmail.com wrote:
 H,

 I the present code a vr is updates as follows:

 // 1) Shutdown all the elements and cleanup all the rules.
 Don't allow to shutdown network in intermediate
 // states - Shutdown and Implementing

 // 2) Only after all the elements and rules are shutdown
 properly, update the network VO
 // get updated network

// 3) Implement the elements and rules again

 // 4) if network has been upgraded from a non persistent ntwk
 offering to a persistent ntwk offering,
 // implement the network if its not already

 This means that for a redundant router vm both sides are brought down
 before upgrade of the db entries is done. This is not acceptable for
 mission critical environments such as our clients at Schuberg Philis
 have. I am to concoct a way around this and will have my sweet time at
 it. I am also willing to share this time with anyone that has thoughts
 and particularly concerns on the issue.

 To get to this point I extracted as much as I could from the
 updateNetwork method in NetworkServiceImpl. The results are in
 hotfix/CLOUDSTACK-7776. I plan to merge this before working on the
 actual fix but after I am convinced that I re-factored it enough and
 as much as possible. Please have a look if you dare to/enjoy it.

 --
 Daan



-- 
Daan

Management server is stuck after upgrade to 4.4.1

2014-10-24 Thread Thomas Schneider

Hello,

I tried yo upgrade Cloudstack from 4.4.0 to 4.4.1, following the
instructions of the release note.
When I restarted the MS the update of the database worked as expected
but after the server is stuck.

Regards,

Partial log output:

2014-10-24 14:01:54,283 INFO  [c.c.u.d.T.Transaction] (main:null) Is
Data Base High Availiability enabled? Ans : false
2014-10-24 14:01:54,843 DEBUG [c.c.u.d.ConnectionConcierge] (main:null)
Registering a database connection for LockMaster1
2014-10-24 14:01:54,843 INFO  [c.c.u.d.Merovingian2] (main:null)
Cleaning up locks for 7012003873552
2014-10-24 14:01:54,853 INFO  [c.c.u.d.Merovingian2] (main:null)
Released 0 locks for 7012003873552
2014-10-24 14:01:54,895 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Running system integrity checker
com.cloud.upgrade.DatabaseUpgradeChecker@6345943f
2014-10-24 14:01:54,896 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
Grabbing lock to check for database upgrade.
2014-10-24 14:01:55,111 DEBUG [c.c.u.d.VersionDaoImpl] (main:null)
Checking to see if the database is at a version before it was the
version table is created
2014-10-24 14:01:55,140 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
DB version = 4.4.0 Code Version = 4.4.1
2014-10-24 14:01:55,142 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
Database upgrade must be performed from 4.4.0 to 4.4.1
2014-10-24 14:01:55,142 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null)
Running upgrade Upgrade440to441 to upgrade from 4.4.0-4.4.1 to 4.4.1
2014-10-24 14:01:55,149 DEBUG [c.c.u.s.Script] (main:null) Looking for
db/schema-440to441.sql in the classpath
2014-10-24 14:01:55,149 DEBUG [c.c.u.s.Script] (main:null) System
resource: file:/usr/share/cloudstack-management/setup/db/schema-440to441.sql
2014-10-24 14:01:55,149 DEBUG [c.c.u.s.Script] (main:null) Absolute path
=  /usr/share/cloudstack-management/setup/db/schema-440to441.sql
...
2014-10-24 14:01:55,293 DEBUG [c.c.u.d.ScriptRunner] (main:null) -- Fix
CLOUDSTACK-7624
2014-10-24 14:01:55,293 DEBUG [c.c.u.d.ScriptRunner] (main:null) ALTER
TABLE `cloud`.`configuration` MODIFY default_value varchar(8191), MODIFY
value varchar(8191)
2014-10-24 14:01:55,398 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating System Vm template IDs
2014-10-24 14:01:55,406 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating KVM System Vms
2014-10-24 14:01:55,410 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating XenServer System Vms
2014-10-24 14:01:55,414 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating VMware System Vms
2014-10-24 14:01:55,414 WARN  [c.c.u.d.Upgrade440to441] (main:null)
4.4.0 VMware SystemVm template not found. VMware hypervisor is not used,
so not failing upgrade
2014-10-24 14:01:55,415 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating Hyperv System Vms
2014-10-24 14:01:55,416 WARN  [c.c.u.d.Upgrade440to441] (main:null)
4.4.0 Hyperv SystemVm template not found. Hyperv hypervisor is not used,
so not failing upgrade
2014-10-24 14:01:55,416 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating LXC System Vms
2014-10-24 14:01:55,417 WARN  [c.c.u.d.Upgrade440to441] (main:null)
4.4.0 LXC SystemVm template not found. LXC hypervisor is not used, so
not failing upgrade
2014-10-24 14:01:55,417 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating System Vm Template IDs Complete
2014-10-24 14:01:55,525 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
Cleaning upgrades because all management server are now at the same version
2014-10-24 14:01:55,530 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null)
Upgrading to version 4.4.1...
2014-10-24 14:01:55,531 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
Cleanup upgrade Upgrade440to441 to upgrade from 4.4.0-4.4.1 to 4.4.1
2014-10-24 14:01:55,532 DEBUG [c.c.u.s.Script] (main:null) Looking for
db/schema-440to441-cleanup.sql in the classpath
2014-10-24 14:01:55,532 DEBUG [c.c.u.s.Script] (main:null) System
resource:
file:/usr/share/cloudstack-management/setup/db/schema-440to441-cleanup.sql
2014-10-24 14:01:55,532 DEBUG [c.c.u.s.Script] (main:null) Absolute path
=  /usr/share/cloudstack-management/setup/db/schema-440to441-cleanup.sql
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) --
Licensed to the Apache Software Foundation (ASF) under one
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) -- or
more contributor license agreements.  See the NOTICE file
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) --
distributed with this work for additional information
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) --
regarding copyright ownership.  The ASF licenses this file
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) -- to
you under the Apache License, Version 2.0 (the
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) --
License); you may not use this file except in compliance
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) -- with
the License.  You may obtain a copy of the

RE: UI: where has Acquire new IP button disappeared?

2014-10-24 Thread Gabor Apati-Nagy

Hi Lucian,

The View secondary IP button should be displayed next to the IP Address in 
the gridview. Clicking on that this page should display the Acquire new 
secondary IP button. I have tested this in master and we seem to have the same 
code in 4.4.
Could you double check this? It could be confusing that the first button is not 
in the heading, but is located in the grid.

Cheers,
Gabor


-Original Message-
From: Nux! [mailto:n...@li.nux.ro] 
Sent: 24 October 2014 09:44
To: dev@cloudstack.apache.org
Subject: Re: UI: where has Acquire new IP button disappeared?

Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7782 for this.

Anyone knows who we can bug for a fix?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Nux! n...@li.nux.ro
 To: dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 00:32:55
 Subject: UI: where has Acquire new IP button disappeared?

 Hi,
 
 Only now I notice that the option in the NIC tab of a VM 
 (Basic/Adv+SG) no longer has the Acquire secondary button, nor does it list 
 the Secondary IPs.
 I can set and see the extra IPs in cloudmonkey though if I run:
 
 add iptonic nicid=XXX
 list nics nicid=XXX virtualmachineid=XXX
 
 
 This is not OK ... alas I notice it too late. Promise to test more next 
 release.
 
 Any way I can get that back? I have people using the UI who rely on 
 this feature.
 
 Lucian
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro

[HELP] cloudstack 4.4.0 src build failed

2014-10-24 Thread zengfh2...@aliyun.com

您好：
 OS: CentOS6.3 x64
cloudstack: apache-cloudstack-4.4.0-src.tar.bz2

As building RPM，excute cloudstack-4.4.0/packaging/centos63/package.sh 
,the error as followed, please help me to resolve it, Thanks!

Failed tests: 
runUploadSslCertBadkeyAlgo(org.apache.cloudstack.network.lb.CertServiceTest) 
runUploadSslCertBadkeyPair(org.apache.cloudstack.network.lb.CertServiceTest) 
runUploadSslCertBadChain(org.apache.cloudstack.network.lb.CertServiceTest) 
runUploadSslCertNoRootCert(org.apache.cloudstack.network.lb.CertServiceTest) 
runUploadSslCertNoChain(org.apache.cloudstack.network.lb.CertServiceTest) 

Tests in error: 
runUploadSslCertWithCAChain(org.apache.cloudstack.network.lb.CertServiceTest): 
Error parsing certificate data Certificate expired or not valid 
runUploadSslCertSelfSignedNoPassword(org.apache.cloudstack.network.lb.CertServiceTest):
 Error parsing certificate data Certificate expired or not valid 
runUploadSslCertSelfSignedWithPassword(org.apache.cloudstack.network.lb.CertServiceTest):
 Error parsing certificate data Certificate expired or not valid 

Tests run: 139, Failures: 5, Errors: 3, Skipped: 1


[INFO]  
[INFO] Reactor Summary: 
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS 
[8.201s] 
[INFO] Apache CloudStack . SUCCESS [2.836s] 
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [1.335s] 
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [5.058s] 
[INFO] Apache CloudStack Utils ... SUCCESS [22.108s] 
[INFO] Apache CloudStack Framework ... SUCCESS [0.090s] 
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [13.717s] 
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [7.190s] 
[INFO] Apache CloudStack API . SUCCESS [24.591s] 
[INFO] Apache CloudStack Framework - REST  SUCCESS [4.550s] 
[INFO] Apache CloudStack Framework - IPC . SUCCESS [8.496s] 
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.058s] 
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [6.813s] 
[INFO] Apache CloudStack Framework - Security  SUCCESS [3.292s] 
[INFO] Apache CloudStack Core  SUCCESS [17.587s] 
[INFO] Apache CloudStack Agents .. SUCCESS [9.923s] 
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [4.526s] 
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [2.240s] 
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [22.376s] 
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [9.565s] 
[INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [5.471s] 
[INFO] Apache CloudStack Server .. FAILURE [1:16.272s] 
[INFO] Apache CloudStack Usage Server  SKIPPED 
[INFO] Apache XenSource XAPI . SKIPPED 
[INFO] Apache CloudStack Cloud Engine Orchestration Component SKIPPED 
[INFO] Apache CloudStack Cloud Services .. SKIPPED 
[INFO] Apache CloudStack Secondary Storage ... SKIPPED 
[INFO] Apache CloudStack Secondary Storage Service ... SKIPPED 
[INFO] Apache CloudStack Engine Storage Component  SKIPPED 
[INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED 
[INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED 
[INFO] Apache CloudStack Engine Storage Data Motion Component SKIPPED 
[INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED 
[INFO] Apache CloudStack Engine Storage Snapshot Component SKIPPED 
[INFO] Apache CloudStack Cloud Engine API  SKIPPED 
[INFO] Apache CloudStack Cloud Engine Service  SKIPPED 
[INFO] Apache CloudStack Plugin POM .. SKIPPED 
[INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED 
[INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED 
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED 
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor SKIPPED 
[INFO] Apache CloudStack Plugin - Explicit Dedication Processor SKIPPED 
[INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment Planner 
SKIPPED 
[INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner SKIPPED 
[INFO] Apache CloudStack Plugin - Implicit Dedication Planner SKIPPED 
[INFO] Apache CloudStack Plugin - Skip Heurestics Planner SKIPPED 
[INFO] Apache CloudStack Plugin - Host Allocator Random .. SKIPPED 
[INFO] Apache CloudStack Plugin - Dedicated Resources  SKIPPED 
[INFO] Apache CloudStack Plugin - Hypervisor OracleVM  SKIPPED 
[INFO] Apache CloudStack Plugin - Open vSwitch ... SKIPPED 
[INFO] Apache CloudStack Plugin - Hypervisor

Re: UI: where has Acquire new IP button disappeared?

Hello,

This might sound stupid, but what is this gridview you are talking of?
This is what I am seeing http://imgur.com/9fl6ERD

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Gabor Apati-Nagy gabor.apati-n...@citrix.com
 To: dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 14:26:40
 Subject: RE: UI: where has Acquire new IP button disappeared?

 Hi Lucian,
 
 The View secondary IP button should be displayed next to the IP Address in 
 the
 gridview. Clicking on that this page should display the Acquire new secondary
 IP button. I have tested this in master and we seem to have the same code in
 4.4.
 Could you double check this? It could be confusing that the first button is 
 not
 in the heading, but is located in the grid.
 
 Cheers,
 Gabor
 
 
 -Original Message-
 From: Nux! [mailto:n...@li.nux.ro]
 Sent: 24 October 2014 09:44
 To: dev@cloudstack.apache.org
 Subject: Re: UI: where has Acquire new IP button disappeared?
 
 Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7782 for this.
 
 Anyone knows who we can bug for a fix?
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro
 
 - Original Message -
 From: Nux! n...@li.nux.ro
 To: dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 00:32:55
 Subject: UI: where has Acquire new IP button disappeared?
 
 Hi,
 
 Only now I notice that the option in the NIC tab of a VM
 (Basic/Adv+SG) no longer has the Acquire secondary button, nor does it list
 the Secondary IPs.
 I can set and see the extra IPs in cloudmonkey though if I run:
 
 add iptonic nicid=XXX
 list nics nicid=XXX virtualmachineid=XXX
 
 
 This is not OK ... alas I notice it too late. Promise to test more next 
 release.
 
 Any way I can get that back? I have people using the UI who rely on
 this feature.
 
 Lucian
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
  www.nux.ro

[GitHub] cloudstack pull request: listDirectory method updated to use Objec...

2014-10-24 Thread santhoshdaivajna

GitHub user santhoshdaivajna opened a pull request:

https://github.com/apache/cloudstack/pull/25

listDirectory method updated to use ObjectListing.isTruncated().

Because buckets can contain a virtually unlimited number of keys, the
complete results of a list query can be extremely large. To manage large
result sets, Amazon S3 uses pagination to split them into multiple
responses.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/santhoshdaivajna/cloudstack master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/25.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #25


commit 820d99344b1f3c07ee1d41fdeb1ec82a09acc292
Author: santhosh santh...@47line.com
Date:   2014-10-24T15:45:29Z

listDirectory method updated to use ObjectListing.isTruncated().

Because buckets can contain a virtually unlimited number of keys, the
complete results of a list query can be extremely large. To manage large
result sets, Amazon S3 uses pagination to split them into multiple
responses.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [HELP] cloudstack 4.4.0 src build failed

Hello,

Any reason you are not building 4.4.1? Perhaps it's fixed there.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: zengfh2...@aliyun.com
 To: dev dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 15:13:19
 Subject: [HELP] cloudstack 4.4.0 src build failed

 您好：
 OS: CentOS6.3 x64
cloudstack: apache-cloudstack-4.4.0-src.tar.bz2

As building RPM，excute cloudstack-4.4.0/packaging/centos63/package.sh 
 ,the error
as followed, please help me to resolve it, Thanks!
 
 Failed tests:
 runUploadSslCertBadkeyAlgo(org.apache.cloudstack.network.lb.CertServiceTest)
 runUploadSslCertBadkeyPair(org.apache.cloudstack.network.lb.CertServiceTest)
 runUploadSslCertBadChain(org.apache.cloudstack.network.lb.CertServiceTest)
 runUploadSslCertNoRootCert(org.apache.cloudstack.network.lb.CertServiceTest)
 runUploadSslCertNoChain(org.apache.cloudstack.network.lb.CertServiceTest)
 
 Tests in error:
 runUploadSslCertWithCAChain(org.apache.cloudstack.network.lb.CertServiceTest):
 Error parsing certificate data Certificate expired or not valid
 runUploadSslCertSelfSignedNoPassword(org.apache.cloudstack.network.lb.CertServiceTest):
 Error parsing certificate data Certificate expired or not valid
 runUploadSslCertSelfSignedWithPassword(org.apache.cloudstack.network.lb.CertServiceTest):
 Error parsing certificate data Certificate expired or not valid
 
 Tests run: 139, Failures: 5, Errors: 3, Skipped: 1
 
 
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS
 [8.201s]
 [INFO] Apache CloudStack . SUCCESS [2.836s]
 [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [1.335s]
 [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [5.058s]
 [INFO] Apache CloudStack Utils ... SUCCESS [22.108s]
 [INFO] Apache CloudStack Framework ... SUCCESS [0.090s]
 [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [13.717s]
 [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [7.190s]
 [INFO] Apache CloudStack API . SUCCESS [24.591s]
 [INFO] Apache CloudStack Framework - REST  SUCCESS [4.550s]
 [INFO] Apache CloudStack Framework - IPC . SUCCESS [8.496s]
 [INFO] Apache CloudStack Cloud Engine  SUCCESS [0.058s]
 [INFO] Apache CloudStack Cloud Engine API  SUCCESS [6.813s]
 [INFO] Apache CloudStack Framework - Security  SUCCESS [3.292s]
 [INFO] Apache CloudStack Core  SUCCESS [17.587s]
 [INFO] Apache CloudStack Agents .. SUCCESS [9.923s]
 [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [4.526s]
 [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [2.240s]
 [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [22.376s]
 [INFO] Apache CloudStack Framework - Jobs  SUCCESS [9.565s]
 [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [5.471s]
 [INFO] Apache CloudStack Server .. FAILURE [1:16.272s]
 [INFO] Apache CloudStack Usage Server  SKIPPED
 [INFO] Apache XenSource XAPI . SKIPPED
 [INFO] Apache CloudStack Cloud Engine Orchestration Component SKIPPED
 [INFO] Apache CloudStack Cloud Services .. SKIPPED
 [INFO] Apache CloudStack Secondary Storage ... SKIPPED
 [INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
 [INFO] Apache CloudStack Engine Storage Component  SKIPPED
 [INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
 [INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
 [INFO] Apache CloudStack Engine Storage Data Motion Component SKIPPED
 [INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
 [INFO] Apache CloudStack Engine Storage Snapshot Component SKIPPED
 [INFO] Apache CloudStack Cloud Engine API  SKIPPED
 [INFO] Apache CloudStack Cloud Engine Service  SKIPPED
 [INFO] Apache CloudStack Plugin POM .. SKIPPED
 [INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED
 [INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED
 [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED
 [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor SKIPPED
 [INFO] Apache CloudStack Plugin - Explicit Dedication Processor SKIPPED
 [INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment Planner
 SKIPPED
 [INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner SKIPPED
 [INFO] Apache CloudStack Plugin - Implicit Dedication Planner SKIPPED
 [INFO] Apache CloudStack Plugin

Re: [PROPOSAL] Move to github PR only during moratorium on commit

Yeah, Daan, the approach you describe sounds like a reasonable substitute
for what I have in that diagram.

My main concern was CI running before the code was checked into the real
branch from the staging branch.

On Fri, Oct 24, 2014 at 1:12 AM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

 Mike, Why have everybody work on the same branch. people can work on
 their own branch and when they are done they can rebase on the tip see
 ci success and then merge. The problem with forward branches is
 abandoned work or work that for some reason shouldn't go in 'this'
 release. it will remain there.

 On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski
 mike.tutkow...@solidfire.com wrote:
  Are we talking about something like what I drew up here?:
 
  http://i.imgur.com/UgPtJGY.png
 
  In this scheme, the -forward branches are the ones you can directly
 commit
  to while their peers without the -forward are the ones that code gets
  merged to from its corresponding -forward branch.
 
  CI is performed on the -forward branches before any merging takes place.
 
  The merge recorded concept I put in the diagram refers to the situation
  where you have a commit on a branch like 4.5, but you do NOT want it to
  move forward to master.
 
  I don't know if Git has such a concept, but SVN calls this kind of a
  merge merge recording. Merge recording essentially means you do not
 want
  those changes brought forward to the specified branch (not now and not
 with
  future merges other people or yourself may do).
 
 
 
  On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi 
  animesh.chaturv...@citrix.com wrote:
 
 
 
   -Original Message-
   From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
   Sent: Thursday, October 23, 2014 1:31 AM
   To: dev
   Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
   commit
  
   On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav
   rohit.ya...@shapeblue.com wrote:
Hi,
   
On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
   animesh.chaturv...@citrix.com wrote:
   ...
The approach for fixing issues in release branch first and master
  later is
   not practical as we may miss out commits not made into master and
 future
   release regressing without the fixes.
   
By the same logic, if we fix by default on master only, the release
  branch
   may miss out commits.
  
   I sttrongly disagree with Animesh here and think Rohit is overlooking
 a
   simple fact. At the moment the branches are for 'stabalizing'.
   Fixing on master first is in direct contradiction with that.
  
   We have not been stabalizing 4.4. it contains bug that have during the
   release periods for 4.4.0 and 4.4.1 been fixed on master. That
 shouldn't
   have been allowed to happen.
  [Animesh] Clearly we have disagreement. To avoid the issue that you
  mention David had created forward branch for 4.2 and I found it useful
 and
  continued with that approach in 4.3. With forward branch which are
 really
  staging it was a simple merge of forward back to release branch. The
 other
  approach of merging release branch into master work as well but in my
  opinion keeping master as the default branch (with protection of course
 )
  is simpler to understand and creates less confusion
 
 
 
 
  --
  *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*™*



 --
 Daan




-- 
*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: commits on 4.5

Thanks, Leo

Yeah, being able to essentially mark a commit as NOT needing to be merged
(in fact, merging is wrong in this case) to a newer branch is key, I think,
to helping solve our branching issues.

On Fri, Oct 24, 2014 at 12:36 AM, Leo Simons lsim...@schubergphilis.com
wrote:

Hey Mike,

In git you accomplish these kinds of things with merge strategies. There’s
a lot to choose from. What you’re describing sounds a bit like a variant on
the “theirs” strategy. You can also do a recursive merge with a “theirs”
conflict resolution choice, and there’s many other options. (see below)

I don’t think it should be used though; there isn’t a tool problem here,
it’s a communication problem and a priority problem causing a quality
problem.

cheers,

Leo

4 git merge --help
...
MERGE STRATEGIES
The merge mechanism (git merge and git pull commands) allows the
backend merge strategies to be chosen with -s option. Some
strategies
can also take their own options, which can be passed by giving
-Xoption arguments to git merge and/or git pull.
...
recursive
This can only resolve two heads using a 3-way merge algorithm.
When
there is more than one common ancestor that can be used for
3-way
merge, it creates a merged tree of the common ancestors and uses
that as the reference tree for the 3-way merge. This has been
reported to result in fewer merge conflicts without causing
mismerges by tests done on actual merge commits taken from Linux
2.6 kernel development history. Additionally this can detect and
handle merges involving renames. This is the default merge
strategy
when pulling or merging one branch.

The recursive strategy can take the following options:

ours
This option forces conflicting hunks to be auto-resolved
cleanly by favoring our version. Changes from the other tree
that do not conflict with our side are reflected to the
merge
result. For a binary file, the entire contents are taken
from
our side.

This should not be confused with the ours merge strategy,
which
does not even look at what the other tree contains at all.
It
discards everything the other tree did, declaring our
history
contains all that happened in it.

theirs
This is the opposite of ours.
...
octopus
This resolves cases with more than two heads, but refuses to do
a
complex merge that needs manual resolution. It is primarily
meant
to be used for bundling topic branch heads together. This is the
default merge strategy when pulling or merging more than one
branch.

subtree
This is a modified recursive strategy. When merging trees A and
B,
if B corresponds to a subtree of A, B is first adjusted to match
the tree structure of A, instead of reading the trees at the
same
level. This adjustment is also done to the common ancestor tree.
...

On Oct 24, 2014, at 2:29 AM, Mike Tutkowski mike.tutkow...@solidfire.com
wrote:

Maybe we need something like this in Git (maybe it's already there?):

http://stackoverflow.com/questions/18074697/subversion-mark-as-merged-without-changing-anything

The ability to record a commit has having been merged to another branch,
but nothing was really merged.

Then when you checked code into 4.5 that shouldn't be in master, you
simply
do a merge --record-only (in SVN terminology).

On Thu, Oct 23, 2014 at 3:37 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:

If we just did merges (instead of cherry picks) to 4.5, does Git allow
us
to ONLY merge that particular (merge) commit from 4.5 to master?

In other words, I'd want to make sure we were only merging from 4.5 to
master what we want to (and, as I mentioned earlier, not bring along
commits to 4.5 that should not be in master).

In SVN you could do a sort-of empty merge from branch x to a later
branch (or set of branches), which basically told SVN that that commit
was
not supposed to be brought forward. Then when the next person came along
and committed to branch x and merged forward, SVN would not take your
changes along for the ride.

On Thu, Oct 23, 2014 at 3:30 PM, David Nalley da...@gnsa.us wrote:

RE: Urgent. Importing certificate to CS 4.3.1 using GUI

2014-10-24 Thread Stephen Turner

I'm still puzzled why it would have worked on my Firefox too. There must be 
some difference in configuration.

-- 
Stephen Turner


-Original Message-
From: Amogh Vasekar [mailto:amogh.vase...@citrix.com] 
Sent: 23 October 2014 16:18
To: dev@cloudstack.apache.org
Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI

Hi,

He certainly is :-)
Can you share the screenshot of firebug request and response so as to diagnose 
better?
Also, was the upload call made as admin or regular user?

Thanks,
Amogh

On 10/23/14 3:27 AM, Suresh Sadhu suresh.sa...@citrix.com wrote:

Thanks France, We(France myself) have diagnosed the problem and in 
firefox after  uploading the certificate it shows HTTP Error 501 Not 
implemented error in api response(firebug  output )and

The request is not reaching the server  itself(CS management server and 
api server logs not shown any API request details ..) so probably the 
failure  is due to client side settings or  due to some other problem.

We need to identify  reasons for HTTP error 501 not implemented.
http://www.checkupdown.com/status/E501.html

Amogh/Nitin : can you please check in which cases this 501 not 
implemented will occur.

Regards
Sadhu

 





-Original Message-
From: France [mailto:mailingli...@isg.si]
Sent: 23 October 2014 15:43
To: dev@cloudstack.apache.org
Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI

Suresh is awesome. Hope Citrix knows that. :-) We diagnosed the issue 
with ACS 4.3.1 and Firefox browser, and Suresh will update this thread 
with details.

Regards,
F.


On 15 Oct 2014, at 13:55, France mailingli...@isg.si wrote:

 Because i do not check this mailing list every day due to actual 
payed work, i have not seen your request.
 I will contact you right now.
 
 
 On 08 Oct 2014, at 20:10, Suresh Sadhu suresh.sa...@citrix.com wrote:
 
 Sure Nitin and as of now I didn't hear anything from France.
 
 Regards
 sadhu
 
 -Original Message-
 From: Nitin Mehta [mailto:nitin.me...@citrix.com]
 Sent: 08 October 2014 21:57
 To: dev@cloudstack.apache.org
 Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI
 
 Sadhu - Please do update the thread once you have some observation.
 Thanks
 
 -Nitin
 
 On 08/10/14 5:27 AM, Suresh Sadhu suresh.sa...@citrix.com wrote:
 
 HI France,
 
 I can help  today .
 My personal email id is mailtosa...@gmail.com
 
 
 Regards
 sadhu
 
 -Original Message-
 From: Stephen Turner [mailto:stephen.tur...@citrix.com]
 Sent: 08 October 2014 17:43
 To: dev@cloudstack.apache.org
 Subject: RE: Urgent. Importing certificate to CS 4.3.1 using GUI
 
 France, I'm sorry, but I'm about to go away for three weeks, and 
 I'm not going to have time to work on this.
 
 Is there anyone else who could help France? Is anyone else seeing 
 the problem, because I couldn't reproduce it?
 
 --
 Stephen Turner
 
 
 
 -Original Message-
 From: France [mailto:mailingli...@isg.si]
 Sent: 08 October 2014 11:44
 To: dev@cloudstack.apache.org
 Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI
 
 Send me a private email and you can test it on my exact system with 
 all development options turned on as you wish.
 We will do it via remote screen sharing, like VNC, RDP, Teamviewer, ..
 
 Regards,
 F.
 
 On 26 Sep 2014, at 16:53, Stephen Turner 
 stephen.tur...@citrix.com
 wrote:
 
 I'm afraid I couldn't reproduce this, even with your certificate 
 and private key. Everything I tried, I got Update Certiciate 
 [sic] Succeeded.
 
 Does anyone else have a convenient 4.3 and FF 32 that they can try 
 and repro this with?
 
 France, if you open the developer tools in Firefox and do this 
 again, do you see any errors?
 
 --
 Stephen Turner
 
 
 -Original Message-
 From: France [mailto:mailingli...@isg.si]
 Sent: 26 September 2014 13:44
 To: Stephen Turner
 Cc: dev@cloudstack.apache.org
 Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI
 
 Issue has been created.
 I would assign it to you, but lack credentials?
 
 https://issues.apache.org/jira/browse/CLOUDSTACK-7635
 
 Regards,
 F.
 
 On 26 Sep 2014, at 11:47, Stephen Turner 
 stephen.tur...@citrix.com
 wrote:
 
 Yes, I would like a bug report for this. Please assign it to me.
 This bit of UI has been rewritten on master, but it should work 
 the same in all browsers, so I'd like to investigate whether it's 
 fixed on master, and also whether there are any other similar 
 controls that aren't working in FF 32.
 
 If you can attach a public key and other data that illustrates 
 the problem, that would be great just to make sure that we can repro it.
 Thank you.
 
 --
 Stephen Turner
 
 
 -Original Message-
 From: France [mailto:mailingli...@isg.si]
 Sent: 25 September 2014 14:52
 To: dev@cloudstack.apache.org
 Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI
 
 There is a bug in ACS 4.3.1 GUI.
 The before mentioned process did not work with Firefox 32.0.2, 
 while it worked on latest

Re: [HELP] cloudstack 4.4.0 src build failed

2014-10-24 Thread Ian Duffy

This looks like the certificate issue that has been mentioned in another
thread on the list.

On 24 October 2014 16:48, Nux! n...@li.nux.ro wrote:

 Hello,

 Any reason you are not building 4.4.1? Perhaps it's fixed there.

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
  From: zengfh2...@aliyun.com
  To: dev dev@cloudstack.apache.org
  Sent: Friday, 24 October, 2014 15:13:19
  Subject: [HELP] cloudstack 4.4.0 src build failed

  您好：
  OS: CentOS6.3 x64
 cloudstack: apache-cloudstack-4.4.0-src.tar.bz2
 
 As building RPM，excute
 cloudstack-4.4.0/packaging/centos63/package.sh ,the error
 as followed, please help me to resolve it, Thanks!
 
  Failed tests:
 
 runUploadSslCertBadkeyAlgo(org.apache.cloudstack.network.lb.CertServiceTest)
 
 runUploadSslCertBadkeyPair(org.apache.cloudstack.network.lb.CertServiceTest)
 
 runUploadSslCertBadChain(org.apache.cloudstack.network.lb.CertServiceTest)
 
 runUploadSslCertNoRootCert(org.apache.cloudstack.network.lb.CertServiceTest)
  runUploadSslCertNoChain(org.apache.cloudstack.network.lb.CertServiceTest)
 
  Tests in error:
 
 runUploadSslCertWithCAChain(org.apache.cloudstack.network.lb.CertServiceTest):
  Error parsing certificate data Certificate expired or not valid
 
 runUploadSslCertSelfSignedNoPassword(org.apache.cloudstack.network.lb.CertServiceTest):
  Error parsing certificate data Certificate expired or not valid
 
 runUploadSslCertSelfSignedWithPassword(org.apache.cloudstack.network.lb.CertServiceTest):
  Error parsing certificate data Certificate expired or not valid
 
  Tests run: 139, Failures: 5, Errors: 3, Skipped: 1
 
 
  [INFO]
 
  [INFO] Reactor Summary:
  [INFO]
  [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration
 SUCCESS
  [8.201s]
  [INFO] Apache CloudStack . SUCCESS
 [2.836s]
  [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS
 [1.335s]
  [INFO] Apache CloudStack Framework - Managed Context . SUCCESS
 [5.058s]
  [INFO] Apache CloudStack Utils ... SUCCESS
 [22.108s]
  [INFO] Apache CloudStack Framework ... SUCCESS
 [0.090s]
  [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
 [13.717s]
  [INFO] Apache CloudStack Framework - Configuration ... SUCCESS
 [7.190s]
  [INFO] Apache CloudStack API . SUCCESS
 [24.591s]
  [INFO] Apache CloudStack Framework - REST  SUCCESS
 [4.550s]
  [INFO] Apache CloudStack Framework - IPC . SUCCESS
 [8.496s]
  [INFO] Apache CloudStack Cloud Engine  SUCCESS
 [0.058s]
  [INFO] Apache CloudStack Cloud Engine API  SUCCESS
 [6.813s]
  [INFO] Apache CloudStack Framework - Security  SUCCESS
 [3.292s]
  [INFO] Apache CloudStack Core  SUCCESS
 [17.587s]
  [INFO] Apache CloudStack Agents .. SUCCESS
 [9.923s]
  [INFO] Apache CloudStack Framework - Clustering .. SUCCESS
 [4.526s]
  [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
 [2.240s]
  [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS
 [22.376s]
  [INFO] Apache CloudStack Framework - Jobs  SUCCESS
 [9.565s]
  [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS
 [5.471s]
  [INFO] Apache CloudStack Server .. FAILURE
 [1:16.272s]
  [INFO] Apache CloudStack Usage Server  SKIPPED
  [INFO] Apache XenSource XAPI . SKIPPED
  [INFO] Apache CloudStack Cloud Engine Orchestration Component SKIPPED
  [INFO] Apache CloudStack Cloud Services .. SKIPPED
  [INFO] Apache CloudStack Secondary Storage ... SKIPPED
  [INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
  [INFO] Apache CloudStack Engine Storage Component  SKIPPED
  [INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
  [INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
  [INFO] Apache CloudStack Engine Storage Data Motion Component SKIPPED
  [INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
  [INFO] Apache CloudStack Engine Storage Snapshot Component SKIPPED
  [INFO] Apache CloudStack Cloud Engine API  SKIPPED
  [INFO] Apache CloudStack Cloud Engine Service  SKIPPED
  [INFO] Apache CloudStack Plugin POM .. SKIPPED
  [INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED
  [INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED
  [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED
  [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor SKIPPED
  [INFO] Apache CloudStack Plugin - Explicit Dedication Processor SKIPPED
  [INFO] Apache

Re: UI: where has Acquire new IP button disappeared?

Hello,

This might sound stupid, but what is this gridview you are talking of?
This is what I am seeing http://imgur.com/9fl6ERD

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Gabor Apati-Nagy gabor.apati-n...@citrix.com
 To: dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 14:26:40
 Subject: RE: UI: where has Acquire new IP button disappeared?

 Hi Lucian,
 
 The View secondary IP button should be displayed next to the IP Address in 
 the
 gridview. Clicking on that this page should display the Acquire new secondary
 IP button. I have tested this in master and we seem to have the same code in
 4.4.
 Could you double check this? It could be confusing that the first button is 
 not
 in the heading, but is located in the grid.
 
 Cheers,
 Gabor
 
 
 -Original Message-
 From: Nux! [mailto:n...@li.nux.ro]
 Sent: 24 October 2014 09:44
 To: dev@cloudstack.apache.org
 Subject: Re: UI: where has Acquire new IP button disappeared?
 
 Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7782 for this.
 
 Anyone knows who we can bug for a fix?
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro
 
 - Original Message -
 From: Nux! n...@li.nux.ro
 To: dev@cloudstack.apache.org
 Sent: Friday, 24 October, 2014 00:32:55
 Subject: UI: where has Acquire new IP button disappeared?
 
 Hi,
 
 Only now I notice that the option in the NIC tab of a VM
 (Basic/Adv+SG) no longer has the Acquire secondary button, nor does it list
 the Secondary IPs.
 I can set and see the extra IPs in cloudmonkey though if I run:
 
 add iptonic nicid=XXX
 list nics nicid=XXX virtualmachineid=XXX
 
 
 This is not OK ... alas I notice it too late. Promise to test more next 
 release.
 
 Any way I can get that back? I have people using the UI who rely on
 this feature.
 
 Lucian
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
  www.nux.ro

RE: [HELP] cloudstack 4.4.0 src build failed

2014-10-24 Thread Frank Zhang

As you are building from source tarball, the simplest way to fix is to delete 
CertServiceTest.java

 -Original Message-
 From: Ian Duffy [mailto:i...@ianduffy.ie]
 Sent: Friday, October 24, 2014 9:54 AM
 To: CloudStack Dev
 Subject: Re: [HELP] cloudstack 4.4.0 src build failed
 
 This looks like the certificate issue that has been mentioned in another 
 thread
 on the list.
 
 On 24 October 2014 16:48, Nux! n...@li.nux.ro wrote:
 
  Hello,
 
  Any reason you are not building 4.4.1? Perhaps it's fixed there.
 
  --
  Sent from the Delta quadrant using Borg technology!
 
  Nux!
  www.nux.ro
 
  - Original Message -
   From: zengfh2...@aliyun.com
   To: dev dev@cloudstack.apache.org
   Sent: Friday, 24 October, 2014 15:13:19
   Subject: [HELP] cloudstack 4.4.0 src build failed
 
   您好：
   OS: CentOS6.3 x64
  cloudstack: apache-cloudstack-4.4.0-src.tar.bz2
  
  As building RPM，excute
  cloudstack-4.4.0/packaging/centos63/package.sh ,the error
  as followed, please help me to resolve it, Thanks!
  
   Failed tests:
  
  runUploadSslCertBadkeyAlgo(org.apache.cloudstack.network.lb.CertServic
  eTest)
  
  runUploadSslCertBadkeyPair(org.apache.cloudstack.network.lb.CertServic
  eTest)
  
  runUploadSslCertBadChain(org.apache.cloudstack.network.lb.CertServiceT
  est)
  
  runUploadSslCertNoRootCert(org.apache.cloudstack.network.lb.CertServic
  eTest)
   runUploadSslCertNoChain(org.apache.cloudstack.network.lb.CertService
   Test)
  
   Tests in error:
  
 
 runUploadSslCertWithCAChain(org.apache.cloudstack.network.lb.CertServiceTe
 st):
   Error parsing certificate data Certificate expired or not valid
  
 
 runUploadSslCertSelfSignedNoPassword(org.apache.cloudstack.network.lb.Cert
 ServiceTest):
   Error parsing certificate data Certificate expired or not valid
  
 
 runUploadSslCertSelfSignedWithPassword(org.apache.cloudstack.network.lb.Ce
 rtServiceTest):
   Error parsing certificate data Certificate expired or not valid
  
   Tests run: 139, Failures: 5, Errors: 3, Skipped: 1
  
  
   [INFO]
  --
  --
   [INFO] Reactor Summary:
   [INFO]
   [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration
  SUCCESS
   [8.201s]
   [INFO] Apache CloudStack . SUCCESS
  [2.836s]
   [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS
  [1.335s]
   [INFO] Apache CloudStack Framework - Managed Context . SUCCESS
  [5.058s]
   [INFO] Apache CloudStack Utils ... SUCCESS
  [22.108s]
   [INFO] Apache CloudStack Framework ... SUCCESS
  [0.090s]
   [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
  [13.717s]
   [INFO] Apache CloudStack Framework - Configuration ... SUCCESS
  [7.190s]
   [INFO] Apache CloudStack API . SUCCESS
  [24.591s]
   [INFO] Apache CloudStack Framework - REST  SUCCESS
  [4.550s]
   [INFO] Apache CloudStack Framework - IPC . SUCCESS
  [8.496s]
   [INFO] Apache CloudStack Cloud Engine  SUCCESS
  [0.058s]
   [INFO] Apache CloudStack Cloud Engine API  SUCCESS
  [6.813s]
   [INFO] Apache CloudStack Framework - Security  SUCCESS
  [3.292s]
   [INFO] Apache CloudStack Core  SUCCESS
  [17.587s]
   [INFO] Apache CloudStack Agents .. SUCCESS
  [9.923s]
   [INFO] Apache CloudStack Framework - Clustering .. SUCCESS
  [4.526s]
   [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
  [2.240s]
   [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS
  [22.376s]
   [INFO] Apache CloudStack Framework - Jobs  SUCCESS
  [9.565s]
   [INFO] Apache CloudStack Cloud Engine Internal Components API
   SUCCESS
  [5.471s]
   [INFO] Apache CloudStack Server .. FAILURE
  [1:16.272s]
   [INFO] Apache CloudStack Usage Server  SKIPPED
   [INFO] Apache XenSource XAPI . SKIPPED
   [INFO] Apache CloudStack Cloud Engine Orchestration Component
   SKIPPED [INFO] Apache CloudStack Cloud Services ..
   SKIPPED [INFO] Apache CloudStack Secondary Storage ...
   SKIPPED [INFO] Apache CloudStack Secondary Storage Service ...
   SKIPPED [INFO] Apache CloudStack Engine Storage Component 
   SKIPPED [INFO] Apache CloudStack Engine Storage Volume Component .
   SKIPPED [INFO] Apache CloudStack Engine Storage Image Component ..
   SKIPPED [INFO] Apache CloudStack Engine Storage Data Motion
   Component SKIPPED [INFO] Apache CloudStack Engine Storage Cache
   Component .. SKIPPED [INFO] Apache CloudStack Engine Storage
   Snapshot Component SKIPPED [INFO] Apache CloudStack Cloud Engine API
    SKIPPED [INFO] Apache CloudStack Cloud Engine
   Service  SKIPPED

Re: [PROPOSAL] Move to github PR only during moratorium on commit

Right, we just need to make sure CI comes into play before the merge.

Hence my earlier reply to what Daan mention:

My main concern was CI running before the code was checked into the real
branch from the staging branch.

On Fri, Oct 24, 2014 at 12:28 PM, David Nalley da...@gnsa.us wrote:

 On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com
 wrote:
  Mike, Why have everybody work on the same branch. people can work on
  their own branch and when they are done they can rebase on the tip see
  ci success and then merge. The problem with forward branches is
  abandoned work or work that for some reason shouldn't go in 'this'
  release. it will remain there.
 

 CI really needs to happen before the merge occurs, IMO. Backing out
 merges, in my experience, is incredibly painful. And typically this
 means that someone else is going to have to clean up the mess after
 someone merges.




-- 
*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: [PROPOSAL] Move to github PR only during moratorium on commit

2014-10-24 Thread David Nalley

On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote:
 Mike, Why have everybody work on the same branch. people can work on
 their own branch and when they are done they can rebase on the tip see
 ci success and then merge. The problem with forward branches is
 abandoned work or work that for some reason shouldn't go in 'this'
 release. it will remain there.


CI really needs to happen before the merge occurs, IMO. Backing out
merges, in my experience, is incredibly painful. And typically this
means that someone else is going to have to clean up the mess after
someone merges.

Jenkins build is back to normal : build-4.5 #43

2014-10-24 Thread jenkins

See http://jenkins.buildacloud.org/job/build-4.5/43/changes

Pulling Resource usage for domain or account

2014-10-24 Thread Logan Barfield

We have a cluster that is dedicated to a specific domain, and that domain
has resource limits set.

What would be the best way to display the currently utilized resources to
the user of that domain?

It's fairly easy with an API call to get the Max for each resource, but
so far I've been unable to find a good way to grab the currently utilized
resources (memory, primary storage, secondary storage) via the Domain-Admin
or User APIs.

I can do it via the Admin API, but even then it takes a few different calls
to grab the data before cleaning it up and formatting it.

Re: [PROPOSAL] Move to github PR only during moratorium on commit

mobile dev with bilingual spelling checker used (read at your own risk)
Op 24 okt. 2014 20:30 schreef David Nalley da...@gnsa.us:

 On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
  Mike, Why have everybody work on the same branch. people can work on
  their own branch and when they are done they can rebase on the tip see
  ci success and then merge. The problem with forward branches is
  abandoned work or work that for some reason shouldn't go in 'this'
  release. it will remain there.
 

 CI really needs to happen before the merge occurs, IMO.
Yes, that is exactly what i am saying
Backing out
 merges, in my experience, is incredibly painful. And typically this
 means that someone else is going to have to clean up the mess after
 someone merges.
and this is also what is wrong with the forward branches. It happened there
as well.

Re: [PROPOSAL] Move to github PR only during moratorium on commit

We do run ci on branches!

mobile dev with bilingual spelling checker used (read at your own risk)
Op 24 okt. 2014 20:38 schreef Mike Tutkowski mike.tutkow...@solidfire.com
:

 Right, we just need to make sure CI comes into play before the merge.

 Hence my earlier reply to what Daan mention:

 My main concern was CI running before the code was checked into the real
 branch from the staging branch.

 On Fri, Oct 24, 2014 at 12:28 PM, David Nalley da...@gnsa.us wrote:

  On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland daan.hoogl...@gmail.com
  wrote:
   Mike, Why have everybody work on the same branch. people can work on
   their own branch and when they are done they can rebase on the tip see
   ci success and then merge. The problem with forward branches is
   abandoned work or work that for some reason shouldn't go in 'this'
   release. it will remain there.
  
 
  CI really needs to happen before the merge occurs, IMO. Backing out
  merges, in my experience, is incredibly painful. And typically this
  means that someone else is going to have to clean up the mess after
  someone merges.
 



 --
 *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: [PROPOSAL] Move to github PR only during moratorium on commit

Cool...so, it sounds like any branch we create in the repo will
automatically have CI run against it post each commit.

How do you know when CI has completed and what the results are?

At that point, you could treat your own branch (as Daan says) as the
forward branch. Once CI has been successful, you can merge your code to,
say, 4.5 (or the RM can).

We then need a protocol for when we merge to 4.5 from our own branch, but
don't want to have those changes in master.

If we do want those changes, of course we can just merge from 4.5 to master.

On Fri, Oct 24, 2014 at 2:45 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:

 We do run ci on branches!

 mobile dev with bilingual spelling checker used (read at your own risk)
 Op 24 okt. 2014 20:38 schreef Mike Tutkowski 
 mike.tutkow...@solidfire.com
 :

  Right, we just need to make sure CI comes into play before the merge.
 
  Hence my earlier reply to what Daan mention:
 
  My main concern was CI running before the code was checked into the
 real
  branch from the staging branch.
 
  On Fri, Oct 24, 2014 at 12:28 PM, David Nalley da...@gnsa.us wrote:
 
   On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland 
 daan.hoogl...@gmail.com
   wrote:
Mike, Why have everybody work on the same branch. people can work on
their own branch and when they are done they can rebase on the tip
 see
ci success and then merge. The problem with forward branches is
abandoned work or work that for some reason shouldn't go in 'this'
release. it will remain there.
   
  
   CI really needs to happen before the merge occurs, IMO. Backing out
   merges, in my experience, is incredibly painful. And typically this
   means that someone else is going to have to clean up the mess after
   someone merges.
  
 
 
 
  --
  *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*™*
 




-- 
*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: Pulling Resource usage for domain or account

2014-10-24 Thread Nitin Mehta

I think listAccounts api also gives that info ? If this is not easy to
find please find an enhancement on JIRA. Thanks.

-Nitin 

On 24/10/14 11:51 AM, Logan Barfield lbarfi...@tqhosting.com wrote:

We have a cluster that is dedicated to a specific domain, and that domain
has resource limits set.

What would be the best way to display the currently utilized resources to
the user of that domain?

It's fairly easy with an API call to get the Max for each resource, but
so far I've been unable to find a good way to grab the currently utilized
resources (memory, primary storage, secondary storage) via the
Domain-Admin
or User APIs.

I can do it via the Admin API, but even then it takes a few different
calls
to grab the data before cleaning it up and formatting it.

Re: vm.password.length issue in 4.4.1-SNAPSHOT

2014-10-24 Thread Amogh Vasekar

Hi Laszlo,

Any comments on the below? I agree adding 3 characters is a bug and
willing to fix it.

In addition, Ian, I believe we should set a minimum allowed value for the
config value vm.password.length. Any objections to setting the minimum to
8, the previous default?

Thanks
Amogh

On 10/13/14 5:34 PM, Ian Duffy i...@ianduffy.ie wrote:

The only other usage of it is within
server/src/com/cloud/server/ConfigurationServerImpl.java
Its used for creating a Secondary storage vm copy password.

I'm seeing absolutely no reason why we have 3 values going in no matter
what, I'm willing to say its a bug. I'm curious to why the tests are
written to deal with it though

On 14 October 2014 00:26, Nux! n...@li.nux.ro wrote:

 Well, it's a bit messy, but still better than the old password length.
 Ideally this should get clarified/fixed, but for now I am happy with my
 long+3 password! :)


 Cheers,
 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
  From: Ian Duffy i...@ianduffy.ie
  To: CloudStack Dev dev@cloudstack.apache.org
  Cc: laszlo hornyak laszlo.horn...@gmail.com
  Sent: Monday, 13 October, 2014 19:54:53
  Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT

  Hey Nux,
 
  So I passed this work off to a util class that was already present in
the
  code base PasswordGenerator
 
 @Override
 public String generateRandomPassword() {
 Integer passwordLength =
  Integer.parseInt(_configDao.getValue(vm.password.length));
 return 
PasswordGenerator.generateRandomPassword(passwordLength);
 }
 
  Not a clue why but the generateRandomPassword method creates a random
  3-character string first then loops through to generate n random
 characters.
 
 public static String generateRandomPassword(int num) {
 Random r = new SecureRandom();
 StringBuilder password = new StringBuilder();
 
 // Generate random 3-character string with a lowercase
character,
 // uppercase character, and a digit
 
 
 
password.append(generateLowercaseChar(r)).append(generateUppercaseChar(r)
).append(generateDigit(r));
 
 // Generate a random n-character string with only lowercase
 // characters
 for (int i = 0; i  num; i++) {
 password.append(generateLowercaseChar(r));
 }
 
 return password.toString();
 }
 
  The unit tests seem to accommodate for this aswell:
 
 // actual length is requested length + 3
 
  
Assert.assertTrue(PasswordGenerator.generateRandomPassword(0).length() ==
  3);
 
  
Assert.assertTrue(PasswordGenerator.generateRandomPassword(1).length() ==
  4);
 
  I'm guessing there's some reasoning for this CCing Laszlo who
 according
  to git log did some work on this class.
 
  Thanks,
 
  Ian
 
  On 13 October 2014 19:39, Nux! n...@li.nux.ro wrote:
 
  Hello,
 
  First of all THANKS! to whoever made this feature happen (Ian I
 guess).
  Now we can set more secure passwords generated for our instances.
 
  Second, the feature works, but with a small glitch, the number seems
to
 be
  affected by some sort of offset. I.e. if I set the password to be 15
 chars
  in length then the generated password will actually be 18 chars.
  In order to get a 15 chars long passwd I had to set
vm.password.length
 to
  12. Bug or feature? :)
 
 
  Lucian
 
  --
  Sent from the Delta quadrant using Borg technology!
 
  Nux!
  www.nux.ro

Re: vm.password.length issue in 4.4.1-SNAPSHOT

Imho, considering the password is not very secure (it's missing symbols), we 
should increase the length.
For my personal stuff I default to 15 chars.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Amogh Vasekar amogh.vase...@citrix.com
 To: dev@cloudstack.apache.org
 Cc: laszlo hornyak laszlo.horn...@gmail.com
 Sent: Saturday, 25 October, 2014 00:37:07
 Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT

 Hi Laszlo,
 
 Any comments on the below? I agree adding 3 characters is a bug and
 willing to fix it.
 
 In addition, Ian, I believe we should set a minimum allowed value for the
 config value vm.password.length. Any objections to setting the minimum to
 8, the previous default?
 
 Thanks
 Amogh
 
 On 10/13/14 5:34 PM, Ian Duffy i...@ianduffy.ie wrote:
 
The only other usage of it is within
server/src/com/cloud/server/ConfigurationServerImpl.java
Its used for creating a Secondary storage vm copy password.

I'm seeing absolutely no reason why we have 3 values going in no matter
what, I'm willing to say its a bug. I'm curious to why the tests are
written to deal with it though

On 14 October 2014 00:26, Nux! n...@li.nux.ro wrote:

 Well, it's a bit messy, but still better than the old password length.
 Ideally this should get clarified/fixed, but for now I am happy with my
 long+3 password! :)


 Cheers,
 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
  From: Ian Duffy i...@ianduffy.ie
  To: CloudStack Dev dev@cloudstack.apache.org
  Cc: laszlo hornyak laszlo.horn...@gmail.com
  Sent: Monday, 13 October, 2014 19:54:53
  Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT

  Hey Nux,
 
  So I passed this work off to a util class that was already present in
the
  code base PasswordGenerator
 
 @Override
 public String generateRandomPassword() {
 Integer passwordLength =
  Integer.parseInt(_configDao.getValue(vm.password.length));
 return
PasswordGenerator.generateRandomPassword(passwordLength);
 }
 
  Not a clue why but the generateRandomPassword method creates a random
  3-character string first then loops through to generate n random
 characters.
 
 public static String generateRandomPassword(int num) {
 Random r = new SecureRandom();
 StringBuilder password = new StringBuilder();
 
 // Generate random 3-character string with a lowercase
character,
 // uppercase character, and a digit
 
 
 
password.append(generateLowercaseChar(r)).append(generateUppercaseChar(r)
).append(generateDigit(r));
 
 // Generate a random n-character string with only lowercase
 // characters
 for (int i = 0; i  num; i++) {
 password.append(generateLowercaseChar(r));
 }
 
 return password.toString();
 }
 
  The unit tests seem to accommodate for this aswell:
 
 // actual length is requested length + 3
 
  
Assert.assertTrue(PasswordGenerator.generateRandomPassword(0).length() ==
  3);
 
  
Assert.assertTrue(PasswordGenerator.generateRandomPassword(1).length() ==
  4);
 
  I'm guessing there's some reasoning for this CCing Laszlo who
 according
  to git log did some work on this class.
 
  Thanks,
 
  Ian
 
  On 13 October 2014 19:39, Nux! n...@li.nux.ro wrote:
 
  Hello,
 
  First of all THANKS! to whoever made this feature happen (Ian I
 guess).
  Now we can set more secure passwords generated for our instances.
 
  Second, the feature works, but with a small glitch, the number seems
to
 be
  affected by some sort of offset. I.e. if I set the password to be 15
 chars
  in length then the generated password will actually be 18 chars.
  In order to get a 15 chars long passwd I had to set
vm.password.length
 to
  12. Bug or feature? :)
 
 
  Lucian
 
  --
  Sent from the Delta quadrant using Borg technology!
 
  Nux!
  www.nux.ro

Re: vm.password.length issue in 4.4.1-SNAPSHOT

2014-10-24 Thread Amogh Vasekar

Do note that the password generated here is considered temporary, as
previously pointed out by Chiradeep in another thread.

Thanks
Amogh

On 10/24/14 5:31 PM, Nux! n...@li.nux.ro wrote:

Imho, considering the password is not very secure (it's missing symbols),
we should increase the length.
For my personal stuff I default to 15 chars.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Amogh Vasekar amogh.vase...@citrix.com
 To: dev@cloudstack.apache.org
 Cc: laszlo hornyak laszlo.horn...@gmail.com
 Sent: Saturday, 25 October, 2014 00:37:07
 Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT

 Hi Laszlo,
 
 Any comments on the below? I agree adding 3 characters is a bug and
 willing to fix it.
 
 In addition, Ian, I believe we should set a minimum allowed value for
the
 config value vm.password.length. Any objections to setting the minimum
to
 8, the previous default?
 
 Thanks
 Amogh
 
 On 10/13/14 5:34 PM, Ian Duffy i...@ianduffy.ie wrote:
 
The only other usage of it is within
server/src/com/cloud/server/ConfigurationServerImpl.java
Its used for creating a Secondary storage vm copy password.

I'm seeing absolutely no reason why we have 3 values going in no matter
what, I'm willing to say its a bug. I'm curious to why the tests are
written to deal with it though

On 14 October 2014 00:26, Nux! n...@li.nux.ro wrote:

 Well, it's a bit messy, but still better than the old password length.
 Ideally this should get clarified/fixed, but for now I am happy with
my
 long+3 password! :)


 Cheers,
 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
  From: Ian Duffy i...@ianduffy.ie
  To: CloudStack Dev dev@cloudstack.apache.org
  Cc: laszlo hornyak laszlo.horn...@gmail.com
  Sent: Monday, 13 October, 2014 19:54:53
  Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT

  Hey Nux,
 
  So I passed this work off to a util class that was already present
in
the
  code base PasswordGenerator
 
 @Override
 public String generateRandomPassword() {
 Integer passwordLength =
  Integer.parseInt(_configDao.getValue(vm.password.length));
 return
PasswordGenerator.generateRandomPassword(passwordLength);
 }
 
  Not a clue why but the generateRandomPassword method creates a
random
  3-character string first then loops through to generate n random
 characters.
 
 public static String generateRandomPassword(int num) {
 Random r = new SecureRandom();
 StringBuilder password = new StringBuilder();
 
 // Generate random 3-character string with a lowercase
character,
 // uppercase character, and a digit
 
 
 
password.append(generateLowercaseChar(r)).append(generateUppercaseChar(
r)
).append(generateDigit(r));
 
 // Generate a random n-character string with only lowercase
 // characters
 for (int i = 0; i  num; i++) {
 password.append(generateLowercaseChar(r));
 }
 
 return password.toString();
 }
 
  The unit tests seem to accommodate for this aswell:
 
 // actual length is requested length + 3
 
  
Assert.assertTrue(PasswordGenerator.generateRandomPassword(0).length()
==
  3);
 
  
Assert.assertTrue(PasswordGenerator.generateRandomPassword(1).length()
==
  4);
 
  I'm guessing there's some reasoning for this CCing Laszlo who
 according
  to git log did some work on this class.
 
  Thanks,
 
  Ian
 
  On 13 October 2014 19:39, Nux! n...@li.nux.ro wrote:
 
  Hello,
 
  First of all THANKS! to whoever made this feature happen (Ian I
 guess).
  Now we can set more secure passwords generated for our instances.
 
  Second, the feature works, but with a small glitch, the number
seems
to
 be
  affected by some sort of offset. I.e. if I set the password to be
15
 chars
  in length then the generated password will actually be 18 chars.
  In order to get a 15 chars long passwd I had to set
vm.password.length
 to
  12. Bug or feature? :)
 
 
  Lucian
 
  --
  Sent from the Delta quadrant using Borg technology!
 
  Nux!
  www.nux.ro

Re: vm.password.length issue in 4.4.1-SNAPSHOT

2014-10-24 Thread Ian Duffy

  I agree adding 3 characters is a bug and willing to fix it.

Me too.. I find it very worrying that the code base has tests that
cater for bugs to be valid input.
Really makes me wonder about the quality of the product.

Anyways... I did a grep of the codebase for usage of the method. Its not
used anywhere else... (Which does make me wonder why it existed in the
first place and if its functionality has been duplicated else where)

  Any objections to setting the minimum to 8, the previous default?

No objections from me.

On 25 October 2014 01:41, Amogh Vasekar amogh.vase...@citrix.com wrote:

 Do note that the password generated here is considered temporary, as
 previously pointed out by Chiradeep in another thread.

 Thanks
 Amogh

 On 10/24/14 5:31 PM, Nux! n...@li.nux.ro wrote:

 Imho, considering the password is not very secure (it's missing symbols),
 we should increase the length.
 For my personal stuff I default to 15 chars.
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro
 
 - Original Message -
  From: Amogh Vasekar amogh.vase...@citrix.com
  To: dev@cloudstack.apache.org
  Cc: laszlo hornyak laszlo.horn...@gmail.com
  Sent: Saturday, 25 October, 2014 00:37:07
  Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT
 
  Hi Laszlo,
 
  Any comments on the below? I agree adding 3 characters is a bug and
  willing to fix it.
 
  In addition, Ian, I believe we should set a minimum allowed value for
 the
  config value vm.password.length. Any objections to setting the minimum
 to
  8, the previous default?
 
  Thanks
  Amogh
 
  On 10/13/14 5:34 PM, Ian Duffy i...@ianduffy.ie wrote:
 
 The only other usage of it is within
 server/src/com/cloud/server/ConfigurationServerImpl.java
 Its used for creating a Secondary storage vm copy password.
 
 I'm seeing absolutely no reason why we have 3 values going in no matter
 what, I'm willing to say its a bug. I'm curious to why the tests are
 written to deal with it though
 
 On 14 October 2014 00:26, Nux! n...@li.nux.ro wrote:
 
  Well, it's a bit messy, but still better than the old password length.
  Ideally this should get clarified/fixed, but for now I am happy with
 my
  long+3 password! :)
 
 
  Cheers,
  Lucian
 
  --
  Sent from the Delta quadrant using Borg technology!
 
  Nux!
  www.nux.ro
 
  - Original Message -
   From: Ian Duffy i...@ianduffy.ie
   To: CloudStack Dev dev@cloudstack.apache.org
   Cc: laszlo hornyak laszlo.horn...@gmail.com
   Sent: Monday, 13 October, 2014 19:54:53
   Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT
 
   Hey Nux,
  
   So I passed this work off to a util class that was already present
 in
 the
   code base PasswordGenerator
  
  @Override
  public String generateRandomPassword() {
  Integer passwordLength =
   Integer.parseInt(_configDao.getValue(vm.password.length));
  return
 PasswordGenerator.generateRandomPassword(passwordLength);
  }
  
   Not a clue why but the generateRandomPassword method creates a
 random
   3-character string first then loops through to generate n random
  characters.
  
  public static String generateRandomPassword(int num) {
  Random r = new SecureRandom();
  StringBuilder password = new StringBuilder();
  
  // Generate random 3-character string with a lowercase
 character,
  // uppercase character, and a digit
  
  
 
 password.append(generateLowercaseChar(r)).append(generateUppercaseChar(
 r)
 ).append(generateDigit(r));
  
  // Generate a random n-character string with only lowercase
  // characters
  for (int i = 0; i  num; i++) {
  password.append(generateLowercaseChar(r));
  }
  
  return password.toString();
  }
  
   The unit tests seem to accommodate for this aswell:
  
  // actual length is requested length + 3
  
  
 Assert.assertTrue(PasswordGenerator.generateRandomPassword(0).length()
 ==
   3);
  
  
 Assert.assertTrue(PasswordGenerator.generateRandomPassword(1).length()
 ==
   4);
  
   I'm guessing there's some reasoning for this CCing Laszlo who
  according
   to git log did some work on this class.
  
   Thanks,
  
   Ian
  
   On 13 October 2014 19:39, Nux! n...@li.nux.ro wrote:
  
   Hello,
  
   First of all THANKS! to whoever made this feature happen (Ian I
  guess).
   Now we can set more secure passwords generated for our instances.
  
   Second, the feature works, but with a small glitch, the number
 seems
 to
  be
   affected by some sort of offset. I.e. if I set the password to be
 15
  chars
   in length then the generated password will actually be 18 chars.
   In order to get a 15 chars long passwd I had to set
 vm.password.length
  to
   12. Bug or feature? :)
  
  
   Lucian
  
   --
   Sent from the Delta quadrant using Borg technology!
  
   Nux!
   www.nux.ro

Re: [PROPOSAL] Move to github PR only during moratorium on commit