Re: SystemVM file name changes

[Leo Simons]

Hey Ian,

On Sep 24, 2014, at 2:04 AM, Ian Duffy  wrote:
> I noticed the filename of the generated systemvms changed on
> http://jenkins.buildacloud.org/job/build-systemvm64-master/
> 
> They now include a [0-9]* before the hypervisor name representing the build
> number.

That’s one of the things coming out of the 1290e10 merge.

> Why do we do this? Its annoying for external resources linking to the last
> successful build.

The general concept is one of traceable and repeatable builds.

In RPM terms, given just a random binary RPM found on a random system
* it should be possible to unambiguously determine the source RPM from which it 
was built
* it should be possible to determine who or what built it, and when
* it should be possible to trace the source RPM back to the exact version 
control revision
* it should be possible to determine easily whether that binary is the same as
  another one on another machine / in another repository that has the same
  identifiers

In RPM land, the jenkins $BUILD_NUMBER should go into the RPM Release field and 
not into the RPM Version field. But in this case we don’t have RPM, or spec 
files, so there is only the filename to accomplish the same (which is why the 
branch name is also in there), and it has to be in this spot or cloudstack gets 
a bit confused.

What we do in our integration environment is to apply just a bit of logic to 
parse out the version number from the file name. I.e. to get an RPM from 
jenkins see fetch-rpms.sh included below, or to fetch the most recent systemvm 
from a directory listing see download-template.sh also included below. Would 
something like that work for you?

If not, the logic for creating the version is in build.sh:

version_tag=
if [ ! -z "${version}" ]; then
  if [ ! -z "${BUILD_NUMBER}" ]; then
version="${version}.${BUILD_NUMBER}"
  fi
  version_tag="-${version}"
elif [ ! -z "${BUILD_NUMBER}" ]; then
  version="${BUILD_NUMBER}"
  version_tag="-${BUILD_NUMBER}”
fi

So we can change that, or we can unset BUILD_NUMBER in the jenkins build prior 
to invocation. What do you think?

It would be much better to exclusively use yum/maven repositories and their 
logic to centralize this kind of logic server-side, or at least to be creating 
and updating symlinks to ‘latest’. That’s a work in progress...


cheers,


Leo

download-templates.sh
=
#!/bin/bash
#
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements.  See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership.  The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License.  You may obtain a copy of the License at
#
#   http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing,
# software distributed under the License is distributed on an
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
# KIND, either express or implied.  See the License for the
# specific language governing permissions and limitations
# under the License.

# Download systemvm templates onto secondary storage

set -e
echo $@ | grep debug >/dev/null && DEBUG="1"
echo $@ | grep trace >/dev/null && TRACE="1"

function source_common() {
  local SOURCE="${BASH_SOURCE[0]}"
  DIR="$( cd -P "$( dirname "${SOURCE}" )" && pwd )"
  source "${DIR}/common.sh"
}
source_common

NFS_HOST="${1:-localhost}"
NFS_SECONDARY_EXPORT="${2:-/storage/secondary}"
MOUNT_PATH="${3:-/mnt/secondary}"
BASE_URL="${4:-https://artifacts.schubergphilis.com/artifacts/cloudstack}";
TEMPLATE="${5:-systemvmtemplate}"
DB_HOST="${6:-localhost}"
DB_USER="${7:-root}"
DB_PASSWORD="${8:-}"

function find_template() {
  if ! `echo "${TEMPLATE}" | egrep '^[a-zA-Z0-9]+-[0-9]+(\.[0-9]+)*$'`; then
# (apache) directory listing
# find only links
# filter by template name
# find only xen template
# strip suffix
# take the first (newest) one
newest_first="?C=M;O=D"
TEMPLATE=$(curl "${BASE_URL}/${newest_first}" | \
  egrep -o 'href="[^"]+"' | \
  egrep "${TEMPLATE}" | \
  egrep -o "[^/\"]+-xen\.vhd\.bz2" | \
  sed 's/-xen.vhd.bz2//' |\
  head -n 1)
if [[ "${TEMPLATE}" == "" ]]; then
  error "No possible match found for ${TEMPLATE} at ${BASE_URL}"
fi
log INFO "Using template ${TEMPLATE}"
  fi
}

function install_xen_template() {
  XEN_URL="${BASE_URL}/${TEMPLATE}-xen.vhd.bz2"
  # KVM_URL="${BASE_URL}/${TEMPLATE}-kvm.vhd.bz2"

  [ -d "${MOUNT_PATH}" ] || mkdir "${MOUNT_PATH}"

  mount -t nfs "${NFS_HOST}:${NFS_SECONDARY_EXPORT}" "${MOUNT_PATH}" || true

  
/usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt \
-F \
-m "${MOUNT_PATH}" \
-h "xenserver" \
-u "${XEN_URL}" \
-o "${DB_HOST}" \
-r "${DB_USER}" \
-d "${DB_PASSWORD}"
}

function main() {
  find_template
  install_xen_te

Re: [01/50] git commit: updated refs/heads/master to 1290e10

[Leo Simons]

Hey hey,

On Sep 23, 2014, at 11:50 PM, David Nalley  wrote:
> On Tue, Sep 23, 2014 at 4:44 PM, Rohit Yadav  
> wrote:
>> Hi David,
>> 
>> On 23-Sep-2014, at 8:31 pm, David Nalley  wrote:
>>> Where was the merge request for this huge merge to master? (it was at
>>> 50 commit emails, when it stopped sending, )
>>> We have passed feature freeze for 4.5.0, so I am confused as why this
>>> was merged. Is there a reason not to revert all of this?
>> 
>> This was the request: https://github.com/apache/cloudstack/pull/16
>> And JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-7143
>> We all get emails from Github PR (just re-checked) so you may find them on 
>> the ML.
> 
> Yes, GH PR is exactly like the Review Board emails in this particular
> aspect. My question is why is this merged into master rather than a
> feature branch, and why no [MERGE] email as per:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Expectations

Hmm, I hadn’t seen that before; don’t think it’s linked from the “how to 
contribute” stuff. Sorry. Or is this something a committer is to do?

Can we change the rules? Because I’d guess the [MERGE] e-mail serves exactly 
the same role as a pull request: widely announcing a branch is ready to merge 
in and providing a trigger point for discussion.

It’s also interesting to consider whether you need a feature branch at all in 
the local repository for branches that were first developed (and tested) 
remotely. After all the only remaining thing you will do to that branch is to 
merge it in. The original feature branch is

  https://github.com/schubergphilis/CloudStack/tree/feature/systemvm-refactor

which has existed for a few months and was discussed here a few times (well I 
sent e-mail about it, there wasn’t much discussion…), with

  
https://github.com/schubergphilis/CloudStack/tree/feature/systemvm-refactor-for-upstream

as the re-re-rebased version of all that. This is all github standard (best?) 
practice, to the point that you cannot even create pull requests that result in 
the creation of new branches. I.e. if you look at

  
https://github.com/schubergphilis/cloudstack/compare/feature/systemvm-refactor-for-upstream

and you click the “edit” in the top row, you can’t even suggest merging to a 
new branch, there’s only existing ones listed. Of course the committer doing 
the actual upstreaming can make a different choice, but, why would you?

As for whether to take this for 4.5.0, of course the risk is not 0, but its 
pretty darn low. I also think by typical community rules just about none of the 
commits in the pull request are a new feature. Longer term the point of these 
changes is a quality increase by being just slightly more precise and 
deliberate in a few places. If you think they don’t accomplish that you should 
definitely pull it out, but then I’d like to hear what’s wrong!

If you pull it out, please do consider something more limited like

https://github.com/schubergphilis/cloudstack/commit/74c381540ebaf940bbbf471b580303488aa9c5b4
which avoids putting master version of the systemvm code into branch builds.

I would also _really_ like to see a virtualbox systemvm.box out of the official 
4.5.0 build so that we can easily use our systemvm component tests for 
regression testing the changes we’ll have for 4.5.1/4.6.0. If you back this out 
it’ll be annoying bit twiddling to make one manually.



cheers!


Leo

Re: [ACS441] merge request: hotfix/4.4-7574

[Pierre-Luc Dion]

I guest so, but I don't know the OS name to define in VMware :-S  I don't
have a VMware system in hand.


*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_


On Tue, Sep 23, 2014 at 9:22 PM, Amogh Vasekar 
wrote:

> Hi,
>
> Do we claim support for these OS on vmware too?
>
> Amogh
>
> On 9/23/14 5:44 PM, "Pierre-Luc Dion"  wrote:
>
> >Hi Dahn,
> >
> >can you merge this branch into 4.4, I've test creation of windows 8.1,
> >2012r2 and centos6.5 on xenserver.
> >
> >Thanks,
> >
> >Pierre-Luc
>
>

Build failed in Jenkins: simulator-singlerun #429

[jenkins]

See 

Changes:

[pdion891] CLOUDSTACK-7574, CREATE TABLE cloud.baremetal_rct

[pdion891] remove table baremetal_rct crate from schema-440to441.sql,already in 
schema-441to450.sql

[anthony.xu] throw timeout exception when lock acquire times out

--
[...truncated 8880 lines...]
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 22.732s
[INFO] Finished at: Tue Sep 23 22:10:06 EDT 2014
[INFO] Final Memory: 41M/176M
[INFO] 
[simulator-singlerun] $ /bin/bash -x /tmp/hudson794521949021670983.sh
+ grep -q Launcher
+ jps -l
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=13106
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ '[' 0 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=8
+ '[' 8 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=9
+ '[' 9 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=10
+ '[' 10 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=11
+ '[' 11 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=12
+ '[' 12 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=13
+ '[' 13 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=14
+ '[' 14 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=15
+ '[' 15 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=16
+ '[' 16 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=17
+ '[' 17 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=18
+ '[' 18 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=19
+ '[' 19 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=20
+ '[' 20 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=21
+ '[' 21 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=22
+ '[' 22 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=23
+ '[' 23 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=24
+ '[' 24 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=25
+ '[' 25 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=26
+ '[' 26 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=27
+ '[' 27 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=28
+ '[' 28 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=29
+ '[' 29 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=30
+ '[' 30 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=31
+ '[' 31 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=32
+ '[' 32 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=33
+ '[' 33 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=34
+ '[' 34 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=35
+ '[' 35 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=36
+ '[' 36 -l

Re: [ACS441] merge request: hotfix/4.4-7574

[Amogh Vasekar]

Hi,

Do we claim support for these OS on vmware too?

Amogh

On 9/23/14 5:44 PM, "Pierre-Luc Dion"  wrote:

>Hi Dahn,
>
>can you merge this branch into 4.4, I've test creation of windows 8.1,
>2012r2 and centos6.5 on xenserver.
>
>Thanks,
>
>Pierre-Luc

[ACS441] merge request: hotfix/4.4-7574

[Pierre-Luc Dion]

Hi Dahn,

can you merge this branch into 4.4, I've test creation of windows 8.1,
2012r2 and centos6.5 on xenserver.

Thanks,

Pierre-Luc

Build failed in Jenkins: simulator-singlerun #428

[jenkins]

See 

Changes:

[anthony.xu] removed unused class

[sheng.yang] CLOUDSTACK-7436: Fix automation test on RvR status detection

--
[...truncated 8872 lines...]
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 21.787s
[INFO] Finished at: Tue Sep 23 20:34:19 EDT 2014
[INFO] Final Memory: 40M/204M
[INFO] 
[simulator-singlerun] $ /bin/bash -x /tmp/hudson9208507046767249637.sh
+ jps -l
+ grep -q Launcher
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=31411
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ '[' 0 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=8
+ '[' 8 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=9
+ '[' 9 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=10
+ '[' 10 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=11
+ '[' 11 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=12
+ '[' 12 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=13
+ '[' 13 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=14
+ '[' 14 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=15
+ '[' 15 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=16
+ '[' 16 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=17
+ '[' 17 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=18
+ '[' 18 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=19
+ '[' 19 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=20
+ '[' 20 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=21
+ '[' 21 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=22
+ '[' 22 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=23
+ '[' 23 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=24
+ '[' 24 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=25
+ '[' 25 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=26
+ '[' 26 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=27
+ '[' 27 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=28
+ '[' 28 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=29
+ '[' 29 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=30
+ '[' 30 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=31
+ '[' 31 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=32
+ '[' 32 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=33
+ '[' 33 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=34
+ '[' 34 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=35
+ '[' 35 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=36
+ '[' 36 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=37
+ '[' 37 -lt 44 ']'

SystemVM file name changes

[Ian Duffy]

Hi All,

I noticed the filename of the generated systemvms changed on
http://jenkins.buildacloud.org/job/build-systemvm64-master/

They now include a [0-9]* before the hypervisor name representing the build
number.

Why do we do this? Its annoying for external resources linking to the last
successful build.

[GitHub] cloudstack pull request: VPC and Virtual Network Managers refactor...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/19#issuecomment-56598885
  
Hi, I was recently reminded about the branch merging process. Once you're 
confident with your testing of Xen/KVM please send a merge request on dev ML 
and follow: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Expectations

Hope this helps.


---
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: [01/50] git commit: updated refs/heads/master to 1290e10

[Rohit Yadav]

Hi David,

On 23-Sep-2014, at 11:50 pm, David Nalley  wrote:
> Yes, GH PR is exactly like the Review Board emails in this particular
> aspect. My question is why is this merged into master rather than a
> feature branch, and why no [MERGE] email as per:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Expectations

Ah, my bad. I did not consider the process/syntax around it. There was some 
initial email on this but it did not start with a “[MERGE]” but started with 
“rfc:” for merging it on master:
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201407.mbox/%3C7A6CF878-7A28-4D4A-BCD2-0C264F8C90B7%40schubergphilis.com%3E

I also forgot that this process should apply for merging changes from 
reviewboard and Github PR as well. That’s completely my fault to not enforce 
the branch merging process on this PR. The only thing I can offer now is to 
make sure that this work won’t break build or anything else on master/4.5.0

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

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

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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: [01/50] git commit: updated refs/heads/master to 1290e10

[David Nalley]

On Tue, Sep 23, 2014 at 4:44 PM, Rohit Yadav  wrote:
> Hi David,
>
> On 23-Sep-2014, at 8:31 pm, David Nalley  wrote:
>> Where was the merge request for this huge merge to master? (it was at
>> 50 commit emails, when it stopped sending, )
>> We have passed feature freeze for 4.5.0, so I am confused as why this
>> was merged. Is there a reason not to revert all of this?
>
> This was the request: https://github.com/apache/cloudstack/pull/16
> And JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-7143
> We all get emails from Github PR (just re-checked) so you may find them on 
> the ML.
>

Yes, GH PR is exactly like the Review Board emails in this particular
aspect. My question is why is this merged into master rather than a
feature branch, and why no [MERGE] email as per:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Expectations

> I was reviewing this Github pull request which came in couple of weeks ago. 
> This is well tested and successfully refactors the way we build systemvms. It 
> was only merged when it passed build tests and painful manual QA (I did on 
> KVM). Just want to mention that this is not my code or $dayjob work, I was 
> just trying to help out the contribution from community member(s).
>
> Pardon my ignorance but I was not aware about our official status of 
> master/4.5.0 that we’re already passed feature freeze. Can you confirm the 
> official stand/status on master/4.5.0 and when do we plan to cut the release 
> branch, and if we are changing anything with the way we do releases etc?
>

See:
http://markmail.org/message/jctcystkzv4sqrvz

Based on that thread, we decided not to branch 4.5.0 and instead keep
master = 4.5.0 until much later in the schedule.
Hence merging features into master is breaking feature freeze.

> I see a lot of changes that comes in every other day on master. The pattern I 
> see is that developers check-in barely working feature and then find the 
> excuse to check-in more patches/commits as bug fixes where they actually are 
> trying to complete an incomplete feature. I think this is a chronic issue 
> which should be checked and everyone should make an effort to work in their 
> feature branch, work on their git-foo, rebase/fix-conflicts and send merge 
> request or Github pull requests or request using reviewboard. I think this 
> will allow all of us to participate in on-going efforts and would help 
> improve its quality using QA and code reviewing.
>

This is a separate issue; but I tend to agree with your analysis of
how things happen. If you see this happening though, please speak up.
As a committer you have veto power. Speaking frankly, we all have to
be on guard for quality issues.

--David

[GitHub] cloudstack pull request: CLOUDSTACK-7143: Refactoring of the syste...

[lsimons]

Github user lsimons commented on the pull request:

https://github.com/apache/cloudstack/pull/16#issuecomment-56589622
  
Thanks for all the help Rohit! I'm sure to most people some bash script 
rearrangement looks boring, but nevermind that, to me it just feels good to 
sumbit more than just simple one-line patches to an apache project after such a 
long time :-)


---
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: [01/50] git commit: updated refs/heads/master to 1290e10

[Rohit Yadav]

Hi David,

On 23-Sep-2014, at 8:31 pm, David Nalley  wrote:
> Where was the merge request for this huge merge to master? (it was at
> 50 commit emails, when it stopped sending, )
> We have passed feature freeze for 4.5.0, so I am confused as why this
> was merged. Is there a reason not to revert all of this?

This was the request: https://github.com/apache/cloudstack/pull/16
And JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-7143
We all get emails from Github PR (just re-checked) so you may find them on the 
ML.

I was reviewing this Github pull request which came in couple of weeks ago. 
This is well tested and successfully refactors the way we build systemvms. It 
was only merged when it passed build tests and painful manual QA (I did on 
KVM). Just want to mention that this is not my code or $dayjob work, I was just 
trying to help out the contribution from community member(s).

Pardon my ignorance but I was not aware about our official status of 
master/4.5.0 that we’re already passed feature freeze. Can you confirm the 
official stand/status on master/4.5.0 and when do we plan to cut the release 
branch, and if we are changing anything with the way we do releases etc?

I see a lot of changes that comes in every other day on master. The pattern I 
see is that developers check-in barely working feature and then find the excuse 
to check-in more patches/commits as bug fixes where they actually are trying to 
complete an incomplete feature. I think this is a chronic issue which should be 
checked and everyone should make an effort to work in their feature branch, 
work on their git-foo, rebase/fix-conflicts and send merge request or Github 
pull requests or request using reviewboard. I think this will allow all of us 
to participate in on-going efforts and would help improve its quality using QA 
and code reviewing.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

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

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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: [01/50] git commit: updated refs/heads/master to 1290e10

[Hugo Trippaers]

Hey David,

This is one of the requests that came in using the “new" github pull request 
thing. The big advantage is that we leverage the nice things from github. Part 
of doing it that way means we keep the history of the original developer 
intact. With review board we typically get one smashed commit with the entire 
change. This is an entire commit history we got working up to a rewrite of the 
build scripts for the systemvm. I’m not exactly sure if that is what we want 
from github yet, but lets see what we all think about it. Procedurally this is 
the same as merging something in from the review board after review.

As for the content, i’m pretty biased as it is part of the ongoing project to 
introduce the redundant VPC router. Leo did a great job in rewriting the build 
scripts for the systemvms. No changing any functionality, but mainly making the 
code and scripts more accessible. I’m thinking of this as a change to packaging 
more than merging new features. There are changes pending that will change 
functionality, but those are planned for after 4.5 happens.

Cheers,

Hugo



On 23 sep. 2014, at 20:31, David Nalley  wrote:

> Where was the merge request for this huge merge to master? (it was at
> 50 commit emails, when it stopped sending, )
> We have passed feature freeze for 4.5.0, so I am confused as why this
> was merged. Is there a reason not to revert all of this?
> 
> --David
> 
> On Mon, Sep 22, 2014 at 3:44 PM,   wrote:
>> Repository: cloudstack
>> Updated Branches:
>>  refs/heads/master a6ee4112a -> 1290e1010
>> 
>> 
>> CLOUDSTACK-7143: move fix_acpid to its own file
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/5627b67f
>> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/5627b67f
>> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/5627b67f
>> 
>> Branch: refs/heads/master
>> Commit: 5627b67ff3a6af70949ee1622b3e5a572d39a0b7
>> Parents: 6a688a0
>> Author: Leo Simons 
>> Authored: Mon Jul 21 11:19:03 2014 +0200
>> Committer: Rohit Yadav 
>> Committed: Mon Sep 22 21:31:35 2014 +0200
>> 
>> --
>> .../definitions/systemvmtemplate/configure_acpid.sh  | 15 +++
>> .../definitions/systemvmtemplate/definition.rb   |  1 +
>> .../definitions/systemvmtemplate/postinstall.sh  | 15 ---
>> 3 files changed, 16 insertions(+), 15 deletions(-)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/5627b67f/tools/appliance/definitions/systemvmtemplate/configure_acpid.sh
>> --
>> diff --git a/tools/appliance/definitions/systemvmtemplate/configure_acpid.sh 
>> b/tools/appliance/definitions/systemvmtemplate/configure_acpid.sh
>> new file mode 100644
>> index 000..70abe30
>> --- /dev/null
>> +++ b/tools/appliance/definitions/systemvmtemplate/configure_acpid.sh
>> @@ -0,0 +1,15 @@
>> +fix_acpid() {
>> +  # Fix acpid
>> +  mkdir -p /etc/acpi/events
>> +  cat >> /etc/acpi/events/power << EOF
>> +event=button/power.*
>> +action=/usr/local/sbin/power.sh "%e"
>> +EOF
>> +  cat >> /usr/local/sbin/power.sh << EOF
>> +#!/bin/bash
>> +/sbin/poweroff
>> +EOF
>> +  chmod a+x /usr/local/sbin/power.sh
>> +}
>> +
>> +fix_acpid
>> 
>> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/5627b67f/tools/appliance/definitions/systemvmtemplate/definition.rb
>> --
>> diff --git a/tools/appliance/definitions/systemvmtemplate/definition.rb 
>> b/tools/appliance/definitions/systemvmtemplate/definition.rb
>> index be0b403..a2eb82b 100644
>> --- a/tools/appliance/definitions/systemvmtemplate/definition.rb
>> +++ b/tools/appliance/definitions/systemvmtemplate/definition.rb
>> @@ -63,6 +63,7 @@ config = {
>> 'configure_locale.sh',
>> 'configure_login.sh',
>> 'postinstall.sh',
>> +'configure_acpid.sh',
>> 'cleanup.sh',
>> 'configure_networking.sh',
>> 'zerodisk.sh'
>> 
>> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/5627b67f/tools/appliance/definitions/systemvmtemplate/postinstall.sh
>> --
>> diff --git a/tools/appliance/definitions/systemvmtemplate/postinstall.sh 
>> b/tools/appliance/definitions/systemvmtemplate/postinstall.sh
>> index 893b521..f2ce1ae 100644
>> --- a/tools/appliance/definitions/systemvmtemplate/postinstall.sh
>> +++ b/tools/appliance/definitions/systemvmtemplate/postinstall.sh
>> @@ -116,20 +116,6 @@ nameserver 8.8.4.4
>> EOF
>> }
>> 
>> -fix_acpid() {
>> -  # Fix acpid
>> -  mkdir -p /etc/acpi/events
>> -  cat >> /etc/acpi/events/power << EOF
>> -event=button/power.*
>> -action=/usr/local/sbin/power.sh "%e"
>> -EOF
>> -  cat >> /usr/local/sbin/po

Re: [01/50] git commit: updated refs/heads/master to 1290e10

[David Nalley]

Where was the merge request for this huge merge to master? (it was at
50 commit emails, when it stopped sending, )
We have passed feature freeze for 4.5.0, so I am confused as why this
was merged. Is there a reason not to revert all of this?

--David

On Mon, Sep 22, 2014 at 3:44 PM,   wrote:
> Repository: cloudstack
> Updated Branches:
>   refs/heads/master a6ee4112a -> 1290e1010
>
>
> CLOUDSTACK-7143: move fix_acpid to its own file
>
>
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/5627b67f
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/5627b67f
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/5627b67f
>
> Branch: refs/heads/master
> Commit: 5627b67ff3a6af70949ee1622b3e5a572d39a0b7
> Parents: 6a688a0
> Author: Leo Simons 
> Authored: Mon Jul 21 11:19:03 2014 +0200
> Committer: Rohit Yadav 
> Committed: Mon Sep 22 21:31:35 2014 +0200
>
> --
>  .../definitions/systemvmtemplate/configure_acpid.sh  | 15 +++
>  .../definitions/systemvmtemplate/definition.rb   |  1 +
>  .../definitions/systemvmtemplate/postinstall.sh  | 15 ---
>  3 files changed, 16 insertions(+), 15 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/5627b67f/tools/appliance/definitions/systemvmtemplate/configure_acpid.sh
> --
> diff --git a/tools/appliance/definitions/systemvmtemplate/configure_acpid.sh 
> b/tools/appliance/definitions/systemvmtemplate/configure_acpid.sh
> new file mode 100644
> index 000..70abe30
> --- /dev/null
> +++ b/tools/appliance/definitions/systemvmtemplate/configure_acpid.sh
> @@ -0,0 +1,15 @@
> +fix_acpid() {
> +  # Fix acpid
> +  mkdir -p /etc/acpi/events
> +  cat >> /etc/acpi/events/power << EOF
> +event=button/power.*
> +action=/usr/local/sbin/power.sh "%e"
> +EOF
> +  cat >> /usr/local/sbin/power.sh << EOF
> +#!/bin/bash
> +/sbin/poweroff
> +EOF
> +  chmod a+x /usr/local/sbin/power.sh
> +}
> +
> +fix_acpid
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/5627b67f/tools/appliance/definitions/systemvmtemplate/definition.rb
> --
> diff --git a/tools/appliance/definitions/systemvmtemplate/definition.rb 
> b/tools/appliance/definitions/systemvmtemplate/definition.rb
> index be0b403..a2eb82b 100644
> --- a/tools/appliance/definitions/systemvmtemplate/definition.rb
> +++ b/tools/appliance/definitions/systemvmtemplate/definition.rb
> @@ -63,6 +63,7 @@ config = {
>  'configure_locale.sh',
>  'configure_login.sh',
>  'postinstall.sh',
> +'configure_acpid.sh',
>  'cleanup.sh',
>  'configure_networking.sh',
>  'zerodisk.sh'
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/5627b67f/tools/appliance/definitions/systemvmtemplate/postinstall.sh
> --
> diff --git a/tools/appliance/definitions/systemvmtemplate/postinstall.sh 
> b/tools/appliance/definitions/systemvmtemplate/postinstall.sh
> index 893b521..f2ce1ae 100644
> --- a/tools/appliance/definitions/systemvmtemplate/postinstall.sh
> +++ b/tools/appliance/definitions/systemvmtemplate/postinstall.sh
> @@ -116,20 +116,6 @@ nameserver 8.8.4.4
>  EOF
>  }
>
> -fix_acpid() {
> -  # Fix acpid
> -  mkdir -p /etc/acpi/events
> -  cat >> /etc/acpi/events/power << EOF
> -event=button/power.*
> -action=/usr/local/sbin/power.sh "%e"
> -EOF
> -  cat >> /usr/local/sbin/power.sh << EOF
> -#!/bin/bash
> -/sbin/poweroff
> -EOF
> -  chmod a+x /usr/local/sbin/power.sh
> -}
> -
>  fix_hostname() {
># Fix hostname in openssh-server generated keys
>sed -i "s/root@\(.*\)$/root@$HOSTNAME/g" /etc/ssh/ssh_host_*.pub
> @@ -164,7 +150,6 @@ EOF
>
>  do_fixes() {
>fix_nameserver
> -  fix_acpid
>fix_hostname
>fix_conntrackd
>fix_vhdutil
>

Re: conf values for 4.4 from master

[Sheng Yang]

Hi Daan,

These are already added for 4.4's schema-430to440.sql (and your second mail
is the same as the first case of first mail...)

dcb0db6084 (Sheng Yang  2014-04-16 20:13:16 -0700 1660) INSERT INTO
`cloud`.`configuration`(category, instance, component, name, value,
description, default_value) VALUES ('Advanced', 'DEFAULT',
'NetworkOrchestrationService', 'router.r

3578c7137f (Sheng Yang  2014-04-18 23:27:12 -0700 1669)
3578c7137f (Sheng Yang  2014-04-18 23:27:12 -0700 1670) INSERT INTO
`cloud`.`configuration`(category, instance, component, name, value,
description, default_value) VALUES ('Advanced', 'DEFAULT',
'NetworkOrchestrationService', 'router.a

--Sheng

On Tue, Sep 23, 2014 at 3:05 AM, Daan Hoogland 
wrote:

> I see one more of them:
>
> INSERT INTO `cloud`.`configuration`(category, instance, component, name,
> value, description, default_value) VALUES ('Advanced', 'DEFAULT',
> 'NetworkOrchestrationService', 'router.redundant.vrrp.interval', '1',
> 'seconds between VRRP broadcast. It would 3 times broadcast fail to trigger
> fail-over mechanism of redundant router', '1') ON DUPLICATE KEY UPDATE
> category='Advanced';
>
>
> On Tue, Sep 23, 2014 at 11:38 AM, Daan Hoogland 
> wrote:
>
> > Sheng,
> >
> > these two lines where added by you to the file schema-430to440.sql in
> > master but not in 4.4
> >
> > INSERT INTO `cloud`.`configuration`(category, instance, component, name,
> > value, description, default_value) VALUES ('Advanced', 'DEFAULT',
> > 'NetworkOrchestrationService', 'router.redundant.vrrp.interval', '1',
> > 'seconds between VRRP broadcast. It would 3 times broadcast fail to
> trigger
> > fail-over mechanism of redundant router', '1') ON DUPLICATE KEY UPDATE
> > category='Advanced';
> > INSERT INTO `cloud`.`configuration`(category, instance, component, name,
> > value, description, default_value) VALUES ('Advanced', 'DEFAULT',
> > 'NetworkOrchestrationService', 'router.aggregation.command.each.timeout',
> > '3', 'timeout in seconds for each Virtual Router command being
> aggregated.
> > The final aggregation command timeout would be determined by this
> timeout *
> > commands counts ', '3') ON DUPLICATE KEY UPDATE category='Advanced';
> >
> > Is it sensible to add them in 4.4 as well?
> >
> > --
> > Daan
> >
>
>
>
> --
> Daan
>

RE: baremetal in master and 4.4

[Frank Zhang]

Thanks Daan. When I wrote this schema, schema-430to440.sql was the latest one I 
could find.
I have moved it to schema-441to450.sql

From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: Tuesday, September 23, 2014 2:00 AM
To: Frank Zhang
Cc: dev
Subject: baremetal in master and 4.4

Frank,
Can you have a look at commit 781ad96b04c9030fc1c0a0401145414e7f3978aa ? It is 
only on master, not on 4.4 but it contains a change in schema-430to440.sql
I'd say the easiest remedy is to revert and recreate with the db change in 
another db upgrade file.


--
Daan

Jenkins build is back to normal : simulator-singlerun #423

[jenkins]

See 

Re: Marvin Package?

[David Nalley]

On Tue, Sep 23, 2014 at 7:26 AM, Rohit Yadav  wrote:
> Hi David,
>
> On 22-Sep-2014, at 4:54 am, David Nalley  wrote:
>> Sharing things on pypi is a distribution channel for end users -  if
>> it's done by the project, it must be voted on and released. If it's
>> done by an individual, they can't post anything they want, but we'll
>> have to insist that they don't use our trademarks (e.g. both Marvin
>> and CloudStack will need to be removed from the package name)
>
> For all the previously voted releases of CloudStack, can we still build 
> marvin from those source releases and publish on pypi (keeping the marvin 
> version same as CloudStack version to avoid confusion)?
>

Yes. If it's been voted on successfully that can be published.

--David

[GitHub] cloudstack pull request: VPC and Virtual Network Managers refactor...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/19#issuecomment-56535474
  
Hi Rohit,

For xen I did only advanced. With simulator both.

I can do basic for xen if you need aome help.

Cheers,
Wilder

Sent from my iPhone

On 23 Sep 2014, at 16:58, "Rohit Yadav" 
mailto:notificati...@github.com>> wrote:


Hi @wilderrodrigues I'll get back to 
you soon on this. Meanwhile, just to reconfirm have you tested it for both 
basic and advance networks for Xen? If so, I'll just do it for KVM.

—
Reply to this email directly or view it on 
GitHub.


---
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.
---

Cloudstack Mirror

[David Bierce]

We now have a mirror of cloudstack locally.

http://mirror.appcore.com/cloudstack/

Contains both cloudstack signed RPM and DEBs

/rhel for the rpm repo for YUM
/ubuntu for the deb repo for APT

This is also a mirror of the all the systemvms for all versions in /systemvms



Thanks,
David Bierce
Senior System Administrator  | Appcore

Office +1.800.735.7104
Direct +1.515.612.7801 
www.appcore.com

[GitHub] cloudstack pull request: VPC and Virtual Network Managers refactor...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/19#issuecomment-56536147
  
Yeah, please do it for Xen and see if it works for basic VM life cycle. 
I've some $dayjob stuff to do so I may not be able to test your PR this week 
with KVM.


---
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.
---

Sorry for the Spam.

[David Bierce]

Sorry for the spam.  Apple mail decided apache dev list was the destination for 
our internal mailing list.  It has been fixed.


Thanks,
David Bierce
Senior System Administrator  | Appcore

Office +1.800.735.7104
Direct +1.515.612.7801 
www.appcore.com

[GitHub] cloudstack pull request: VPC and Virtual Network Managers refactor...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/19#issuecomment-56533161
  
Hi @wilderrodrigues I'll get back to you soon on this. Meanwhile, just to 
reconfirm have you tested it for both basic and advance networks for Xen? If 
so, I'll just do it for KVM.


---
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.
---

[GitHub] cloudstack pull request: VPC and Virtual Network Managers refactor...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/19#issuecomment-56522671
  
Hi @bhaisaab,

I fixed the DHCP problem, tested all Advanced and Basic Marvin tests 
against the simulator and my XenServer environment. The commit has been added 
to the pull request.

Could you please have a look and let me know?

Once I get a GO from you, I will do the rebase and let Travis do its magic.

Cheers,
Wilder


---
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.
---

[ERROR] Failed create template from snapshot The uuid you supplied was invalid.

[raja sekhar]

Hi All,

I have upgraded ACS 4.3 to 4.4.0.From that time onwards the root volume
snapshots are not taking properly, sometimes the snapshots are taking and
sometimes the snapshots stuck in "ERROR" state. when ever i want to create
template from a backedup snapshot i'm getting the error "Failed create
template from snapshot
The uuid you supplied was invalid."

The log file shows,

2014-09-23 18:55:54,197 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
Timer:ctx-5e74939f) Acquiring hosts for clusters already owned by this
management server
2014-09-23 18:55:54,199 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
Timer:ctx-5e74939f) Completed acquiring hosts for clusters already owned by
this management server
2014-09-23 18:55:54,199 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
Timer:ctx-5e74939f) Acquiring hosts for clusters not owned by any
management server
2014-09-23 18:55:54,200 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
Timer:ctx-5e74939f) Completed acquiring hosts for clusters not owned by any
management server
2014-09-23 18:56:02,808 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) SeqA 23-69610: Processing Seq 23-69610:  {
Cmd , MgmtId: -1, via: 23, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":155,"_loadInfo":"{\n
 \"connections\": []\n}","wait":0}}] }
2014-09-23 18:56:02,813 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) SeqA 23-69610: Sending Seq 23-69610:  { Ans:
, MgmtId: 52244012385, via: 23, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2014-09-23 18:56:07,809 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-4:null) SeqA 23-69611: Processing Seq 23-69611:  {
Cmd , MgmtId: -1, via: 23, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":155,"_loadInfo":"{\n
 \"connections\": []\n}","wait":0}}] }
2014-09-23 18:56:07,814 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-4:null) SeqA 23-69611: Sending Seq 23-69611:  { Ans:
, MgmtId: 52244012385, via: 23, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2014-09-23 18:56:10,833 DEBUG [c.c.c.ConsoleProxyManagerImpl]
(consoleproxy-1:ctx-120d1e42) Zone 1 is ready to launch console proxy
2014-09-23 18:56:10,949 DEBUG [o.a.c.s.SecondaryStorageManagerImpl]
(secstorage-1:ctx-2b827d35) Zone 1 is ready to launch secondary storage VM
2014-09-23 18:56:16,215 DEBUG [c.c.a.ApiServlet]
(catalina-exec-2:ctx-1b03b697) ===START===  10.0.1.100 -- GET
 
command=createTemplate&response=json&sessionkey=bKgNoaskvKmQI0pYS%2F9DuT4raSA%3D&snapshotid=907fc0ec-d782-4407-8560-83e335f5c79e&name=testtmp&displayText=testtmp&osTypeId=d84de96a-1495-11e4-ba8d-000c29a411ce&isPublic=false&passwordEnabled=false&isdynamicallyscalable=false&_=1411524124265
2014-09-23 18:56:16,246 DEBUG [c.c.t.TemplateManagerImpl]
(catalina-exec-2:ctx-1b03b697 ctx-11184fc3) This template is getting
created from other template, setting source template Id to: 5
2014-09-23 18:56:16,292 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-2:ctx-1b03b697 ctx-11184fc3) submit async job-4429, details:
AsyncJobVO {id:4429, userId: 2, accountId: 2, instanceType: Template,
instanceId: 230, cmd:
org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
cmdInfo:
{"sessionkey":"bKgNoaskvKmQI0pYS/9DuT4raSA\u003d","cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"d84de96a-1495-11e4-ba8d-000c29a411ce","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"230","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"907fc0ec-d782-4407-8560-83e335f5c79e\",\"com.cloud.template.VirtualMachineTemplate\":\"1c9dff2f-22e9-4349-9bee-3c80d0bb4eea\",\"com.cloud.storage.GuestOS\":\"d84de96a-1495-11e4-ba8d-000c29a411ce\"}","displayText":"testtmp","snapshotid":"907fc0ec-d782-4407-8560-83e335f5c79e","passwordEnabled":"false","name":"testtmp","_":"1411524124265","uuid":"1c9dff2f-22e9-4349-9bee-3c80d0bb4eea","ctxAccountId":"2","ctxStartEventId":"16996"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 52244012385, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-09-23 18:56:16,293 INFO  [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-65:ctx-5c66f5fd job-4429) Add job-4429 into job monitoring
2014-09-23 18:56:16,293 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-65:ctx-5c66f5fd job-4429) Executing AsyncJobVO {id:4429,
userId: 2, accountId: 2, instanceType: Template, instanceId: 230, cmd:
org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin,
cmdInfo:
{"sessionkey":"bKgNoaskvKmQI0pYS/9DuT4raSA\u003d","cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"d84de96a-1495-11e4-ba8d-000c29a411ce","isPublic":"false","isdynamicallyscalable":"false","response":"json","id":"230","ctxDetails":"{\"com.cloud.storage.Snapshot\":\"907fc0e

Re: CloudStack Docker and Mesos Support

[sebgoa]

On Sep 17, 2014, at 12:28 PM, Sebastien Goasguen  wrote:

> 
> On Sep 16, 2014, at 7:20 PM, ilya musayev  
> wrote:
> 
>> Hi all,
>> 
>> Would you know where we stand with Mesos and Docker?
>> 
> 
> That's a big question.
> 
> Mesos is a resource allocator that multiple frameworks can use to run 
> workloads of various sorts.
> The interest is to mix workloads: big data, long running services, parallel 
> computing, docker in order to maximize utilization of your resources.
> 
> For instance Aurora (mesos framework) can execute long running services 
> within docker containers.
> 
> The challenge with docker is the coordination of multiple containers. 
> Kubernetes for example coordinate docker containers to run HA applications.
> 
> What we see (IMHO) is things like Kubernetes being deployed in the cloud 
> (gce, azure, backspace are currently "supported" in kubernetes). And at 
> mesoscon, there was a small demo of running kuberneters as a mesos framework.
> 
> So…bottom line for me is that I see Mesos and everything on top as a workload 
> that can be run in CloudStack. Similar thing with CoreOS. If a CloudStack 
> cloud makes available CoreOS templates, then users can start CoreOS cluster 
> and manage Docker straight up or via Kubernetes (because of course there is 
> CoreOS "support" in Kubernetes).
> 
> Hence, there is nothing to do, except for CloudStack clouds to show that they 
> can offer Mesos* or Kubernetes* on demand.
> 
> However if we were to re-architect CloudStack entirely, we could use Mesos as 
> a base resource allocator and write a VM framework. The framework would ask 
> for "hypervisors" to mesos and once allocated CloudStack would start 
> them…etc. The issue would still be in the networking. The advantage is that a 
> user could run a Mesos cluster and mix workloads: CloudStack + Big Data + 
> docker….
> 
> Anything we can do to make CoreOS "cloud stackable" and create a cloudstack 
> driver in Kubernetes would be really nice.
> 
>> Thanks
>> ilya
> 

I did not mean to kill this discussion….so to get pardoned I wrote this:

https://github.com/runseb/kubernetes-exoscale

-sebastien

Re: Review Request 25536: Adding new test case to verify the fix for issue "Exception when attaching data disk to Rhel vm on vSphere"

[sanjeev n]

> On Sept. 19, 2014, 6:03 a.m., SrikanteswaraRao Talluri wrote:
> > test/integration/component/test_escalations_vmware.py, line 19
> > 
> >
> > can you please avoid import * ?

commit 5fb2b3a0d24c2bcda0745a6b8ff59fae5651e054
Author: sanjeev 
Date:   Wed Sep 10 11:55:26 2014 +0530

Test to verify fix for issue "Exception when attaching data disk to RHEL vm 
on vSphere

Added Rhel6 template details to test_data.py

Signed-off-by: sanjeev 

Fixed review comments provided in RR 25536


- sanjeev


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


On Sept. 11, 2014, 10:31 a.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25536/
> ---
> 
> (Updated Sept. 11, 2014, 10:31 a.m.)
> 
> 
> Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> @desc: Exception when attaching data disk to RHEL VM on vSphere
> Step1: Confirm that vmware.root.disk.controller = "ide" in Global Settings.
> Step2: Register RHEl 6.0 template and deploy a VM.
> Step3: Note that the root disk is attached to IDE.
> Step4: Create new DATA disk and attempt to attach it to the VM.
> Verify that step4 succeeds without any exception
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_vmware.py PRE-CREATION 
>   tools/marvin/marvin/config/test_data.py 4133aba 
> 
> Diff: https://reviews.apache.org/r/25536/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

Re: FTP connection tracking modules missing in VR after upgrade to 4.3.1; Which release will contain the fix?

[Rohit Yadav]

Hi France,

On 22-Sep-2014, at 1:09 pm, France  wrote:
> Hi guys,
>
> i have upgraded from 4.1.1 to 4.3.1 over the weekend. Amongst other 
> regressions i have found this one:
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-7517
>
> So it looks like it is already well known bug and already has a fix.
>
> What can _we_ do to get the fix for 4.3 releases on our production system?

I’ve cherry-picked it to 4.3 branch, you may build from source to get this fix. 
Or, use the rpms from jenkins build.

> Is anyone willing to build a RPM including this fix?
> I see it was fixed only in 4.5. Taking into account what a small fix it is 
> and how important it is, maybe include it in 4.4.1 release also, because it 
> is still not released?
> Also why not add it along with other fixes to 4.3 and release 4.3.2?
> In my personal opinion, ACS has way too few bugfix releases, and lot’s of 
> people have to build their own packages because of that.

RPMs and DEB from latest 4.3 branch will be made available by Jenkins here:
http://jenkins.buildacloud.org/view/4.3

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
http://shapeblue.com/cloudstack-software-engineering



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

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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: Launch a VM (not from a template)

[Adrian Lewis]

I'm glad to see that there's a potential workaround for this. Perhaps this
should be somehow incorporated in the installation process to allow
smaller setups to be implemented on hypervisors with existing VMs. The
main benefit in my mind though is as the OP suggests - DRaAS.

I think that having a "registerVolume" that would import the VM's metadata
and register it into CS management, including renaming to suit the
conventions would be a great addition. As the OP has already mentioned,
this would also open up the possibility of using a number of backup and DR
tools already on the market with minimal effort to integrate with CS - it
would bring the RTO down significantly if the volumes were already in
primary storage, ready to be fired up at will.

This would certainly gain favour in scenarios where CS operators are
looking to run BDR as a service for clients (such as ourselves, the OP and
a growing number of managed service providers currently just offering
backup as a service but not DR). I'm pretty sure that vCloud Director has
a few commercial BDR software options that currently won’t work easily
with CS due to this, or at least the perception by software vendors that
it can't easily be done. Simplifying the process of importing existing VMs
would definitely be something that would increase takeup of CS in certain
use-cases and at the same time boost CS's public visibility through it's
'ecosystem' of partners. If the 'product' is made as partner friendly as
possible, they in turn help the marketing efforts. Vision's DoubleTake had
a CS integration but from what I can tell it's largely been forgotten as
it is no longer supported with 4.3 or 4.4 and there doesn’t seem to be a
roadmap for this update.

Adrian

-Original Message-
From: Nitin Mehta [mailto:nitin.me...@citrix.com]
Sent: 23 September 2014 07:15
To: dev@cloudstack.apache.org
Subject: Re: Launch a VM (not from a template)

Marcus - I think its possible even now in CS. I don¹t think we need
another api.
1. You can create a vm using the deployvm api with flag startvm=false.
This would create vm and its corresponding resources db records without
actually creating them. You can give a dummy template for now as it still
needs a templateid (we should remove this dependence in future).
2. You can then use updateVolume to update the volume with storage pool id
and marking it ready.
3. Finally you use start vm api to start the vm. It would create all the
resources and start the vm. Since the volume is already ready it won't go
into creating the root volume.

Thanks,
-Nitin

On 22/09/14 10:08 PM, "Marcus"  wrote:

>So, we have thought about this a bit as well. Our solution, which we
>haven't actually implemented yet, was to create a
"registerVirtualMachine"
>api call that would be similar to deployVirtualMachine but accept a
>"rootdiskid" and storage pool id.  This would essentially enter a vm into
>the db but just copy the " rootdiskid" into the root volumes space rather
>than creating a new one. This would allow root disks to be created
outside
>of cloudstack and then made known to cloudstack. It wouldn't be terribly
>difficult to implement (the current deploy only creates a root disk if it
>doesn't already exist so would be easy to short circuit), you would want
>to
>ensure the service offering matches the storage tags though.
>
>A "registerVolume" would also be useful.
>On Sep 22, 2014 9:18 PM, "Will Stevens"  wrote:
>
>> ws: inline...
>>
>> Thanks for the response Mike.  :)
>>
>>
>> *Will STEVENS*
>> Lead Developer
>>
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
>> w cloudops.com *|* tw @CloudOps_
>>
>> On Mon, Sep 22, 2014 at 7:39 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> > If you did #1, how would you pick a relevant compute offering? You
>>would
>> > probably need to look first to make sure at least one existed that
>>could
>> > satisfy your requirement(s) and then make sure the resources could be
>> > marked in advance as if they were being consumed.
>> >
>>
>> ws: so in this case the original VM would be managed by CS and the 3rd
>> party software would be backing it up and replicating it to other
>> zones/regions.  technically, we should have all of the information we
>>need
>> about the VM because CS will already know about the original VM which
>>this
>> VM is getting spun up to replace.  essentially this would be used for
>>DR in
>> a different DC.  if one DC goes down for some reason, this would
>>basically
>> behave like a cold standby in a different DC.
>>
>> you did touch on a pipe dream of mine though (which I am still in the
>> process of thinking through).  I want to be able to spin up a fresh CS
>> install and then discover an existing xen pool and then configure CS to
>> step in as an orchestration tool for the existing infra.  I am still
>> thinking through how this would be possible, but this is outside the
>>scope
>> of this specific problem, so I wo

Re: Marvin Package?

[Rohit Yadav]

Hi David,

On 22-Sep-2014, at 4:54 am, David Nalley  wrote:
> Sharing things on pypi is a distribution channel for end users -  if
> it's done by the project, it must be voted on and released. If it's
> done by an individual, they can't post anything they want, but we'll
> have to insist that they don't use our trademarks (e.g. both Marvin
> and CloudStack will need to be removed from the package name)

For all the previously voted releases of CloudStack, can we still build marvin 
from those source releases and publish on pypi (keeping the marvin version same 
as CloudStack version to avoid confusion)?

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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: conf values for 4.4 from master

[Daan Hoogland]

I see one more of them:

INSERT INTO `cloud`.`configuration`(category, instance, component, name,
value, description, default_value) VALUES ('Advanced', 'DEFAULT',
'NetworkOrchestrationService', 'router.redundant.vrrp.interval', '1',
'seconds between VRRP broadcast. It would 3 times broadcast fail to trigger
fail-over mechanism of redundant router', '1') ON DUPLICATE KEY UPDATE
category='Advanced';


On Tue, Sep 23, 2014 at 11:38 AM, Daan Hoogland 
wrote:

> Sheng,
>
> these two lines where added by you to the file schema-430to440.sql in
> master but not in 4.4
>
> INSERT INTO `cloud`.`configuration`(category, instance, component, name,
> value, description, default_value) VALUES ('Advanced', 'DEFAULT',
> 'NetworkOrchestrationService', 'router.redundant.vrrp.interval', '1',
> 'seconds between VRRP broadcast. It would 3 times broadcast fail to trigger
> fail-over mechanism of redundant router', '1') ON DUPLICATE KEY UPDATE
> category='Advanced';
> INSERT INTO `cloud`.`configuration`(category, instance, component, name,
> value, description, default_value) VALUES ('Advanced', 'DEFAULT',
> 'NetworkOrchestrationService', 'router.aggregation.command.each.timeout',
> '3', 'timeout in seconds for each Virtual Router command being aggregated.
> The final aggregation command timeout would be determined by this timeout *
> commands counts ', '3') ON DUPLICATE KEY UPDATE category='Advanced';
>
> Is it sensible to add them in 4.4 as well?
>
> --
> Daan
>



-- 
Daan

Build failed in Jenkins: simulator-singlerun #422

[jenkins]

See 

--
[...truncated 8851 lines...]
> WARNING: Provided file does not exist: 

> Initializing database=simulator with host=localhost port=3306 
username=cloud password=cloud
> Running query: drop database if exists `simulator`
> Running query: create database `simulator`
> Running query: GRANT ALL ON simulator.* to 'cloud'@`localhost` 
identified by 'cloud'
> Running query: GRANT ALL ON simulator.* to 'cloud'@`%` identified 
by 'cloud'
> Processing SQL file at 

> Processing SQL file at 

> Processing SQL file at 

> Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[INFO] 
[INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ 
cloud-developer ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-developer ---
[INFO] Installing 
 
to 
/var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.5.0-SNAPSHOT/cloud-developer-4.5.0-SNAPSHOT.pom
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 33.948s
[INFO] Finished at: Tue Sep 23 05:53:44 EDT 2014
[INFO] Final Memory: 42M/202M
[INFO] 
[simulator-singlerun] $ /bin/bash -x /tmp/hudson4873913338587795182.sh
+ jps -l
+ grep -q Launcher
+ echo Killing leftover management servers
Killing leftover management servers
++ jps -l
++ awk '{print $1}'
++ grep Launcher
+ kill -KILL 11174
+ sleep 10
+ rm -f xunit.xml
+ rm -rf /tmp/MarvinLogs
+ echo Check for initialization of the management server
Check for initialization of the management server
+ COUNTER=0
+ SERVER_PID=18603
+ mvn -P systemvm,simulator -pl :cloud-client-ui jetty:run
+ '[' 0 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=1
+ '[' 1 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=2
+ '[' 2 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=3
+ '[' 3 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=4
+ '[' 4 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=5
+ '[' 5 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=6
+ '[' 6 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=7
+ '[' 7 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=8
+ '[' 8 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=9
+ '[' 9 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=10
+ '[' 10 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=11
+ '[' 11 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=12
+ '[' 12 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=13
+ '[' 13 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=14
+ '[' 14 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=15
+ '[' 15 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=16
+ '[' 16 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=17
+ '[' 17 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=18
+ '[' 18 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=19
+ '[' 19 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=20
+ '[' 20 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=21
+ '[' 21 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-output.out
+ sleep 5
+ COUNTER=22
+ '[' 22 -lt 44 ']'
+ grep -q 'Management server node 127.0.0.1 is up' jetty-ou

conf values for 4.4 from master

[Daan Hoogland]

Sheng,

these two lines where added by you to the file schema-430to440.sql in
master but not in 4.4

INSERT INTO `cloud`.`configuration`(category, instance, component, name,
value, description, default_value) VALUES ('Advanced', 'DEFAULT',
'NetworkOrchestrationService', 'router.redundant.vrrp.interval', '1',
'seconds between VRRP broadcast. It would 3 times broadcast fail to trigger
fail-over mechanism of redundant router', '1') ON DUPLICATE KEY UPDATE
category='Advanced';
INSERT INTO `cloud`.`configuration`(category, instance, component, name,
value, description, default_value) VALUES ('Advanced', 'DEFAULT',
'NetworkOrchestrationService', 'router.aggregation.command.each.timeout',
'3', 'timeout in seconds for each Virtual Router command being aggregated.
The final aggregation command timeout would be determined by this timeout *
commands counts ', '3') ON DUPLICATE KEY UPDATE category='Advanced';

Is it sensible to add them in 4.4 as well?

-- 
Daan

Build failed in Jenkins: simulator-singlerun #421

[jenkins]

See 

Changes:

[sanjeev] Creating custom disk does not work as expected

[Daan Hoogland] CLOUDSTACK-6603 [Upgrade]DB Exception while Autoscale 
monitoring after upgrading from 4.3 to 4.4

--
[...truncated 8521 lines...]
hard linking marvin/cloudstackAPI/updateIsoPermissions.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateLBHealthCheckPolicy.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateLBStickinessPolicy.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateLoadBalancer.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateLoadBalancerRule.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateNetwork.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateNetworkACLItem.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateNetworkACLList.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateNetworkOffering.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateNetworkServiceProvider.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updatePhysicalNetwork.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updatePod.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updatePortForwardingRule.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateProject.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateProjectInvitation.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateRegion.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateRemoteAccessVpn.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateResourceCount.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateResourceLimit.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateServiceOffering.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateSnapshotPolicy.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateStorageNetworkIpRange.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateStoragePool.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateTemplate.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateTemplatePermissions.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateTrafficType.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateUser.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateVMAffinityGroup.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateVPC.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateVPCOffering.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateVirtualMachine.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateVolume.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateVpnConnection.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateVpnCustomerGateway.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateVpnGateway.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/updateZone.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/upgradeRouterTemplate.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/uploadCustomCertificate.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/uploadSslCert.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/cloudstackAPI/uploadVolume.py -> 
Marvin-4.5.0-SNAPSHOT/marvin/cloudstackAPI
hard linking marvin/config/__init__.py -> Marvin-4.5.0-SNAPSHOT/marvin/config
hard linking marvin/config/test_data.py -> Marvin-4.5.0-SNAPSHOT/marvin/config
hard linking marvin/lib/__init__.py -> Marvin-4.5.0-SNAPSHOT/marvin/lib
hard linking marvin/lib/base.py -> Marvin-4.5.0-SNAPSHOT/marvin/lib
hard linking marvin/lib/common.py -> Marvin-4.5.0-SNAPSHOT/marvin/lib
hard linking marvin/lib/utils.py -> Marvin-4.5.0-SNAPSHOT/marvin/lib
hard linking marvin/sandbox/__init__.py -> Marvin-4.5.0-SNAPSHOT/marvin/sandbox
hard linking m

Review Request 25934: Fixed various bugs in AlertsSyslogAppender

[Anshul Gangwar]

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

Review request for cloudstack, Devdeep Singh and Sateesh Chodapuneedi.


Bugs: CLOUDSTACK-7610, CLOUDSTACK-7611 and CLOUDSTACK-7612
https://issues.apache.org/jira/browse/CLOUDSTACK-7610
https://issues.apache.org/jira/browse/CLOUDSTACK-7611
https://issues.apache.org/jira/browse/CLOUDSTACK-7612


Repository: cloudstack-git


Description
---

Fixed following bugs in AlertsSyslogAppender
1. Added sync alert.
2. Changed unrecognised alerts are send as unknown instead of null.
3. Added unit tests to cover some more scenarios.


Diffs
-

  
plugins/alert-handlers/syslog-alerts/src/org/apache/cloudstack/syslog/AlertsSyslogAppender.java
 5f6e8ec 
  
plugins/alert-handlers/syslog-alerts/test/org/apache/cloudstack/syslog/AlertsSyslogAppenderTest.java
 5799348 

Diff: https://reviews.apache.org/r/25934/diff/


Testing
---

Added unit tests and all were passing fine


Thanks,

Anshul Gangwar

Re: Review Request 25933: CLOUDSTACK-7408: Fixed - Private key of the ssh keypair was getting corrupted

[Gaurav Aradhye]

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

(Updated Sept. 23, 2014, 2:40 p.m.)


Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.


Bugs: CLOUDSTACK-7408
https://issues.apache.org/jira/browse/CLOUDSTACK-7408


Repository: cloudstack-git


Description (updated)
---

Test cases in test suite test_reset_ssh_keypair.py failed while trying SSH 
using the private key file after resetting SSH keypair (CS sends private key to 
client, public key to ssh host - in this case VM).

SSH failed because the private key file was getting corrupted because it was 
passed to Paramiko's load_host_keys() function. This function loads the host 
key (fingerprint) into the passed file. Here path to known_hosts file should be 
passed instead of path to private key file.

Also set the "look_for_keys" option to False because we don't want Paramiko to 
look for ssh keys at default location, because we are passing the private key 
itself and it is stored in temporary location.

I have added extra parameter "knownHostsFilePath" which is initialised in 
sshClient class. This can be used in future if some user has his/her 
known_hosts file at different location than ~/.ssh/known_hosts. However, there 
is no necessity to pass this value from test cases as of now, it will be taken 
the default.


Diffs
-

  tools/marvin/marvin/lib/base.py b0dd6e2 
  tools/marvin/marvin/lib/utils.py 8788b3b 
  tools/marvin/marvin/sshClient.py df2 

Diff: https://reviews.apache.org/r/25933/diff/


Testing
---

Yes. I ran two test classes present in this test suite separately, hence adding 
separate logs.

Log:

[I]
Test Reset SSH keys for VM  already having SSH key ... === TestName: 
test_01_reset_ssh_keys | Status : SUCCESS ===
ok
Reset SSH keys for VM  created from password enabled template and ... === 
TestName: test_02_reset_ssh_key_password_enabled_template | Status : SUCCESS ===
ok
Reset SSH key for VM  having no SSH key ... === TestName: 
test_03_reset_ssh_with_no_key | Status : SUCCESS ===
ok
Reset SSH keys for VM  created from password enabled template and ... === 
TestName: test_04_reset_key_passwd_enabled_no_key | Status : SUCCESS ===
ok
Reset SSH keys for VM  already having SSH key when VM is in running ... === 
TestName: test_05_reset_key_in_running_state | Status : SUCCESS ===
ok
Reset SSH keys for VM  created from password enabled template and ... === 
TestName: test_06_reset_key_passwd_enabled_vm_running | Status : SUCCESS ===
ok
Verify API resetSSHKeyForVirtualMachine with incorrect parameters ... === 
TestName: test_07_reset_keypair_invalid_params | Status : SUCCESS ===
ok

--
Ran 7 tests in 2247.949s

OK


[II]

Verify API resetSSHKeyForVirtualMachine for non admin non root ... === 
TestName: test_01_reset_keypair_normal_user | Status : SUCCESS ===
ok
Verify API resetSSHKeyForVirtualMachine for domain admin non root ... === 
TestName: test_02_reset_keypair_domain_admin | Status : SUCCESS ===
ok
Verify API resetSSHKeyForVirtualMachine for domain admin root ... === TestName: 
test_03_reset_keypair_root_admin | Status : SUCCESS ===
ok

--
Ran 3 tests in 1866.305s

OK


Thanks,

Gaurav Aradhye

Review Request 25933: CLOUDSTACK-7408: Fixed - Private key of the ssh keypair was getting corrupted

[Gaurav Aradhye]

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

Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.


Bugs: CLOUDSTACK-7408
https://issues.apache.org/jira/browse/CLOUDSTACK-7408


Repository: cloudstack-git


Description
---

Test cases in test suite failed while trying SSH using the private key file 
after resetting SSH keypair (CS sends private key to client, public key to ssh 
host - in this case VM).

SSH failed because the private key file was getting corrupted because it was 
passed to Paramiko's load_host_keys() function. This function loads the host 
key (fingerprint) into the passed file. Here path to known_hosts file should be 
passed instead of path to private key file.

Also set the "look_for_keys" option to False because we don't want Paramiko to 
look for ssh keys at default location, because we are passing the private key 
itself and it is stored in temporary location.

I have added extra parameter "knownHostsFilePath" which is initialised in 
sshClient class. This can be used in future if some user has his/her 
known_hosts file at different location than ~/.ssh/known_hosts. However, there 
is no necessity to pass this value from test cases as of now, it will be taken 
the default.


Diffs
-

  tools/marvin/marvin/lib/base.py b0dd6e2 
  tools/marvin/marvin/lib/utils.py 8788b3b 
  tools/marvin/marvin/sshClient.py df2 

Diff: https://reviews.apache.org/r/25933/diff/


Testing
---

Yes. I ran two test classes present in this test suite separately, hence adding 
separate logs.

Log:

[I]
Test Reset SSH keys for VM  already having SSH key ... === TestName: 
test_01_reset_ssh_keys | Status : SUCCESS ===
ok
Reset SSH keys for VM  created from password enabled template and ... === 
TestName: test_02_reset_ssh_key_password_enabled_template | Status : SUCCESS ===
ok
Reset SSH key for VM  having no SSH key ... === TestName: 
test_03_reset_ssh_with_no_key | Status : SUCCESS ===
ok
Reset SSH keys for VM  created from password enabled template and ... === 
TestName: test_04_reset_key_passwd_enabled_no_key | Status : SUCCESS ===
ok
Reset SSH keys for VM  already having SSH key when VM is in running ... === 
TestName: test_05_reset_key_in_running_state | Status : SUCCESS ===
ok
Reset SSH keys for VM  created from password enabled template and ... === 
TestName: test_06_reset_key_passwd_enabled_vm_running | Status : SUCCESS ===
ok
Verify API resetSSHKeyForVirtualMachine with incorrect parameters ... === 
TestName: test_07_reset_keypair_invalid_params | Status : SUCCESS ===
ok

--
Ran 7 tests in 2247.949s

OK


[II]

Verify API resetSSHKeyForVirtualMachine for non admin non root ... === 
TestName: test_01_reset_keypair_normal_user | Status : SUCCESS ===
ok
Verify API resetSSHKeyForVirtualMachine for domain admin non root ... === 
TestName: test_02_reset_keypair_domain_admin | Status : SUCCESS ===
ok
Verify API resetSSHKeyForVirtualMachine for domain admin root ... === TestName: 
test_03_reset_keypair_root_admin | Status : SUCCESS ===
ok

--
Ran 3 tests in 1866.305s

OK


Thanks,

Gaurav Aradhye

Re: console proxy HTTPS in 4.3.1, static option, clarification please

[France]

Thank you for your answer.

On 22 Sep 2014, at 18:58, Amogh Vasekar  wrote:

> Hi,
> 
> No, option (3) is not fully supported yet since it needs integration with
> a load balancer for all console proxy VM ips. Please see the note at
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes#
> RealhostIPchanges-ConsoleProxy.1
> 
> Amogh
> 
> On 9/22/14 4:47 AM, "France"  wrote:
> 
>> Hi,
>> 
>> because i get confusing information on the internet, i would like to ask
>> here for clarification.
>> 
>> There are three options for
>> consoleproxy.url.domain
>> configure setting.
>> 
>> 1. Disable it with empty string.
>> Not really an option, because iframe to http from https, is silently
>> blocked by browsers now-days. If there would be a link to click instead
>> of iframe it could work and i would be done with it.
>> 
>> 2. *.somedomain.xxx
>> Wildcard option. Requires to run own DNS server and buying of expensive
>> certificates. Not really an option, due to too high costs of wildcard and
>> setting up of another unnecessary service.
>> 
>> 3. secure.somedomain.xxx
>> Static option which would allow us to use a single FQDN certificate. This
>> is acceptable for us, but upon testing with 4.3.1 (restart of ACS,
>> destruction of console proxy SVM) did not link to secure.somedomain.xxx.
>> 
>> Before i loose any more time with thir doption. Does it work with 3.4.1?
>> 
>> 
>> According to documentation for 4.3 on:
>> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.
>> 3/search.html?q=consoleproxy.url.domain&check_keywords=yes&area=default
>> in:
>> Working with System Virtual Machines
>> Console Proxy
>> 
>> Load-balancing Console Proxies
>> 
>> An alternative to using dynamic DNS or creating a range of DNS entries as
>> described in the last section would be to create a SSL certificate for a
>> specific domain name, configure CloudStack to use that particular FQDN,
>> and then configure a load balancer to load balance the console proxy¹s IP
>> address behind the FQDN. As the functionality for this is still new,
>> please 
>> seehttps://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+chan
>> ges for more details.
>> 
>> 
>> Regards,
>> F

baremetal in master and 4.4

[Daan Hoogland]

Frank,

Can you have a look at commit 781ad96b04c9030fc1c0a0401145414e7f3978aa ? It
is only on master, not on 4.4 but it contains a change in
schema-430to440.sql

I'd say the easiest remedy is to revert and recreate with the db change in
another db upgrade file.


-- 
Daan

Re: Review Request 25580: Adding test case to verify fix for issue "Create volume from custom disk offering does not work as expected"

[sanjeev n]

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

Ship it!


commit 0d5a435f7669eddd44a6b62317fe26bb1d96e96c
Author: sanjeev 
Date:   Tue Sep 23 14:15:39 2014 +0530

Creating custom disk does not work as expected

- sanjeev n


On Sept. 12, 2014, 1:32 p.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25580/
> ---
> 
> (Updated Sept. 12, 2014, 1:32 p.m.)
> 
> 
> Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> @Desc:Create volume from custom disk offering does not work as expected
> Step1:Create custom disk offering
> Step2:Create Volume with size x
> Step3:Attach that volume to a vm
> Step4:Create another volume with size y
> Step5:Verify that the new volume is created with size Y but not with size X
>   
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_volumes.py db4c3d8 
>   tools/marvin/marvin/lib/base.py 04217b2 
> 
> Diff: https://reviews.apache.org/r/25580/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> @Desc:Create volume from custom disk offering does not work as expected ... 
> === TestName: test_13_volume_custom_disk_size | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 303.508s
> 
> OK
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

Re: git commit: updated refs/heads/master to b8795d8

[Daan Hoogland]

Frank I had a look at this commit and found an issue with it. Please look
at my comments in the last file:

On Tue, Sep 23, 2014 at 12:53 AM,  wrote:
​...


>
> Branch: refs/heads/master
> Commit: b8795d88796aa5b9a736fff3ad6fbcf5d6f2b825
> Parents: 6655d8f
> Author: Frank Zhang 
> Authored: Mon Sep 22 15:56:57 2014 -0700
> Committer: Frank Zhang 
> Committed: Mon Sep 22 15:56:57 2014 -0700
>
​...​

http://git-wip-us.apache.org/repos/asf/cloudstack/blob/b8795d88/plugins/hypervisors/baremetal/src/org/apache/cloudstack/api/ListBaremetalRctCmd.java
> --
> diff --git
> a/plugins/hypervisors/baremetal/src/org/apache/cloudstack/api/ListBaremetalRctCmd.java
> b/plugins/hypervisors/baremetal/src/org/apache/cloudstack/api/ListBaremetalRctCmd.java
> new file mode 100755
> index 000..3a69f3c
> --- /dev/null
> +++
> b/plugins/hypervisors/baremetal/src/org/apache/cloudstack/api/ListBaremetalRctCmd.java
> @@ -0,0 +1,69 @@
> +// Licensed to the Apache Software Foundation (ASF) under one
> +// or more contributor license agreements.  See the NOTICE file
> +// distributed with this work for additional information
> +// regarding copyright ownership.  The ASF licenses this file
> +// to you under the Apache License, Version 2.0 (the
> +// "License"); you may not use this file except in compliance
> +// with the License.  You may obtain a copy of the License at
> +//
> +//   http://www.apache.org/licenses/LICENSE-2.0
> +//
> +// Unless required by applicable law or agreed to in writing,
> +// software distributed under the License is distributed on an
> +// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> +// KIND, either express or implied.  See the License for the
> +// specific language governing permissions and limitations
> +// under the License.
> +//
> +// Automatically generated by addcopyright.py at 01/29/2013
> +package org.apache.cloudstack.api;
> +
> +import com.cloud.baremetal.manager.BaremetalVlanManager;
> +import com.cloud.baremetal.networkservice.BaremetalRctResponse;
> +import com.cloud.exception.ConcurrentOperationException;
> +import com.cloud.exception.InsufficientCapacityException;
> +import com.cloud.exception.NetworkRuleConflictException;
> +import com.cloud.exception.ResourceAllocationException;
> +import com.cloud.exception.ResourceUnavailableException;
> +import org.apache.cloudstack.acl.RoleType;
> +import org.apache.cloudstack.api.response.ListResponse;
> +import org.apache.log4j.Logger;
> +
> +import javax.inject.Inject;
> +import java.util.ArrayList;
> +import java.util.List;
> +
> +@APICommand(name = "listBaremetalRct", description = "list baremetal rack
> configuration", responseObject = BaremetalRctResponse.class,
> +requestHasSensitiveInfo = false, responseHasSensitiveInfo =
> false, authorized = {RoleType.Admin})
> +public class ListBaremetalRctCmd extends BaseListCmd {
> +private static final Logger s_logger =
> Logger.getLogger(ListBaremetalRctCmd.class);
> +private static final String s_name = "listbaremetalrctresponse";
> +@Inject
> +BaremetalVlanManager vlanMgr;
> +
>

​here Exception is caught, only ServerApiException is thrown but a long
list of exceptions is declared:
​


> +@Override
> +public void execute() throws ResourceUnavailableException,
> InsufficientCapacityException, ServerApiException,
> ConcurrentOperationException,
> +ResourceAllocationException, NetworkRuleConflictException {
> +try {
> +ListResponse response = new
> ListResponse<>();
> +List rctResponses = new ArrayList<>();
> +BaremetalRctResponse rsp = vlanMgr.listRct();
> +if (rsp != null) {
> +rctResponses.add(rsp);
> +}
> +response.setResponses(rctResponses);
> +response.setResponseName(getCommandName());
> +response.setObjectName("baremetalrcts");
> +this.setResponseObject(response);
>

​only what is actually thrown​

​should be caught​

> +} catch (Exception e) {
> +s_logger.debug("Exception happened while executing
> ListBaremetalRctCmd", e);
> +throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR,
> e.getMessage());
> +}
> +}
> +
> +@Override
> +public String getCommandName() {
> +return s_name;
> +}
> +
> +}
>
>


-- 
Daan

Re: Review Request 25771: Adding new test case to verify the fix provided in bug CLOUDSTACK-6172

[SrikanteswaraRao Talluri]

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

Ship it!


Ship It!

- SrikanteswaraRao Talluri


On Sept. 23, 2014, 6:29 a.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25771/
> ---
> 
> (Updated Sept. 23, 2014, 6:29 a.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CS-6172
> https://issues.apache.org/jira/browse/CS-6172
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> @Desc:Volume is not retaining same uuid when migrating from one storage to 
> another.
> Step1:Create a volume/data disk
> Step2:Verify UUID of the volume
> Step3:Migrate the volume to another primary storage within the cluster
> Step4:Migrating volume to new primary storage should succeed
> Step5:volume UUID should not change even after migration
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_volumes.py 122f2d1 
> 
> Diff: https://reviews.apache.org/r/25771/diff/
> 
> 
> Testing
> ---
> 
> Yes
> @Desc:Volume is not retaining same uuid when migrating from one storage to 
> another. ... === TestName: test_01_migrateVolume | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 343.250s
> 
> OK
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

Re: schema-430to440.sql: not same file in master and 4.4 branches

[Daan Hoogland]

On Mon, Sep 22, 2014 at 11:01 PM, Pierre-Luc Dion 
wrote:

> Look like current file: setup/db/db/schema-430to440.sql are not same in
> master branch and 4.4.
> This is a problem I guest.
>
> at least this file is the reason why in 4.4.0 and 4.4.1 we can't create vm
> using Windows2012r2 or CentOs 6.5 on XenServer.
>
> please see here:
>
> 4.4 file history
>
> https://github.com/apache/cloudstack/commits/4.4/setup/db/db/schema-430to440.sql
>
> master file history:
>
> https://github.com/apache/cloudstack/commits/master/setup/db/db/schema-430to440.sql
>
> would it make sense is the one in master be replace by the one in 4.4
> branch ?
>
​I think a more ​intelligent merge is needed. I can see two way changes.

@Ian: can you have a quick look at your changes to master?


> also, I'd like to  fix  new OS type introduce in 4.4.0 in 4.4.1, can we
> update 4.4.1 for missing xenserver mapping?
>
​ok, go ahead.​

Thanks
>
> *Pierre-Luc DION*
>

-- 
Daan