Anyone else see these errors in Eclipse?

[Mike Tutkowski]

"display cannot be resolved to a variable"

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

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: [Merge] CloudStack IAM branch to master

[Kelven Yang]

It is already in 4.4 as well.

Kelven

On 3/14/14, 3:58 PM, "Marcus"  wrote:

>That is, I'll pull the current 4.4 into my branch and test before I merge
>it in
>
>
>On Fri, Mar 14, 2014 at 4:57 PM, Marcus  wrote:
>> Can we get the fix in 4.4? I'd rather sync that then master, since it
>> has been cut already.
>>
>>
>> On Fri, Mar 14, 2014 at 4:00 PM, Kelven Yang 
>>wrote:
>>> Marcus,
>>>
>>> I¹ve pushed the fix to master already. You probably need to sync your
>>> local branch with master
>>>
>>> Kelven
>>>
>>> On 3/14/14, 11:08 AM, "Marcus"  wrote:
>>>
It's in branch resize-root

On Fri, Mar 14, 2014 at 10:47 AM, Min Chen  wrote:
> Marcus,
>
> What is the latest commit you have picked up on your local
>setup from
> master? Our QA reports similar issues caused by recent VMSync bug
>fix,
> just want to make sure that your local code has that fix.
>
> Thanks
> -min
>
> On 3/14/14 9:37 AM, "Min Chen"  wrote:
>
>>Before merge, I did a sanity zone and VM deployment test, and worked
>>fine
>>on my setup after fixing the issues introduced by Antonio's commit. I
>>can
>>verify this again today. From the symptom, it seems not related to
>>IAM
>>change.
>>
>>Thanks
>>-min
>>
>>
>>
>>On 3/14/14 1:07 AM, "Marcus"  wrote:
>>
>>>creating a new router does the same...
>>>
>>>2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
>>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
>>>VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
>>>time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
>>>updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
>>>State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
>>>2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
>>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
>>>instance VM[DomainRouter|r-5-VM]
>>>com.cloud.exception.ConcurrentOperationException: Unable to
>>>transition
>>>to a new state.
>>>at
>>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachi
>>>neM
>>>an
>>>a
>>>gerImpl.java:1029)
>>>at
>>>com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineMa
>>>nag
>>>er
>>>I
>>>mpl.java:775)
>>>
>>>On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
 I have no idea if its related to this branch merge or not, but I'm
 unable to start the ssvm on master since I pulled about an hour
ago.
I
 can deploy a fresh zone, and the ssvm will actually start, but it
 can't transition state in the DB, so it kills the vm.

 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
 (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
 VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
 updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
 State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014}
Stale
 Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14
01:56:38
 MDT 2014}
 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
 (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
 instance VM[SecondaryStorageVm|s-1-VM]
 com.cloud.exception.ConcurrentOperationException: Unable to
transition
 to a new state.
 at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMach
ine
Ma
n
agerImpl.java:1029)
 at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMach
ine
Ma
n
agerImpl.java:5129)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp
l.j
av
a
:57)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc
ess
or
I
mpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandler
Pro
xy
.
java:107)
 at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachi
neM
an
a
gerImpl.java:5274)
 at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:10
2)
 at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run
InC
on
t
ext(AsyncJobManagerImpl.java:491)
 at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(
Man
ag
e
dConte

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Edison Su]

> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: Friday, March 14, 2014 4:15 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> On 14.03.2014 21:57, Edison Su wrote:
> > Add a fix: e5c391fcf3852e50ebd99d4a72fd51d1753b05eb on 4.3-forward
> > branch.
> > I do see the rule coming on the kvm host:
> >
> > -A FORWARD -o cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0
> > -A FORWARD -i cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0
> > -A FORWARD -o cloudbr0 -j DROP -A FORWARD -i cloudbr0 -j DROP
> 
> There seems to be a problem with the fixed script, too. The first rule applied
> to a SG doesn't really get applied on the hypervisor, once you add more rules
> the first rule get activated as well. I have replaced your script with the one

From my test, all the rules got applied. If you stop/start vm, will the first 
rule get applied?
Let's for QA team's testing.

> from 4.2.1 and that one works as expected.
> 
> I'll do more testing tomorrow.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

IAM guidelines for CS APIs

[Prachi Damle]

Hi there,

With the introduction of the IAM feature, there are some new 
annotations/mechanisms to implement access control at CS API and Service layer.

Min and I have documented guidelines to follow while adding APIs to CloudStack:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+IAM+guidelines+for+API+and+Service+Layer


If you are adding a new API or modifying an existing one, please refer this 
document to know:

-  How to set API permissions

-  How to use annotations for specifying correct entity permissions in  
CUD APIs

-  How to write list API's

-  How to support  Response View Separation for API Commands


Thank you,
Prachi

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 21:57, Edison Su wrote:
Add a fix: e5c391fcf3852e50ebd99d4a72fd51d1753b05eb on 4.3-forward 
branch.

I do see the rule coming on the kvm host:

-A FORWARD -o cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0
-A FORWARD -i cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0
-A FORWARD -o cloudbr0 -j DROP
-A FORWARD -i cloudbr0 -j DROP


There seems to be a problem with the fixed script, too. The first rule 
applied to a SG doesn't really get applied on the hypervisor, once you 
add more rules the first rule get activated as well. I have replaced 
your script with the one from 4.2.1 and that one works as expected.


I'll do more testing tomorrow.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [Merge] CloudStack IAM branch to master

[Marcus]

That is, I'll pull the current 4.4 into my branch and test before I merge it in


On Fri, Mar 14, 2014 at 4:57 PM, Marcus  wrote:
> Can we get the fix in 4.4? I'd rather sync that then master, since it
> has been cut already.
>
>
> On Fri, Mar 14, 2014 at 4:00 PM, Kelven Yang  wrote:
>> Marcus,
>>
>> I¹ve pushed the fix to master already. You probably need to sync your
>> local branch with master
>>
>> Kelven
>>
>> On 3/14/14, 11:08 AM, "Marcus"  wrote:
>>
>>>It's in branch resize-root
>>>
>>>On Fri, Mar 14, 2014 at 10:47 AM, Min Chen  wrote:
 Marcus,

 What is the latest commit you have picked up on your local
setup from
 master? Our QA reports similar issues caused by recent VMSync bug fix,
 just want to make sure that your local code has that fix.

 Thanks
 -min

 On 3/14/14 9:37 AM, "Min Chen"  wrote:

>Before merge, I did a sanity zone and VM deployment test, and worked
>fine
>on my setup after fixing the issues introduced by Antonio's commit. I
>can
>verify this again today. From the symptom, it seems not related to IAM
>change.
>
>Thanks
>-min
>
>
>
>On 3/14/14 1:07 AM, "Marcus"  wrote:
>
>>creating a new router does the same...
>>
>>2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
>>VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
>>time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
>>updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
>>State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
>>2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
>>instance VM[DomainRouter|r-5-VM]
>>com.cloud.exception.ConcurrentOperationException: Unable to transition
>>to a new state.
>>at
>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineM
>>an
>>a
>>gerImpl.java:1029)
>>at
>>com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManag
>>er
>>I
>>mpl.java:775)
>>
>>On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
>>> I have no idea if its related to this branch merge or not, but I'm
>>> unable to start the ssvm on master since I pulled about an hour ago.
>>>I
>>> can deploy a fresh zone, and the ssvm will actually start, but it
>>> can't transition state in the DB, so it kills the vm.
>>>
>>> 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
>>> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
>>> VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
>>> updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
>>> State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014} Stale
>>> Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14 01:56:38
>>> MDT 2014}
>>> 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
>>> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
>>> instance VM[SecondaryStorageVm|s-1-VM]
>>> com.cloud.exception.ConcurrentOperationException: Unable to
>>>transition
>>> to a new state.
>>> at
>>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachine
>>>Ma
>>>n
>>>agerImpl.java:1029)
>>> at
>>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachine
>>>Ma
>>>n
>>>agerImpl.java:5129)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>>>av
>>>a
>>>:57)
>>> at
>>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>>>or
>>>I
>>>mpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:606)
>>> at
>>>com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerPro
>>>xy
>>>.
>>>java:107)
>>> at
>>>com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineM
>>>an
>>>a
>>>gerImpl.java:5274)
>>> at
>>>com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
>>> at
>>>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInC
>>>on
>>>t
>>>ext(AsyncJobManagerImpl.java:491)
>>> at
>>>org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Man
>>>ag
>>>e
>>>dContextRunnable.java:49)
>>> at
>>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.cal
>>>l(
>>>D
>>>efaultManagedContext.java:56)
>>> at
>>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callW
>>>it
>>>h
>>>Context(DefaultManagedContext.java:103)
>>> at
>>>org.apache.clouds

Re: [Merge] CloudStack IAM branch to master

[Marcus]

Can we get the fix in 4.4? I'd rather sync that then master, since it
has been cut already.


On Fri, Mar 14, 2014 at 4:00 PM, Kelven Yang  wrote:
> Marcus,
>
> I¹ve pushed the fix to master already. You probably need to sync your
> local branch with master
>
> Kelven
>
> On 3/14/14, 11:08 AM, "Marcus"  wrote:
>
>>It's in branch resize-root
>>
>>On Fri, Mar 14, 2014 at 10:47 AM, Min Chen  wrote:
>>> Marcus,
>>>
>>> What is the latest commit you have picked up on your local
>>>setup from
>>> master? Our QA reports similar issues caused by recent VMSync bug fix,
>>> just want to make sure that your local code has that fix.
>>>
>>> Thanks
>>> -min
>>>
>>> On 3/14/14 9:37 AM, "Min Chen"  wrote:
>>>
Before merge, I did a sanity zone and VM deployment test, and worked
fine
on my setup after fixing the issues introduced by Antonio's commit. I
can
verify this again today. From the symptom, it seems not related to IAM
change.

Thanks
-min



On 3/14/14 1:07 AM, "Marcus"  wrote:

>creating a new router does the same...
>
>2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
>VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
>time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
>updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
>State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
>2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
>instance VM[DomainRouter|r-5-VM]
>com.cloud.exception.ConcurrentOperationException: Unable to transition
>to a new state.
>at
>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineM
>an
>a
>gerImpl.java:1029)
>at
>com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManag
>er
>I
>mpl.java:775)
>
>On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
>> I have no idea if its related to this branch merge or not, but I'm
>> unable to start the ssvm on master since I pulled about an hour ago.
>>I
>> can deploy a fresh zone, and the ssvm will actually start, but it
>> can't transition state in the DB, so it kills the vm.
>>
>> 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
>> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
>> VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
>> updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
>> State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014} Stale
>> Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14 01:56:38
>> MDT 2014}
>> 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
>> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
>> instance VM[SecondaryStorageVm|s-1-VM]
>> com.cloud.exception.ConcurrentOperationException: Unable to
>>transition
>> to a new state.
>> at
>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachine
>>Ma
>>n
>>agerImpl.java:1029)
>> at
>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachine
>>Ma
>>n
>>agerImpl.java:5129)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>>av
>>a
>>:57)
>> at
>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>>or
>>I
>>mpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at
>>com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerPro
>>xy
>>.
>>java:107)
>> at
>>com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineM
>>an
>>a
>>gerImpl.java:5274)
>> at
>>com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
>> at
>>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInC
>>on
>>t
>>ext(AsyncJobManagerImpl.java:491)
>> at
>>org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Man
>>ag
>>e
>>dContextRunnable.java:49)
>> at
>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.cal
>>l(
>>D
>>efaultManagedContext.java:56)
>> at
>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callW
>>it
>>h
>>Context(DefaultManagedContext.java:103)
>> at
>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWi
>>th
>>C
>>ontext(DefaultManagedContext.java:53)
>> at
>>org.apache.cloudstack.managed.context.ManagedContextRunnable.run(Manag
>>ed
>>C
>>ontextRunnable.java:46)
>> at
>>org.apache.

Re: review request hook for git

[Daan Hoogland]

anybody gave it apin?

just put it in your local .git/hooks/prepare-commit-msg and it should
do its job. It's job is to do nothing if you don't add or update any
files that end with .sql and to add the tag [DB-CHANGE] to the commit
message if you do.

I would like some feedback before I apply. Like is .sql the only
pattern? Or should I include *VO.java or *DaoImpl.java? (maybe later)

Also some test runs to see if quirks pop up would be nice.

regards,
Daan

On Thu, Mar 13, 2014 at 10:56 PM, Daan Hoogland  wrote:
> H,
>
> I concocted a git prepare-commit-msg hook.
>
> Please rant about my evening hobby after testing and reading
>
> 
> DB=`git status | grep -e "modified.*\.sql$" -e "new file.*\.sql$"`
> OLD_MSG=`cat $1`
> if [ -z "$DB" ]
> then
>   MSG="[DB-CHANGE] $OLD_MSG"
> else
>   MSG="$OLD_MSG"
> fi
> echo "$MSG" >$1
> 
>
> regards,
> --
> Daan



-- 
Daan

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 21:57, Edison Su wrote:
Add a fix: e5c391fcf3852e50ebd99d4a72fd51d1753b05eb on 4.3-forward 
branch.

I do see the rule coming on the kvm host:

-A FORWARD -o cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0
-A FORWARD -i cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0
-A FORWARD -o cloudbr0 -j DROP
-A FORWARD -i cloudbr0 -j DROP


Here are the promised logs, if still needed, I'll try your fix shortly.

http://paste.fedoraproject.org/85554/94835334/raw/

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Edison Su [mailto:edison...@citrix.com]
> Sent: Friday, March 14, 2014 2:57 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> Add a fix: e5c391fcf3852e50ebd99d4a72fd51d1753b05eb on 4.3-forward
> branch.
> I do see the rule coming on the kvm host:
> 
> -A FORWARD -o cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0 -A
> FORWARD -i cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0 -A
> FORWARD -o cloudbr0 -j DROP -A FORWARD -i cloudbr0 -j DROP
> 
> Animesh, could you cherry-pick it into 4.3?


[Animesh] Edison thanks for the fix. Can you also add tracking bug in JIRA for 
this issue. Nux do you mind pulling in Edison's commit and confirm the fix?


> > -Original Message-
> > From: Edison Su [mailto:edison...@citrix.com]
> > Sent: Friday, March 14, 2014 1:59 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >
> > The following change will the be root cause:
> >
> > -refs = execute("iptables -n -L " + brfw + " |grep " + brfw + " | 
> > cut -d \( -
> f2
> > | awk '{print $1}'").strip()
> > +refs = execute("""iptables -n -L " + brfw + " | awk
> > + '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % brfw).strip()
> >
> > In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
> >
> > The code should be
> > +refs = execute("""iptables -n -L " + %s + " | awk
> > + '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % (brfw,
> > + brfw)).strip()
> >
> > > -Original Message-
> > > From: Nux! [mailto:n...@li.nux.ro]
> > > Sent: Friday, March 14, 2014 1:13 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> > >
> > > On 14.03.2014 19:36, Edison Su wrote:
> > > >> -Original Message-
> > > >> From: Nux! [mailto:n...@li.nux.ro]
> > > >> Sent: Friday, March 14, 2014 12:19 PM
> > > >> To: dev@cloudstack.apache.org
> > > >> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> > > >>
> > > >> On 14.03.2014 19:14, Edison Su wrote:
> > > >>> Hi Nux,
> > > >>>Could you post security group log file on your 4.3 kvm host?
> > > >>> The file is @/var/log/cloudstack/agent/security_group.log
> > > >>
> > > >> Thanks Edison, but the problem went away once I replaced that
> > > >> python script with
> > > >> https://git-wip-
> > > >> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/v
> > > >> m/
> > > >> ne
> > > >> two
> > > >>
> > >
> >
> rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> > > >> 898a264a5463b85c4cab3033f9c3161c5ef83f8
> > > >
> > > > But the code is not for 4.3, right?
> > > > I want to figure out, why 4.3 security group is broken.
> > >
> > > I think this is the key difference:
> > >
> > > -A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
> > > BF-brbond0-540
> > > -A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
> > > BF-brbond0-540
> > > -A FORWARD -o brbond0-540 -j DROP
> > > -A FORWARD -i brbond0-540 -j DROP
> > >
> > > It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
> > > I'll try to rollback to old script and send you the logs.
> > >
> > > Lucian
> > >
> > > --
> > > Sent from the Delta quadrant using Borg technology!
> > >
> > > Nux!
> > > www.nux.ro

Re: [Merge] CloudStack IAM branch to master

[Kelven Yang]

Marcus,

I¹ve pushed the fix to master already. You probably need to sync your
local branch with master

Kelven

On 3/14/14, 11:08 AM, "Marcus"  wrote:

>It's in branch resize-root
>
>On Fri, Mar 14, 2014 at 10:47 AM, Min Chen  wrote:
>> Marcus,
>>
>> What is the latest commit you have picked up on your local
>>setup from
>> master? Our QA reports similar issues caused by recent VMSync bug fix,
>> just want to make sure that your local code has that fix.
>>
>> Thanks
>> -min
>>
>> On 3/14/14 9:37 AM, "Min Chen"  wrote:
>>
>>>Before merge, I did a sanity zone and VM deployment test, and worked
>>>fine
>>>on my setup after fixing the issues introduced by Antonio's commit. I
>>>can
>>>verify this again today. From the symptom, it seems not related to IAM
>>>change.
>>>
>>>Thanks
>>>-min
>>>
>>>
>>>
>>>On 3/14/14 1:07 AM, "Marcus"  wrote:
>>>
creating a new router does the same...

2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
instance VM[DomainRouter|r-5-VM]
com.cloud.exception.ConcurrentOperationException: Unable to transition
to a new state.
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineM
an
a
gerImpl.java:1029)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManag
er
I
mpl.java:775)

On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
> I have no idea if its related to this branch merge or not, but I'm
> unable to start the ssvm on master since I pulled about an hour ago.
>I
> can deploy a fresh zone, and the ssvm will actually start, but it
> can't transition state in the DB, so it kills the vm.
>
> 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
> VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
> updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
> State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014} Stale
> Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14 01:56:38
> MDT 2014}
> 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
> instance VM[SecondaryStorageVm|s-1-VM]
> com.cloud.exception.ConcurrentOperationException: Unable to
>transition
> to a new state.
> at
>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachine
>Ma
>n
>agerImpl.java:1029)
> at
>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachine
>Ma
>n
>agerImpl.java:5129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>av
>a
>:57)
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>or
>I
>mpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
>com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerPro
>xy
>.
>java:107)
> at
>com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineM
>an
>a
>gerImpl.java:5274)
> at
>com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInC
>on
>t
>ext(AsyncJobManagerImpl.java:491)
> at
>org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Man
>ag
>e
>dContextRunnable.java:49)
> at
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.cal
>l(
>D
>efaultManagedContext.java:56)
> at
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callW
>it
>h
>Context(DefaultManagedContext.java:103)
> at
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWi
>th
>C
>ontext(DefaultManagedContext.java:53)
> at
>org.apache.cloudstack.managed.context.ManagedContextRunnable.run(Manag
>ed
>C
>ontextRunnable.java:46)
> at
>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(As
>yn
>c
>JobManagerImpl.java:448)
> at
>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471
>)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
>java.util.concurrent.Th

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Edison Su]

Add a fix: e5c391fcf3852e50ebd99d4a72fd51d1753b05eb on 4.3-forward branch.
I do see the rule coming on the kvm host:

-A FORWARD -o cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0 
-A FORWARD -i cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0 
-A FORWARD -o cloudbr0 -j DROP 
-A FORWARD -i cloudbr0 -j DROP

Animesh, could you cherry-pick it into 4.3?
> -Original Message-
> From: Edison Su [mailto:edison...@citrix.com]
> Sent: Friday, March 14, 2014 1:59 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> The following change will the be root cause:
> 
> -refs = execute("iptables -n -L " + brfw + " |grep " + brfw + " | cut 
> -d \( -f2
> | awk '{print $1}'").strip()
> +refs = execute("""iptables -n -L " + brfw + " | awk
> + '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % brfw).strip()
> 
> In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
> 
> The code should be
> +refs = execute("""iptables -n -L " + %s + " | awk
> + '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % (brfw,
> + brfw)).strip()
> 
> > -Original Message-
> > From: Nux! [mailto:n...@li.nux.ro]
> > Sent: Friday, March 14, 2014 1:13 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >
> > On 14.03.2014 19:36, Edison Su wrote:
> > >> -Original Message-
> > >> From: Nux! [mailto:n...@li.nux.ro]
> > >> Sent: Friday, March 14, 2014 12:19 PM
> > >> To: dev@cloudstack.apache.org
> > >> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> > >>
> > >> On 14.03.2014 19:14, Edison Su wrote:
> > >>> Hi Nux,
> > >>>Could you post security group log file on your 4.3 kvm host?
> > >>> The file is @/var/log/cloudstack/agent/security_group.log
> > >>
> > >> Thanks Edison, but the problem went away once I replaced that
> > >> python script with
> > >> https://git-wip-
> > >> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/
> > >> ne
> > >> two
> > >>
> >
> rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> > >> 898a264a5463b85c4cab3033f9c3161c5ef83f8
> > >
> > > But the code is not for 4.3, right?
> > > I want to figure out, why 4.3 security group is broken.
> >
> > I think this is the key difference:
> >
> > -A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
> > BF-brbond0-540
> > -A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
> > BF-brbond0-540
> > -A FORWARD -o brbond0-540 -j DROP
> > -A FORWARD -i brbond0-540 -j DROP
> >
> > It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
> > I'll try to rollback to old script and send you the logs.
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Friday, March 14, 2014 2:28 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> 
> 
> > -Original Message-
> > From: Edison Su [mailto:edison...@citrix.com]
> > Sent: Friday, March 14, 2014 1:59 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >
> > The following change will the be root cause:
> >
> > -refs = execute("iptables -n -L " + brfw + " |grep " + brfw + " | 
> > cut -d \( -
> f2
> > | awk '{print $1}'").strip()
> > +refs = execute("""iptables -n -L " + brfw + " | awk
> > + '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % brfw).strip()
> >
> > In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
> >
> > The code should be
> > +refs = execute("""iptables -n -L " + %s + " | awk
> > + '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % (brfw,
> > + brfw)).strip()
> 
> [Animesh]  Edison thanks for finding the root cause. Looking at the commit
> https://git-wip-
> us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=052bff15c6603877e7a
> 0767993eb4675e9bd9ca8
> It has been broken since July last year and we did not run into it. Nux thanks
> for catching it. Commit message simply says "Replaced multiple
> grep/awk/head commands by one awk command" and the effects is pretty
> bad. There is no bug id associated with commit. Why did we have to change
> it?
> 
[Animesh] Can someone add a test case for this issue?
> 
> 
> 
> >
> > > -Original Message-
> > > From: Nux! [mailto:n...@li.nux.ro]
> > > Sent: Friday, March 14, 2014 1:13 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> > >
> > > On 14.03.2014 19:36, Edison Su wrote:
> > > >> -Original Message-
> > > >> From: Nux! [mailto:n...@li.nux.ro]
> > > >> Sent: Friday, March 14, 2014 12:19 PM
> > > >> To: dev@cloudstack.apache.org
> > > >> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> > > >>
> > > >> On 14.03.2014 19:14, Edison Su wrote:
> > > >>> Hi Nux,
> > > >>>Could you post security group log file on your 4.3 kvm host?
> > > >>> The file is @/var/log/cloudstack/agent/security_group.log
> > > >>
> > > >> Thanks Edison, but the problem went away once I replaced that
> > > >> python script with
> > > >> https://git-wip-
> > > >> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/v
> > > >> m/
> > > >> ne
> > > >> two
> > > >>
> > >
> >
> rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> > > >> 898a264a5463b85c4cab3033f9c3161c5ef83f8
> > > >
> > > > But the code is not for 4.3, right?
> > > > I want to figure out, why 4.3 security group is broken.
> > >
> > > I think this is the key difference:
> > >
> > > -A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
> > > BF-brbond0-540
> > > -A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
> > > BF-brbond0-540
> > > -A FORWARD -o brbond0-540 -j DROP
> > > -A FORWARD -i brbond0-540 -j DROP
> > >
> > > It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
> > > I'll try to rollback to old script and send you the logs.
> > >
> > > Lucian
> > >
> > > --
> > > Sent from the Delta quadrant using Borg technology!
> > >
> > > Nux!
> > > www.nux.ro

Re: [REVIEW] OpenStack Swift as Object Storage Service

[Will Stevens]

When I originally wrote this integration there was no way to solve the
Same-Origin issue.  I wrote this implementation 2 years ago and I just
ported it the the 4.4 code base recently to potentially make available to
the community.

Currently: If you want to have Swift available on its own host which is not
accessed through CloudStack, that is fine.  If you want to have it
available through the CloudStack UI as well, you would just have the load
balancer redirect to the Swift hostname rather than an IP.

It is looking like people want significant changes to this code before they
will be happy with it, so it may not be realistic for me to make it
available at this time.  I do not have significant development hours that I
can put towards rebuilding this entire integration, so this may have to get
tabled until I have free hours (unless someone wants to sponsor the
redevelopment).

ws


On Fri, Mar 14, 2014 at 3:39 PM, Edison Su  wrote:

>  What I am trying to say is the public domain name for CloudStack mgt
> server and cloud storage(either swift and S3) can be different. For
> example, the cloudstack mgt server can have a domain name, like
> your-company.com, which mapping to a pubic ip address @ 52.53.53.55,
> while cloud storage can have a domain name, like,
> cloud-storage.your-company.com, which mapping to public ip address @
> 52.53.53.54. With different domain for different service, each service
> can scale and control differently.
>
> The client(browser) can call different domains, as most modern browsers
> supporting Cross-origin resource sharing now.
>
> The workflow will like this:
>
> 1.   Swift javascript client calls cloudstack mgt server api(e.g.
> listswfitcmd) to get the public domain of swift service and also get auth
> info. In your particular case, both public domain of swift service and
> cloudstack mgt server are the same.
>
> 2.   Swift javascript client calls public domain of swift
> service(returned by above step 1) for all the swift related operations.
>
> If we support above procedure, then it should be easy to add the support
> for AWS S3, or any other public cloud storage.
>
>
>
>
>
> *From:* williamstev...@gmail.com [mailto:williamstev...@gmail.com] *On
> Behalf Of *Will Stevens
> *Sent:* Thursday, March 13, 2014 7:16 PM
>
> *To:* Edison Su
> *Cc:* dev@cloudstack.apache.org; David Nalley  (
> da...@gnsa.us)
> *Subject:* Re: [REVIEW] OpenStack Swift as Object Storage Service
>
>
>
> Lets say that we have the following setup to help clarify how this all
> works.
>
>
>
> CloudStack Management server is on: 10.10.10.2:8080
>
> Swift Proxy servers are on: 10.10.10.3:8080, 10.10.10.4:8080,
> 10.10.10.5:8080
>
> We have a load balancer setup on: 52.53.54.55:80
>
> The load balancer is networked to both the Swift cluster and CloudStack.
>
>
>
> When you want to connect to CloudStack, you connect to: 52.53.54.55:80
>
> You can basically think of that as your CloudStack IP since the load
> balancer passes all CloudStack traffic that hits 52.53.54.55:80 directly
> to CloudStack (10.10.10.2:8080).
>
>
>
> To everyone concerned, the IP 52.53.54.55:80 is the CS server because it
> behaves like it.
>
>
>
> The only URLs that do not go directly to the CloudStack box are URLs that
> start with 'v1.0' (swift auth urls) and 'v1' (all other swift calls).
>
>
>
> In this case we have 3 proxy servers on Swift, so the load balancer will
> load balance across the different Swift proxy servers when the URL starts
> with 'v1.0' or 'v1'.
>
>
>
> If we did not do it this way and we setup and endpoint for Swift in
> CloudStack, then we would bottleneck all of the traffic to Swift at the
> CloudStack management server.  The fact that we have 3 proxy servers would
> be made irrelevant because all the traffic would be going through the
> CloudStack management server first.  This would dramatically reduce the
> performance of Swift and would have a dramatic impact on the resources
> required by the CloudStack management server.
>
>
>
> By splitting the traffic before it gets to either of the services, we can
> increase the performance of both of them.
>
>
>
> Is that clearer?
>
>
>
> Will
>
>
>
> On Thu, Mar 13, 2014 at 9:06 PM, Edison Su  wrote:
>
> The way to talk to swift endpoint, by using haproxy to redirect url
> request contains "/v1.0" to swift endpoint, so it assumes, the endpoint of
> swift is the same as cloudstack mgt server. Correct me, if I am wrong, I
> just try to figure how it works.
>
> But what if the swift endpoint is different from CloudStack mgt server?
> Take Aws console as an example, the aws console is console.aws.amazon.com,
> but the S3 endpoint is s3-console-us-standard.console.aws.amazon.com.
>
>
>
> *From:* williamstev...@gmail.com [mailto:williamstev...@gmail.com] *On
> Behalf Of *Will Stevens
> *Sent:* Thursday, March 13, 2014 5:52 PM
> *To:* Edison Su
> *Cc:* dev@cloudstack.apache.org; David Nalley  (
> da...@gnsa.us)
> *Subject:* Re: [REVIEW] OpenStack Swift as Object Sto

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Edison Su [mailto:edison...@citrix.com]
> Sent: Friday, March 14, 2014 1:59 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> The following change will the be root cause:
> 
> -refs = execute("iptables -n -L " + brfw + " |grep " + brfw + " | cut 
> -d \( -f2
> | awk '{print $1}'").strip()
> +refs = execute("""iptables -n -L " + brfw + " | awk
> + '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % brfw).strip()
> 
> In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
> 
> The code should be
> +refs = execute("""iptables -n -L " + %s + " | awk
> + '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % (brfw,
> + brfw)).strip()

[Animesh]  Edison thanks for finding the root cause. Looking at the commit 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=052bff15c6603877e7a0767993eb4675e9bd9ca8
It has been broken since July last year and we did not run into it. Nux thanks 
for catching it. Commit message simply says "Replaced multiple grep/awk/head 
commands by one awk command" and the effects is pretty bad. There is no bug id 
associated with commit. Why did we have to change it?




> 
> > -Original Message-
> > From: Nux! [mailto:n...@li.nux.ro]
> > Sent: Friday, March 14, 2014 1:13 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >
> > On 14.03.2014 19:36, Edison Su wrote:
> > >> -Original Message-
> > >> From: Nux! [mailto:n...@li.nux.ro]
> > >> Sent: Friday, March 14, 2014 12:19 PM
> > >> To: dev@cloudstack.apache.org
> > >> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> > >>
> > >> On 14.03.2014 19:14, Edison Su wrote:
> > >>> Hi Nux,
> > >>>Could you post security group log file on your 4.3 kvm host?
> > >>> The file is @/var/log/cloudstack/agent/security_group.log
> > >>
> > >> Thanks Edison, but the problem went away once I replaced that
> > >> python script with
> > >> https://git-wip-
> > >> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/
> > >> ne
> > >> two
> > >>
> >
> rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> > >> 898a264a5463b85c4cab3033f9c3161c5ef83f8
> > >
> > > But the code is not for 4.3, right?
> > > I want to figure out, why 4.3 security group is broken.
> >
> > I think this is the key difference:
> >
> > -A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
> > BF-brbond0-540
> > -A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
> > BF-brbond0-540
> > -A FORWARD -o brbond0-540 -j DROP
> > -A FORWARD -i brbond0-540 -j DROP
> >
> > It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
> > I'll try to rollback to old script and send you the logs.
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Mike Tutkowski]

Nice job, Edison! :)


On Fri, Mar 14, 2014 at 2:58 PM, Edison Su  wrote:

> The following change will the be root cause:
>
> -refs = execute("iptables -n -L " + brfw + " |grep " + brfw + " |
> cut -d \( -f2 | awk '{print $1}'").strip()
> +refs = execute("""iptables -n -L " + brfw + " | awk
> '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % brfw).strip()
>
> In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
>
> The code should be
> +refs = execute("""iptables -n -L " + %s + " | awk
> '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % (brfw, brfw)).strip()
>
> > -Original Message-
> > From: Nux! [mailto:n...@li.nux.ro]
> > Sent: Friday, March 14, 2014 1:13 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >
> > On 14.03.2014 19:36, Edison Su wrote:
> > >> -Original Message-
> > >> From: Nux! [mailto:n...@li.nux.ro]
> > >> Sent: Friday, March 14, 2014 12:19 PM
> > >> To: dev@cloudstack.apache.org
> > >> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> > >>
> > >> On 14.03.2014 19:14, Edison Su wrote:
> > >>> Hi Nux,
> > >>>Could you post security group log file on your 4.3 kvm host? The
> > >>> file is @/var/log/cloudstack/agent/security_group.log
> > >>
> > >> Thanks Edison, but the problem went away once I replaced that python
> > >> script with
> > >> https://git-wip-
> > >> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/ne
> > >> two
> > >>
> > rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> > >> 898a264a5463b85c4cab3033f9c3161c5ef83f8
> > >
> > > But the code is not for 4.3, right?
> > > I want to figure out, why 4.3 security group is broken.
> >
> > I think this is the key difference:
> >
> > -A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
> > BF-brbond0-540
> > -A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
> > BF-brbond0-540
> > -A FORWARD -o brbond0-540 -j DROP
> > -A FORWARD -i brbond0-540 -j DROP
> >
> > It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
> > I'll try to rollback to old script and send you the logs.
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Edison Su]

The following change will the be root cause:

-refs = execute("iptables -n -L " + brfw + " |grep " + brfw + " | cut 
-d \( -f2 | awk '{print $1}'").strip()
+refs = execute("""iptables -n -L " + brfw + " | awk 
'/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % brfw).strip()

In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8

The code should be 
+refs = execute("""iptables -n -L " + %s + " | awk '/%s(.*)references/ 
{gsub(/\(/, "") ;print $3}'""" % (brfw, brfw)).strip()

> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: Friday, March 14, 2014 1:13 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> On 14.03.2014 19:36, Edison Su wrote:
> >> -Original Message-
> >> From: Nux! [mailto:n...@li.nux.ro]
> >> Sent: Friday, March 14, 2014 12:19 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >>
> >> On 14.03.2014 19:14, Edison Su wrote:
> >>> Hi Nux,
> >>>Could you post security group log file on your 4.3 kvm host? The
> >>> file is @/var/log/cloudstack/agent/security_group.log
> >>
> >> Thanks Edison, but the problem went away once I replaced that python
> >> script with
> >> https://git-wip-
> >> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/ne
> >> two
> >>
> rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> >> 898a264a5463b85c4cab3033f9c3161c5ef83f8
> >
> > But the code is not for 4.3, right?
> > I want to figure out, why 4.3 security group is broken.
> 
> I think this is the key difference:
> 
> -A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
> BF-brbond0-540
> -A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
> BF-brbond0-540
> -A FORWARD -o brbond0-540 -j DROP
> -A FORWARD -i brbond0-540 -j DROP
> 
> It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
> I'll try to rollback to old script and send you the logs.
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: [REVIEW] OpenStack Swift as Object Storage Service

[Marcus]

I agree. It's not immediately clear to me why there's a prerequisite
that the traffic for both mgmt servers and swift have to go to the
same IP. It also eliminates the use of v1.0 and v1 for other purposes,
as its very common for REST API routes to start with something like
that (say the CS mgmt server itself rolls a REST API one day).

On Fri, Mar 14, 2014 at 1:39 PM, Edison Su  wrote:
> What I am trying to say is the public domain name for CloudStack mgt server 
> and cloud storage(either swift and S3) can be different. For example, the 
> cloudstack mgt server can have a domain name, like your-company.com, which 
> mapping to a pubic ip address @ 52.53.53.55, while cloud storage can have a 
> domain name, like, cloud-storage.your-company.com, which mapping to public ip 
> address @52.53.53.54. With different domain for different service, each 
> service can scale and control differently.
> The client(browser) can call different domains, as most modern browsers 
> supporting Cross-origin resource sharing now.
> The workflow will like this:
>
> 1.   Swift javascript client calls cloudstack mgt server api(e.g. 
> listswfitcmd) to get the public domain of swift service and also get auth 
> info. In your particular case, both public domain of swift service and 
> cloudstack mgt server are the same.
>
> 2.   Swift javascript client calls public domain of swift 
> service(returned by above step 1) for all the swift related operations.
> If we support above procedure, then it should be easy to add the support for 
> AWS S3, or any other public cloud storage.
>
>
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
> Will Stevens
> Sent: Thursday, March 13, 2014 7:16 PM
> To: Edison Su
> Cc: dev@cloudstack.apache.org; David Nalley  (da...@gnsa.us)
> Subject: Re: [REVIEW] OpenStack Swift as Object Storage Service
>
> Lets say that we have the following setup to help clarify how this all works.
>
> CloudStack Management server is on: 10.10.10.2:8080
> Swift Proxy servers are on: 10.10.10.3:8080, 
> 10.10.10.4:8080, 
> 10.10.10.5:8080
> We have a load balancer setup on: 52.53.54.55:80
> The load balancer is networked to both the Swift cluster and CloudStack.
>
> When you want to connect to CloudStack, you connect to: 
> 52.53.54.55:80
> You can basically think of that as your CloudStack IP since the load balancer 
> passes all CloudStack traffic that hits 52.53.54.55:80 
> directly to CloudStack (10.10.10.2:8080).
>
> To everyone concerned, the IP 52.53.54.55:80 is the CS 
> server because it behaves like it.
>
> The only URLs that do not go directly to the CloudStack box are URLs that 
> start with 'v1.0' (swift auth urls) and 'v1' (all other swift calls).
>
> In this case we have 3 proxy servers on Swift, so the load balancer will load 
> balance across the different Swift proxy servers when the URL starts with 
> 'v1.0' or 'v1'.
>
> If we did not do it this way and we setup and endpoint for Swift in 
> CloudStack, then we would bottleneck all of the traffic to Swift at the 
> CloudStack management server.  The fact that we have 3 proxy servers would be 
> made irrelevant because all the traffic would be going through the CloudStack 
> management server first.  This would dramatically reduce the performance of 
> Swift and would have a dramatic impact on the resources required by the 
> CloudStack management server.
>
> By splitting the traffic before it gets to either of the services, we can 
> increase the performance of both of them.
>
> Is that clearer?
>
> Will
>
> On Thu, Mar 13, 2014 at 9:06 PM, Edison Su 
> mailto:edison...@citrix.com>> wrote:
> The way to talk to swift endpoint, by using haproxy to redirect url request 
> contains "/v1.0" to swift endpoint, so it assumes, the endpoint of swift is 
> the same as cloudstack mgt server. Correct me, if I am wrong, I just try to 
> figure how it works.
> But what if the swift endpoint is different from CloudStack mgt server? Take 
> Aws console as an example, the aws console is 
> console.aws.amazon.com, but the S3 endpoint is 
> s3-console-us-standard.console.aws.amazon.com.
>
> From: williamstev...@gmail.com 
> [mailto:williamstev...@gmail.com] On Behalf 
> Of Will Stevens
> Sent: Thursday, March 13, 2014 5:52 PM
> To: Edison Su
> Cc: dev@cloudstack.apache.org; David Nalley 
> mailto:da...@gnsa.us>> (da...@gnsa.us)
> Subject: Re: [REVIEW] OpenStack Swift as Object Storage Service
>
> What are you referring to as the 'v1.0 url hack'?  Bypassing the cloudstack 
> management server is an intentional design decisio

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 19:36, Edison Su wrote:

-Original Message-
From: Nux! [mailto:n...@li.nux.ro]
Sent: Friday, March 14, 2014 12:19 PM
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

On 14.03.2014 19:14, Edison Su wrote:

Hi Nux,
   Could you post security group log file on your 4.3 kvm host? The
file is @/var/log/cloudstack/agent/security_group.log


Thanks Edison, but the problem went away once I replaced that python 
script

with
https://git-wip-
us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/netwo
rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
898a264a5463b85c4cab3033f9c3161c5ef83f8


But the code is not for 4.3, right?
I want to figure out, why 4.3 security group is broken.


I think this is the key difference:

-A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j 
BF-brbond0-540
-A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j 
BF-brbond0-540

-A FORWARD -o brbond0-540 -j DROP
-A FORWARD -i brbond0-540 -j DROP

It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
I'll try to rollback to old script and send you the logs.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

RE: cherrypick to 4.3

[Animesh Chaturvedi]

If I build another RC I will pick it up

From: Alena Prokharchyk
Sent: Friday, March 14, 2014 12:43 PM
To: Animesh Chaturvedi
Cc: dev@cloudstack.apache.org
Subject: Re: cherrypick to 4.3

Animesh, one more commit for the same bug needs to be cherry-picked:

94817c1b4b89cfa69f2db50a7060dcb7d7c39dbb

-alena.

From: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Date: Wednesday, March 5, 2014 at 4:49 PM
To: Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: cherrypick to 4.3

Animesh, can you please cherry-pick one more commit from 4.3-forward to 4.3? 
Its a one liner change, yet it fixes Critical bug for VPC

d009c8c7b229a1bb02834f52d9cac17f46e33349
https://issues.apache.org/jira/browse/CLOUDSTACK-6205
"VPC: when network is created in Setup state (with vlan specified), it never 
gets plugged to the VPC VR after restart"

Thanks,
Alena.

Re: cherrypick to 4.3

[Alena Prokharchyk]

Animesh, one more commit for the same bug needs to be cherry-picked:

94817c1b4b89cfa69f2db50a7060dcb7d7c39dbb

-alena.

From: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Date: Wednesday, March 5, 2014 at 4:49 PM
To: Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: cherrypick to 4.3

Animesh, can you please cherry-pick one more commit from 4.3-forward to 4.3? 
Its a one liner change, yet it fixes Critical bug for VPC

d009c8c7b229a1bb02834f52d9cac17f46e33349
https://issues.apache.org/jira/browse/CLOUDSTACK-6205
"VPC: when network is created in Setup state (with vlan specified), it never 
gets plugged to the VPC VR after restart”

Thanks,
Alena.

RE: [REVIEW] OpenStack Swift as Object Storage Service

[Edison Su]

What I am trying to say is the public domain name for CloudStack mgt server and 
cloud storage(either swift and S3) can be different. For example, the 
cloudstack mgt server can have a domain name, like your-company.com, which 
mapping to a pubic ip address @ 52.53.53.55, while cloud storage can have a 
domain name, like, cloud-storage.your-company.com, which mapping to public ip 
address @52.53.53.54. With different domain for different service, each service 
can scale and control differently.
The client(browser) can call different domains, as most modern browsers 
supporting Cross-origin resource sharing now.
The workflow will like this:

1.   Swift javascript client calls cloudstack mgt server api(e.g. 
listswfitcmd) to get the public domain of swift service and also get auth info. 
In your particular case, both public domain of swift service and cloudstack mgt 
server are the same.

2.   Swift javascript client calls public domain of swift service(returned 
by above step 1) for all the swift related operations.
If we support above procedure, then it should be easy to add the support for 
AWS S3, or any other public cloud storage.


From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
Will Stevens
Sent: Thursday, March 13, 2014 7:16 PM
To: Edison Su
Cc: dev@cloudstack.apache.org; David Nalley  (da...@gnsa.us)
Subject: Re: [REVIEW] OpenStack Swift as Object Storage Service

Lets say that we have the following setup to help clarify how this all works.

CloudStack Management server is on: 10.10.10.2:8080
Swift Proxy servers are on: 10.10.10.3:8080, 
10.10.10.4:8080, 10.10.10.5:8080
We have a load balancer setup on: 52.53.54.55:80
The load balancer is networked to both the Swift cluster and CloudStack.

When you want to connect to CloudStack, you connect to: 
52.53.54.55:80
You can basically think of that as your CloudStack IP since the load balancer 
passes all CloudStack traffic that hits 52.53.54.55:80 
directly to CloudStack (10.10.10.2:8080).

To everyone concerned, the IP 52.53.54.55:80 is the CS 
server because it behaves like it.

The only URLs that do not go directly to the CloudStack box are URLs that start 
with 'v1.0' (swift auth urls) and 'v1' (all other swift calls).

In this case we have 3 proxy servers on Swift, so the load balancer will load 
balance across the different Swift proxy servers when the URL starts with 
'v1.0' or 'v1'.

If we did not do it this way and we setup and endpoint for Swift in CloudStack, 
then we would bottleneck all of the traffic to Swift at the CloudStack 
management server.  The fact that we have 3 proxy servers would be made 
irrelevant because all the traffic would be going through the CloudStack 
management server first.  This would dramatically reduce the performance of 
Swift and would have a dramatic impact on the resources required by the 
CloudStack management server.

By splitting the traffic before it gets to either of the services, we can 
increase the performance of both of them.

Is that clearer?

Will

On Thu, Mar 13, 2014 at 9:06 PM, Edison Su 
mailto:edison...@citrix.com>> wrote:
The way to talk to swift endpoint, by using haproxy to redirect url request 
contains "/v1.0" to swift endpoint, so it assumes, the endpoint of swift is the 
same as cloudstack mgt server. Correct me, if I am wrong, I just try to figure 
how it works.
But what if the swift endpoint is different from CloudStack mgt server? Take 
Aws console as an example, the aws console is 
console.aws.amazon.com, but the S3 endpoint is 
s3-console-us-standard.console.aws.amazon.com.

From: williamstev...@gmail.com 
[mailto:williamstev...@gmail.com] On Behalf Of 
Will Stevens
Sent: Thursday, March 13, 2014 5:52 PM
To: Edison Su
Cc: dev@cloudstack.apache.org; David Nalley 
mailto:da...@gnsa.us>> (da...@gnsa.us)
Subject: Re: [REVIEW] OpenStack Swift as Object Storage Service

What are you referring to as the 'v1.0 url hack'?  Bypassing the cloudstack 
management server is an intentional design decision to improve performance.  
The introduction of a load balancer in front of the two distinct services to 
maintain separation of their traffic is a good thing.

I will review the UI tutorial you sent...

I will check how much work it is to replace PLupload with the jQuery File 
Upload plugin.

Cheers,

Will

On Thu, Mar 13, 2014 at 8:24 PM, Edison Su 
mailto:edison...@citrix.com>> wrote:
One comment on the "/v1.0" url hack, seems changing mgt server is unavoidable, 
would it be easier to  add a new api in cloudstack, which can get the endpoint 
of sw

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Animesh Chaturvedi]

> -Original Message-
> From: Edison Su [mailto:edison...@citrix.com]
> Sent: Friday, March 14, 2014 12:37 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> 
> 
> > -Original Message-
> > From: Nux! [mailto:n...@li.nux.ro]
> > Sent: Friday, March 14, 2014 12:19 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >
> > On 14.03.2014 19:14, Edison Su wrote:
> > > Hi Nux,
> > >Could you post security group log file on your 4.3 kvm host? The
> > > file is @/var/log/cloudstack/agent/security_group.log
> >
> > Thanks Edison, but the problem went away once I replaced that python
> > script with
> > https://git-wip-
> > us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/net
> > wo
> >
> rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> > 898a264a5463b85c4cab3033f9c3161c5ef83f8
> 
> But the code is not for 4.3, right?
> I want to figure out, why 4.3 security group is broken.
> 
[Animesh] Yes I am curious too as there was no planned change for 4.3 and how 
it regressed?

> >
> > Do you still require the log file?
> 
> 
> Yes, it's better to find out why.
> 
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro

Re: Review Request 19034: Assigning LB rule to vm nic secondary ip

[Chiradeep Vittal]

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



api/src/com/cloud/network/lb/LoadBalancingRulesService.java


HoW ABOUT DESCRIBING THE ADDITIONAL PARAMETER IN THE COMMENTS



api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignToLoadBalancerRuleCmd.java


There is still an additional constraint though that either this or 
vmidipmap are required. Add comment



api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignToLoadBalancerRuleCmd.java


Prefer returning empty map instead of null



server/src/com/cloud/network/NetworkServiceImpl.java


Why not put this code in the LB manager. 



server/src/com/cloud/network/as/AutoScaleManagerImpl.java


prefer passing empty maps



server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java


You should have a test written for this condition



server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java


if you had passed in an EMPTY map from the API level you wouldn't have to 
check for nullness



server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java


where is the test for this?



server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java


where is the test for this?



server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java


test for this?



server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java


grammar in log!


- Chiradeep Vittal


On March 11, 2014, 12:04 p.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19034/
> ---
> 
> (Updated March 11, 2014, 12:04 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Chiradeep Vittal, Kishan 
> Kavala, and Murali Reddy.
> 
> 
> Bugs: CLOUDSTACK-2692
> https://issues.apache.org/jira/browse/CLOUDSTACK-2692
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> With this feature load balancing rules assigned/associated to any ip of the 
> vm nic. The vm nic ip can be primary ip or nic secondary ip.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/lb/LoadBalancingRulesService.java 4c87d34 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 0a3fafd 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignToLoadBalancerRuleCmd.java
>  6bd7537 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDao.java 79eaf8e 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDaoImpl.java 
> b0b14fc 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapVO.java 0a67106 
>   server/src/com/cloud/network/NetworkServiceImpl.java ebeb31a 
>   server/src/com/cloud/network/as/AutoScaleManagerImpl.java 2fa3821 
>   server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 6f0c1e9 
>   setup/db/db/schema-430to440.sql ee4cf21 
> 
> Diff: https://reviews.apache.org/r/19034/diff/
> 
> 
> Testing
> ---
> 
> Tested configuring the LB rules to vm primary ip and vm secondary ip.
> The haproxy config is created correctly for the selected ip.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Edison Su]

> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: Friday, March 14, 2014 12:19 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> On 14.03.2014 19:14, Edison Su wrote:
> > Hi Nux,
> >Could you post security group log file on your 4.3 kvm host? The
> > file is @/var/log/cloudstack/agent/security_group.log
> 
> Thanks Edison, but the problem went away once I replaced that python script
> with
> https://git-wip-
> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/netwo
> rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> 898a264a5463b85c4cab3033f9c3161c5ef83f8

But the code is not for 4.3, right?
I want to figure out, why 4.3 security group is broken.

> 
> Do you still require the log file?


Yes, it's better to find out why.

> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: [PROPOSAL] Bridge functionality

[Nate Gordon]

I would also like to chime in on this.  Our customers routinely make use of
bridging vlans out into dedicated infrastructure, and a way to automate
this with SDN deployments would be welcome.  I might even be able to get
some dev resources to assist with the development.

Thanks,

-Nate


On Thu, Mar 13, 2014 at 9:19 AM, Ian Rae  wrote:

> Hugo,
>
> This is a common request from our SP customers but most have balked at the
> cost of developing a custom solution. It is an important feature for hybrid
> architectures, let us know how we can help. Certainly we will give feedback
> on the functional spec.
>
> Ian
>
> Ian Rae
> CEO, CloudOps Inc.
> 514-944-4008
> @ianrae | www.linkedin.com/in/ianrae
> www.cloudops.com
>
>
> On Tue, Mar 11, 2014 at 10:12 AM, Hugo Trippaers 
> wrote:
>
> > Hey all,
> >
> > I've been working on adding Bridge support to CloudStack. The use case is
> > that with the introduction of SDN there is a need for us to link logical
> > networks to physical hosts or physical networks. A typical use case would
> > be to connect legacy infrastructure to cloud infrastructure, or to
> support
> > cloud bursting from an existing infrastructure to a network in the cloud.
> >
> > Routing can sometimes be used to accomplish the same effect (for example
> > the private gateway option in a VPC), but in some cases a L2 connection
> is
> > preferred.
> >
> > The functionality would a central bridge manager in CloudStack. The
> bridge
> > manager would have a number of admin only commands that link a number of
> > networks to a specified domain or account. The user commands would allow
> an
> > account to link a logical network to an external physical network. This
> > separation is done to ensure users are never able to configure a bridge
> to
> > a network they shouldn't have access to. Admins will have to make an
> > external network available as a bridge destination and a user can select
> it.
> >
> > The network implementation will consists of a BridgeProvider element
> > extension which elements can implement. It's up to the elements to
> > configure the particulars of their bridge implementation.
> >
> > Initial implementation will cover the admin commands, user commands and
> an
> > implementation in the VMware NSX  plugin. UI is out of scope for the
> first
> > implementation.
> >
> > Any feedback is welcome :D
> >
> > Cheers,
> >
> > Hugo
>



-- 


*Nate Gordon*Director of Technology | Appcore - the business of cloud
computing®

Office +1.800.735.7104  |  Direct +1.515.612.7787
nate.gor...@appcore.com  |  www.appcore.com

--

The information in this message is intended for the named recipients only.
It may contain information that is privileged, confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution, or the taking
of any action in reliance on the contents of this message is strictly
prohibited. If you have received this e-mail in error, do not print it or
disseminate it or its contents. In such event, please notify the sender by
return e-mail and delete the e-mail file immediately thereafter. Thank you.

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 19:14, Edison Su wrote:

Hi Nux,
   Could you post security group log file on your 4.3 kvm host? The
file is @/var/log/cloudstack/agent/security_group.log


Thanks Edison, but the problem went away once I replaced that python 
script with 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/network/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0898a264a5463b85c4cab3033f9c3161c5ef83f8


Do you still require the log file?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Edison Su]

Hi Nux,
   Could you post security group log file on your 4.3 kvm host? The file is 
@/var/log/cloudstack/agent/security_group.log 

> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: Friday, March 14, 2014 5:06 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> 
> On 13.03.2014 21:24, Animesh Chaturvedi wrote:
> >> [Animesh] Did you see this with prior RC too?
> > [Animesh] Nux, security group support for advanced zone is limited and
> > that too was developed in 4.2. I don’t think any changes have been
> > made to that support since then. Can you call out what specific issue
> > are you seeing? Most likely it is pre-existing issue or not supported.
> >
> >
> > The functional spec from 4.2 is at [1] and I don’t know if all that is
> > called out is implemented or not, adding Anthony and Chiradeep to the
> > thread for further comments
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+based
> > +on+Security+Groups+in+Advance+zone
> 
> I could replicate this problem on a clean hypervisor. The security groups
> seem broken on KVM/CentOS.
> 
> It looks like the traffic doesn't go in the right chains, all traffic is 
> accepted as
> FORWARD is set to ACCEPT.
> There are zero packets going through BF-breth0-109.
> 
> Here's outputs from:
> iptables-save: http://paste.fedoraproject.org/85337/47982321/raw/
> ebatables-save: http://paste.fedoraproject.org/85338/79831713/raw/
> ipset -L: http://paste.fedoraproject.org/85339/79832613/raw/
> 
> I will install 4.2.1 as that one was working and try to compare the outputs.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

RE: Anybody saw this error on master?

[Konstantina Chremmou]

GPUGroup.getEnabledVGPUTypes was added in XenServer 6.2 SP1, it doesn't exist 
in 6.2.

Tina

> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: 14 March 2014 5:02 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Anybody saw this error on master?
> 
> I am using XenServer 6.2
> 
> Thanks
> -min
> 
> On 3/14/14 12:45 AM, "Sanjay Tripathi"  wrote:
> 
> >Hi Min,
> >
> >Which version of XS you are working on?
> >
> >--Sanjay
> >
> >-Original Message-
> >From: Min Chen [mailto:min.c...@citrix.com]
> >Sent: Friday, March 14, 2014 6:18 AM
> >To: dev@cloudstack.apache.org
> >Subject: Anybody saw this error on master?
> >
> >Hi there,
> >
> >Anybody has seen this error on master? It is not blocking, but still an
> >eyesore to see it in the log.
> >
> >2014-03-13 16:31:54,357 DEBUG [c.c.h.x.r.CitrixResourceBase]
> >(DirectAgent-8:ctx-87d8612e) Vm cpu utilization 0.08
> >2014-03-13 16:31:54,357 DEBUG [c.c.h.x.r.CitrixResourceBase]
> >(DirectAgent-8:ctx-87d8612e) Vm cpu utilization 0.06
> >2014-03-13 16:31:54,364 WARN  [c.c.h.x.r.CitrixResourceBase]
> >(DirectAgent-6:ctx-6c5e0497) Unable to get GPU statsYou tried to call a
> >method that does not exist.  The method name that you used is echoed.
> >You tried to call a method that does not exist.  The method name that
> >you used is echoed.
> >at com.xensource.xenapi.Types.checkResponse(Types.java:1254)
> >at com.xensource.xenapi.Connection.dispatch(Connection.java:350)
> >at
> >com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerC
> onn
> >ect
> >ion.dispatch(XenServerConnectionPool.java:499)
> >at
> >com.xensource.xenapi.GPUGroup.getEnabledVGPUTypes(GPUGroup.java:
> 394)
> >at
> >com.cloud.hypervisor.xen.resource.CitrixResourceBase.getGPUGroupDetai
> ls
> >(Ci
> >trixResourceBase.java:1308)
> >at
> >com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixReso
> >urc
> >eBase.java:2327)
> >at
> >com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Ci
> t
> >rix
> >ResourceBase.java:444)
> >at
> >com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest
> (Xe
> >nSe
> >rver56Resource.java:59)
> >at
> >com.cloud.hypervisor.xen.resource.XenServer610Resource.executeReque
> st(X
> >enS
> >erver610Resource.java:107)
> >at
> >com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAg
> en
> >tAt
> >tache.java:216)
> >at
> >org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(
> Mana
> >ged
> >ContextRunnable.java:49)
> >at
> >org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.c
> all
> >(De
> >faultManagedContext.java:56)
> >at
> >org.apache.cloudstack.managed.context.impl.DefaultManagedContext.call
> Wi
> >thC
> >ontext(DefaultManagedContext.java:103)
> >at
> >org.apache.cloudstack.managed.context.impl.DefaultManagedContext.run
> Wit
> >hCo
> >ntext(DefaultManagedContext.java:53)
> >at
> >org.apache.cloudstack.managed.context.ManagedContextRunnable.run(M
> anage
> >dCo
> >ntextRunnable.java:46)
> >at
> >java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> >at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> >at
> >java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.a
> c
> >ces
> >s$201(ScheduledThreadPoolExecutor.java:178)
> >at
> >java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.r
> u
> >n(S
> >cheduledThreadPoolExecutor.java:292)
> >at
> >java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja
> va:
> >1145)
> >at
> >java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
> >ava
> >:615)
> >at java.lang.Thread.run(Thread.java:724)
> >
> >
> >Thanks
> >-min

Re: Assigning a JIRA ticket to someone

[Mike Tutkowski]

Thanks, Daan!


On Fri, Mar 14, 2014 at 11:13 AM, Daan Hoogland wrote:

> On Fri, Mar 14, 2014 at 5:55 PM, Mike Tutkowski
>  wrote:
> > Seif Eddine Jemli
>
>
> added
>
> And I added you to administrators for the project, Mike
>
> --
> Daan
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: [Merge] CloudStack IAM branch to master

[Chiradeep Vittal]

For a new feature, I’d agree that squashed-merge is better.

From: Marcus mailto:shadow...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Friday, March 14, 2014 at 10:05 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: [Merge] CloudStack IAM branch to master

Maybe, although to some extent the action of merging I think should be
seen as saying "this is complete". If the history is important, it
could perhaps be kept around in the feature branch until it becomes
irrelevant. Of course it may have minor issues that aren't known, but
I think the ability to preserve master and easily be able to roll back
an entire feature is attractive.

On Fri, Mar 14, 2014 at 12:01 PM, Prachi Damle 
mailto:prachi.da...@citrix.com>> wrote:
Just a thought about the squashed merge, if there are multiple developers 
working on a feature branch as in this case, won't it be better to preserve the 
change history?

-Original Message-
From: Min Chen [mailto:min.c...@citrix.com]
Sent: Friday, March 14, 2014 9:35 AM
To: dev@cloudstack.apache.org
Subject: Re: [Merge] CloudStack IAM branch to master

Thanks Marcus. I am not aware of this convention, will remember that next time 
when I do the merge.

-min

On 3/13/14 10:30 PM, "Marcus" mailto:shadow...@gmail.com>> 
wrote:

Min, in looking at this branch merge, I need to be reminded whether we
are supposed to squash feature branches when they come in, or preserve
history. It's nice to preserve history, but it's a lot easier to undo a
squashed merge.

On Thu, Mar 13, 2014 at 5:56 PM, Min Chen 
mailto:min.c...@citrix.com>> wrote:
IAM branch is now merged to master.

Thanks
-min

On 3/13/14 10:13 AM, "Min Chen" 
mailto:min.c...@citrix.com>> wrote:

Since we haven't heard of any objections to this merge for 3 days, I
am going to merge it to master today.

Thanks
-min

On 3/11/14 12:23 PM, "Hugo Trippaers" 
mailto:h...@trippaers.nl>> wrote:


On 11 mrt. 2014, at 19:52, Min Chen 
mailto:min.c...@citrix.com>> wrote:

Also, have already run FingBugs on our branch and addressed all
new findings introduced by our branch.

Awesome! :-)


Thanks.
-min

On 3/10/14 7:33 PM, "Min Chen" 
mailto:min.c...@citrix.com>> wrote:

No new jar dependencies.

-min

Sent from my iPhone

On Mar 10, 2014, at 7:22 PM, "Chiradeep Vittal"
mailto:chiradeep.vit...@citrix.com>> wrote:

Any new jar dependencies?

On 3/10/14, 11:34 AM, "Min Chen" 
mailto:min.c...@citrix.com>> wrote:

Hi,

Prachi and I would like to merge CloudStack Identity and Access
Management(IAM) plugin services to the master branch.
Development for  this effort has been done by Prachi and me on
ACS rbac branch


(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shor
tlo
g;
h
=r
ef
s/heads/rbac).
Checklists for the merge:
1. JIRA ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-5920.
2. Functional Specs:


https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStac
k+I
de
n
ti
ty
+and+Access+Management+%28IAM%29+Plugin. We have proposed this
feature
back in Jan, and accommodated all the feedbacks in our
implementation.
3. Unit tests for the feature are available at:
services/iam/server/test
(for iam server) and services/iam/plugin/test (for iam plugin).
4. Marvin integration tests for the feature are available at:
test/integration/smoke/test_vm_iam.py.
5. Branch has been rebased with master branch up to commit
63e3eea7905e22cab9466b28a2ab2a80b586aeed.
6. RAT test has been passed.

Thanks.
-min

Re: [Merge] CloudStack IAM branch to master

[Marcus]

It's in branch resize-root

On Fri, Mar 14, 2014 at 10:47 AM, Min Chen  wrote:
> Marcus,
>
> What is the latest commit you have picked up on your local setup from
> master? Our QA reports similar issues caused by recent VMSync bug fix,
> just want to make sure that your local code has that fix.
>
> Thanks
> -min
>
> On 3/14/14 9:37 AM, "Min Chen"  wrote:
>
>>Before merge, I did a sanity zone and VM deployment test, and worked fine
>>on my setup after fixing the issues introduced by Antonio's commit. I can
>>verify this again today. From the symptom, it seems not related to IAM
>>change.
>>
>>Thanks
>>-min
>>
>>
>>
>>On 3/14/14 1:07 AM, "Marcus"  wrote:
>>
>>>creating a new router does the same...
>>>
>>>2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
>>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
>>>VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
>>>time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
>>>updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
>>>State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
>>>2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
>>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
>>>instance VM[DomainRouter|r-5-VM]
>>>com.cloud.exception.ConcurrentOperationException: Unable to transition
>>>to a new state.
>>>at
>>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMan
>>>a
>>>gerImpl.java:1029)
>>>at
>>>com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManager
>>>I
>>>mpl.java:775)
>>>
>>>On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
 I have no idea if its related to this branch merge or not, but I'm
 unable to start the ssvm on master since I pulled about an hour ago. I
 can deploy a fresh zone, and the ssvm will actually start, but it
 can't transition state in the DB, so it kills the vm.

 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
 (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
 VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
 updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
 State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014} Stale
 Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14 01:56:38
 MDT 2014}
 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
 (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
 instance VM[SecondaryStorageVm|s-1-VM]
 com.cloud.exception.ConcurrentOperationException: Unable to transition
 to a new state.
 at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMa
n
agerImpl.java:1029)
 at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMa
n
agerImpl.java:5129)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a
:57)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
I
mpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy
.
java:107)
 at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineMan
a
gerImpl.java:5274)
 at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInCon
t
ext(AsyncJobManagerImpl.java:491)
 at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Manag
e
dContextRunnable.java:49)
 at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(
D
efaultManagedContext.java:56)
 at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWit
h
Context(DefaultManagedContext.java:103)
 at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWith
C
ontext(DefaultManagedContext.java:53)
 at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(Managed
C
ontextRunnable.java:46)
 at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(Asyn
c
JobManagerImpl.java:448)
 at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
a
:1145)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
v
a:615)
 at java.lang.Thread.run(Thread.java:744)

 On Thu, Mar 13, 2014 at 11:30 PM, Marcus  wrote:
> Min, in looking at this branch merge, I need to be reminded whether we
> are supposed to squash feature bran

Re: [Merge] CloudStack IAM branch to master

[Marcus]

Ok, thanks.

On Fri, Mar 14, 2014 at 10:56 AM, Kelven Yang  wrote:
> That¹s my bad. I cherry-picked a fix after IAM¹s merge and this has broken
> it. The problem didn¹t show up in my local run.
>
> I¹m working on a fix of it.
>
> Kelven
>
> On 3/14/14, 9:47 AM, "Min Chen"  wrote:
>
>>Marcus,
>>
>>   What is the latest commit you have picked up on your local setup from
>>master? Our QA reports similar issues caused by recent VMSync bug fix,
>>just want to make sure that your local code has that fix.
>>
>>   Thanks
>>   -min
>>
>>On 3/14/14 9:37 AM, "Min Chen"  wrote:
>>
>>>Before merge, I did a sanity zone and VM deployment test, and worked fine
>>>on my setup after fixing the issues introduced by Antonio's commit. I can
>>>verify this again today. From the symptom, it seems not related to IAM
>>>change.
>>>
>>>Thanks
>>>-min
>>>
>>>
>>>
>>>On 3/14/14 1:07 AM, "Marcus"  wrote:
>>>
creating a new router does the same...

2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
instance VM[DomainRouter|r-5-VM]
com.cloud.exception.ConcurrentOperationException: Unable to transition
to a new state.
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMa
n
a
gerImpl.java:1029)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManage
r
I
mpl.java:775)

On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
> I have no idea if its related to this branch merge or not, but I'm
> unable to start the ssvm on master since I pulled about an hour ago. I
> can deploy a fresh zone, and the ssvm will actually start, but it
> can't transition state in the DB, so it kills the vm.
>
> 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
> VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
> updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
> State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014} Stale
> Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14 01:56:38
> MDT 2014}
> 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
> instance VM[SecondaryStorageVm|s-1-VM]
> com.cloud.exception.ConcurrentOperationException: Unable to transition
> to a new state.
> at
>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineM
>a
>n
>agerImpl.java:1029)
> at
>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineM
>a
>n
>agerImpl.java:5129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
>v
>a
>:57)
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
>r
>I
>mpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
>com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProx
>y
>.
>java:107)
> at
>com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineMa
>n
>a
>gerImpl.java:5274)
> at
>com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInCo
>n
>t
>ext(AsyncJobManagerImpl.java:491)
> at
>org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Mana
>g
>e
>dContextRunnable.java:49)
> at
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call
>(
>D
>efaultManagedContext.java:56)
> at
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWi
>t
>h
>Context(DefaultManagedContext.java:103)
> at
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWit
>h
>C
>ontext(DefaultManagedContext.java:53)
> at
>org.apache.cloudstack.managed.context.ManagedContextRunnable.run(Manage
>d
>C
>ontextRunnable.java:46)
> at
>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(Asy
>n
>c
>JobManagerImpl.java:448)
> at
>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
>java.util

Re: [Merge] CloudStack IAM branch to master

[Marcus]

Maybe, although to some extent the action of merging I think should be
seen as saying "this is complete". If the history is important, it
could perhaps be kept around in the feature branch until it becomes
irrelevant. Of course it may have minor issues that aren't known, but
I think the ability to preserve master and easily be able to roll back
an entire feature is attractive.

On Fri, Mar 14, 2014 at 12:01 PM, Prachi Damle  wrote:
> Just a thought about the squashed merge, if there are multiple developers 
> working on a feature branch as in this case, won't it be better to preserve 
> the change history?
>
> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: Friday, March 14, 2014 9:35 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [Merge] CloudStack IAM branch to master
>
> Thanks Marcus. I am not aware of this convention, will remember that next 
> time when I do the merge.
>
> -min
>
> On 3/13/14 10:30 PM, "Marcus"  wrote:
>
>>Min, in looking at this branch merge, I need to be reminded whether we
>>are supposed to squash feature branches when they come in, or preserve
>>history. It's nice to preserve history, but it's a lot easier to undo a
>>squashed merge.
>>
>>On Thu, Mar 13, 2014 at 5:56 PM, Min Chen  wrote:
>>> IAM branch is now merged to master.
>>>
>>> Thanks
>>> -min
>>>
>>> On 3/13/14 10:13 AM, "Min Chen"  wrote:
>>>
Since we haven't heard of any objections to this merge for 3 days, I
am going to merge it to master today.

Thanks
-min

On 3/11/14 12:23 PM, "Hugo Trippaers"  wrote:

>
>On 11 mrt. 2014, at 19:52, Min Chen  wrote:
>
>> Also, have already run FingBugs on our branch and addressed all
>> new findings introduced by our branch.
>
>Awesome! :-)
>
>>
>> Thanks.
>> -min
>>
>> On 3/10/14 7:33 PM, "Min Chen"  wrote:
>>
>>> No new jar dependencies.
>>>
>>> -min
>>>
>>> Sent from my iPhone
>>>
 On Mar 10, 2014, at 7:22 PM, "Chiradeep Vittal"
  wrote:

 Any new jar dependencies?

> On 3/10/14, 11:34 AM, "Min Chen"  wrote:
>
> Hi,
>
> Prachi and I would like to merge CloudStack Identity and Access
> Management(IAM) plugin services to the master branch.
>Development for  this effort has been done by Prachi and me on
>ACS rbac branch
>
>
>(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shor
>tlo
>g;
>h
>=r
> ef
> s/heads/rbac).
> Checklists for the merge:
> 1. JIRA ticket:
>https://issues.apache.org/jira/browse/CLOUDSTACK-5920.
> 2. Functional Specs:
>
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStac
>k+I
>de
>n
>ti
> ty
> +and+Access+Management+%28IAM%29+Plugin. We have proposed this
>feature
> back in Jan, and accommodated all the feedbacks in our
>implementation.
> 3. Unit tests for the feature are available at:
> services/iam/server/test
> (for iam server) and services/iam/plugin/test (for iam plugin).
> 4. Marvin integration tests for the feature are available at:
> test/integration/smoke/test_vm_iam.py.
> 5. Branch has been rebased with master branch up to commit
>63e3eea7905e22cab9466b28a2ab2a80b586aeed.
> 6. RAT test has been passed.
>
> Thanks.
> -min

>>
>

>>>
>

Re: database version changed to 4.5 on master and it breaks the build

[Hugo Trippaers]

You shouldn't have to. I've got an automated test run that does the same and 
that succeeded before I committed the db change.

I do a clean before jetty:run but that shouldn't matter.

Hugo

Sent from my iPhone

> On 14 mrt. 2014, at 18:25, Alena Prokharchyk  
> wrote:
> 
> My master version is 384eeaf79261c3f744daa138369a424d3ef37295, so all the
> fixes from remote are in my local repo. I observe the error after
> executing the regular sequence of:
> 
> mvn clean install -P developer,systemvm
> mvn -P developer -pl developer -Ddeploydb
> mvn -pl :cloud-client-ui jetty:run
> 
> 
> Hugo, do I need to clean anything manually?
> 
> Thanks,
> Alena.
> 
> 
>> On 3/14/14, 10:20 AM, "Nux!"  wrote:
>> 
>>> On 14.03.2014 17:15, Alena Prokharchyk wrote:
>>> Observing following error on master after re-deploying the DB and
>>> running clean maven build:
>>> 
>>> [ERROR] Nested in
>>> org.springframework.context.ApplicationContextException: Failed to
>>> start bean 'cloudStackLifeCycle'; nested exception is
>>> com.cloud.utils.exception.CloudRuntimeException: Database version
>>> 4.5.0 is higher than management software version 4.4.0-SNAPSHOT:
>>> com.cloud.utils.exception.CloudRuntimeException: Database version
>>> 4.5.0 is higher than management software version 4.4.0-SNAPSHOT
>>> 
>>> 
>>> Whoever increased the DB version to 4.5, could you please fix it?
>>> 
>>> Thanks,
>>> Alena.
>> 
>> Hasn't "master" just become 4.5 after Hugo's cut earlier today?
>> 
>> Lucian
>> 
>> -- 
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
> 

RE: [Merge] CloudStack IAM branch to master

[Prachi Damle]

Just a thought about the squashed merge, if there are multiple developers 
working on a feature branch as in this case, won't it be better to preserve the 
change history?

-Original Message-
From: Min Chen [mailto:min.c...@citrix.com] 
Sent: Friday, March 14, 2014 9:35 AM
To: dev@cloudstack.apache.org
Subject: Re: [Merge] CloudStack IAM branch to master

Thanks Marcus. I am not aware of this convention, will remember that next time 
when I do the merge.

-min

On 3/13/14 10:30 PM, "Marcus"  wrote:

>Min, in looking at this branch merge, I need to be reminded whether we 
>are supposed to squash feature branches when they come in, or preserve 
>history. It's nice to preserve history, but it's a lot easier to undo a 
>squashed merge.
>
>On Thu, Mar 13, 2014 at 5:56 PM, Min Chen  wrote:
>> IAM branch is now merged to master.
>>
>> Thanks
>> -min
>>
>> On 3/13/14 10:13 AM, "Min Chen"  wrote:
>>
>>>Since we haven't heard of any objections to this merge for 3 days, I 
>>>am going to merge it to master today.
>>>
>>>Thanks
>>>-min
>>>
>>>On 3/11/14 12:23 PM, "Hugo Trippaers"  wrote:
>>>

On 11 mrt. 2014, at 19:52, Min Chen  wrote:

> Also, have already run FingBugs on our branch and addressed all 
> new findings introduced by our branch.

Awesome! :-)

>
> Thanks.
> -min
>
> On 3/10/14 7:33 PM, "Min Chen"  wrote:
>
>> No new jar dependencies.
>>
>> -min
>>
>> Sent from my iPhone
>>
>>> On Mar 10, 2014, at 7:22 PM, "Chiradeep Vittal"
>>>  wrote:
>>>
>>> Any new jar dependencies?
>>>
 On 3/10/14, 11:34 AM, "Min Chen"  wrote:

 Hi,

 Prachi and I would like to merge CloudStack Identity and Access
 Management(IAM) plugin services to the master branch. 
Development for  this effort has been done by Prachi and me on 
ACS rbac branch


(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shor
tlo
g;
h
=r
 ef
 s/heads/rbac).
 Checklists for the merge:
 1. JIRA ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-5920.
 2. Functional Specs:


https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStac
k+I
de
n
ti
 ty
 +and+Access+Management+%28IAM%29+Plugin. We have proposed this
feature
 back in Jan, and accommodated all the feedbacks in our 
implementation.
 3. Unit tests for the feature are available at:
 services/iam/server/test
 (for iam server) and services/iam/plugin/test (for iam plugin).
 4. Marvin integration tests for the feature are available at:
 test/integration/smoke/test_vm_iam.py.
 5. Branch has been rebased with master branch up to commit  
63e3eea7905e22cab9466b28a2ab2a80b586aeed.
 6. RAT test has been passed.

 Thanks.
 -min
>>>
>

>>>
>>

Re: database version changed to 4.5 on master and it breaks the build

[Alena Prokharchyk]

My master version is 384eeaf79261c3f744daa138369a424d3ef37295, so all the
fixes from remote are in my local repo. I observe the error after
executing the regular sequence of:

mvn clean install -P developer,systemvm
mvn -P developer -pl developer -Ddeploydb
mvn -pl :cloud-client-ui jetty:run


Hugo, do I need to clean anything manually?

Thanks,
Alena.


On 3/14/14, 10:20 AM, "Nux!"  wrote:

>On 14.03.2014 17:15, Alena Prokharchyk wrote:
>> Observing following error on master after re-deploying the DB and
>> running clean maven build:
>> 
>> [ERROR] Nested in
>> org.springframework.context.ApplicationContextException: Failed to
>> start bean 'cloudStackLifeCycle'; nested exception is
>> com.cloud.utils.exception.CloudRuntimeException: Database version
>> 4.5.0 is higher than management software version 4.4.0-SNAPSHOT:
>> com.cloud.utils.exception.CloudRuntimeException: Database version
>> 4.5.0 is higher than management software version 4.4.0-SNAPSHOT
>> 
>> 
>> Whoever increased the DB version to 4.5, could you please fix it?
>> 
>> Thanks,
>> Alena.
>
>Hasn't "master" just become 4.5 after Hugo's cut earlier today?
>
>Lucian
>
>-- 
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro

Re: database version changed to 4.5 on master and it breaks the build

[Nux!]

On 14.03.2014 17:15, Alena Prokharchyk wrote:

Observing following error on master after re-deploying the DB and
running clean maven build:

[ERROR] Nested in
org.springframework.context.ApplicationContextException: Failed to
start bean 'cloudStackLifeCycle'; nested exception is
com.cloud.utils.exception.CloudRuntimeException: Database version
4.5.0 is higher than management software version 4.4.0-SNAPSHOT:
com.cloud.utils.exception.CloudRuntimeException: Database version
4.5.0 is higher than management software version 4.4.0-SNAPSHOT


Whoever increased the DB version to 4.5, could you please fix it?

Thanks,
Alena.


Hasn't "master" just become 4.5 after Hugo's cut earlier today?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

database version changed to 4.5 on master and it breaks the build

[Alena Prokharchyk]

Observing following error on master after re-deploying the DB and running clean 
maven build:

[ERROR] Nested in org.springframework.context.ApplicationContextException: 
Failed to start bean 'cloudStackLifeCycle'; nested exception is 
com.cloud.utils.exception.CloudRuntimeException: Database version 4.5.0 is 
higher than management software version 4.4.0-SNAPSHOT:
com.cloud.utils.exception.CloudRuntimeException: Database version 4.5.0 is 
higher than management software version 4.4.0-SNAPSHOT


Whoever increased the DB version to 4.5, could you please fix it?

Thanks,
Alena.

Re: Assigning a JIRA ticket to someone

[Daan Hoogland]

On Fri, Mar 14, 2014 at 5:55 PM, Mike Tutkowski
 wrote:
> Seif Eddine Jemli


added

And I added you to administrators for the project, Mike

-- 
Daan

Re: Anybody saw this error on master?

[Min Chen]

I am using XenServer 6.2

Thanks
-min

On 3/14/14 12:45 AM, "Sanjay Tripathi"  wrote:

>Hi Min,
>
>Which version of XS you are working on?
>
>--Sanjay
>
>-Original Message-
>From: Min Chen [mailto:min.c...@citrix.com]
>Sent: Friday, March 14, 2014 6:18 AM
>To: dev@cloudstack.apache.org
>Subject: Anybody saw this error on master?
>
>Hi there,
>
>Anybody has seen this error on master? It is not blocking, but still an
>eyesore to see it in the log.
>
>2014-03-13 16:31:54,357 DEBUG [c.c.h.x.r.CitrixResourceBase]
>(DirectAgent-8:ctx-87d8612e) Vm cpu utilization 0.08
>2014-03-13 16:31:54,357 DEBUG [c.c.h.x.r.CitrixResourceBase]
>(DirectAgent-8:ctx-87d8612e) Vm cpu utilization 0.06
>2014-03-13 16:31:54,364 WARN  [c.c.h.x.r.CitrixResourceBase]
>(DirectAgent-6:ctx-6c5e0497) Unable to get GPU statsYou tried to call a
>method that does not exist.  The method name that you used is echoed.
>You tried to call a method that does not exist.  The method name that you
>used is echoed.
>at com.xensource.xenapi.Types.checkResponse(Types.java:1254)
>at com.xensource.xenapi.Connection.dispatch(Connection.java:350)
>at 
>com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnect
>ion.dispatch(XenServerConnectionPool.java:499)
>at 
>com.xensource.xenapi.GPUGroup.getEnabledVGPUTypes(GPUGroup.java:394)
>at 
>com.cloud.hypervisor.xen.resource.CitrixResourceBase.getGPUGroupDetails(Ci
>trixResourceBase.java:1308)
>at 
>com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourc
>eBase.java:2327)
>at 
>com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Citrix
>ResourceBase.java:444)
>at 
>com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenSe
>rver56Resource.java:59)
>at 
>com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenS
>erver610Resource.java:107)
>at 
>com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAt
>tache.java:216)
>at 
>org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Managed
>ContextRunnable.java:49)
>at 
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(De
>faultManagedContext.java:56)
>at 
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithC
>ontext(DefaultManagedContext.java:103)
>at 
>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithCo
>ntext(DefaultManagedContext.java:53)
>at 
>org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedCo
>ntextRunnable.java:46)
>at 
>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>at 
>java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.acces
>s$201(ScheduledThreadPoolExecutor.java:178)
>at 
>java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(S
>cheduledThreadPoolExecutor.java:292)
>at 
>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
>1145)
>at 
>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
>:615)
>at java.lang.Thread.run(Thread.java:724)
>
>
>Thanks
>-min

Re: [Merge] CloudStack IAM branch to master

[Kelven Yang]

That¹s my bad. I cherry-picked a fix after IAM¹s merge and this has broken
it. The problem didn¹t show up in my local run.

I¹m working on a fix of it.

Kelven

On 3/14/14, 9:47 AM, "Min Chen"  wrote:

>Marcus,
>
>   What is the latest commit you have picked up on your local setup from
>master? Our QA reports similar issues caused by recent VMSync bug fix,
>just want to make sure that your local code has that fix.
>
>   Thanks
>   -min
>
>On 3/14/14 9:37 AM, "Min Chen"  wrote:
>
>>Before merge, I did a sanity zone and VM deployment test, and worked fine
>>on my setup after fixing the issues introduced by Antonio's commit. I can
>>verify this again today. From the symptom, it seems not related to IAM
>>change.
>>
>>Thanks
>>-min
>>
>>
>>
>>On 3/14/14 1:07 AM, "Marcus"  wrote:
>>
>>>creating a new router does the same...
>>>
>>>2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
>>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
>>>VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
>>>time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
>>>updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
>>>State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
>>>2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
>>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
>>>instance VM[DomainRouter|r-5-VM]
>>>com.cloud.exception.ConcurrentOperationException: Unable to transition
>>>to a new state.
>>>at 
>>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMa
>>>n
>>>a
>>>gerImpl.java:1029)
>>>at 
>>>com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManage
>>>r
>>>I
>>>mpl.java:775)
>>>
>>>On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
 I have no idea if its related to this branch merge or not, but I'm
 unable to start the ssvm on master since I pulled about an hour ago. I
 can deploy a fresh zone, and the ssvm will actually start, but it
 can't transition state in the DB, so it kills the vm.

 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
 (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
 VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
 updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
 State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014} Stale
 Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14 01:56:38
 MDT 2014}
 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
 (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
 instance VM[SecondaryStorageVm|s-1-VM]
 com.cloud.exception.ConcurrentOperationException: Unable to transition
 to a new state.
 at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineM
a
n
agerImpl.java:1029)
 at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineM
a
n
agerImpl.java:5129)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
v
a
:57)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
r
I
mpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProx
y
.
java:107)
 at 
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineMa
n
a
gerImpl.java:5274)
 at 
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInCo
n
t
ext(AsyncJobManagerImpl.java:491)
 at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Mana
g
e
dContextRunnable.java:49)
 at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call
(
D
efaultManagedContext.java:56)
 at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWi
t
h
Context(DefaultManagedContext.java:103)
 at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWit
h
C
ontext(DefaultManagedContext.java:53)
 at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(Manage
d
C
ontextRunnable.java:46)
 at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(Asy
n
c
JobManagerImpl.java:448)
 at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja
v
a
:1145)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
a
v
a:615)
 at 

Re: Assigning a JIRA ticket to someone

[Mike Tutkowski]

Seif Eddine Jemli


On Fri, Mar 14, 2014 at 10:48 AM, Daan Hoogland wrote:

> who?
>
> On Fri, Mar 14, 2014 at 4:03 PM, Mike Tutkowski
>  wrote:
> > Hi,
> >
> > I'm trying to assign a JIRA ticket to someone who has a JIRA account,
> but I
> > don't see his name in the list (I see plenty of other names in the list I
> > recognize, though).
> >
> > Any thoughts on what I might be missing here?
> >
> > Thanks!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*
>
>
>
> --
> Daan
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: Assigning a JIRA ticket to someone

[Daan Hoogland]

who?

On Fri, Mar 14, 2014 at 4:03 PM, Mike Tutkowski
 wrote:
> Hi,
>
> I'm trying to assign a JIRA ticket to someone who has a JIRA account, but I
> don't see his name in the list (I see plenty of other names in the list I
> recognize, though).
>
> Any thoughts on what I might be missing here?
>
> Thanks!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*



-- 
Daan

Re: [Merge] CloudStack IAM branch to master

[Min Chen]

Marcus,

What is the latest commit you have picked up on your local setup from
master? Our QA reports similar issues caused by recent VMSync bug fix,
just want to make sure that your local code has that fix.

Thanks
-min

On 3/14/14 9:37 AM, "Min Chen"  wrote:

>Before merge, I did a sanity zone and VM deployment test, and worked fine
>on my setup after fixing the issues introduced by Antonio's commit. I can
>verify this again today. From the symptom, it seems not related to IAM
>change.
>
>Thanks
>-min
>
>
>
>On 3/14/14 1:07 AM, "Marcus"  wrote:
>
>>creating a new router does the same...
>>
>>2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
>>VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
>>time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
>>updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
>>State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
>>2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
>>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
>>instance VM[DomainRouter|r-5-VM]
>>com.cloud.exception.ConcurrentOperationException: Unable to transition
>>to a new state.
>>at 
>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMan
>>a
>>gerImpl.java:1029)
>>at 
>>com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManager
>>I
>>mpl.java:775)
>>
>>On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
>>> I have no idea if its related to this branch merge or not, but I'm
>>> unable to start the ssvm on master since I pulled about an hour ago. I
>>> can deploy a fresh zone, and the ssvm will actually start, but it
>>> can't transition state in the DB, so it kills the vm.
>>>
>>> 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
>>> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
>>> VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
>>> updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
>>> State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014} Stale
>>> Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14 01:56:38
>>> MDT 2014}
>>> 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
>>> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
>>> instance VM[SecondaryStorageVm|s-1-VM]
>>> com.cloud.exception.ConcurrentOperationException: Unable to transition
>>> to a new state.
>>> at 
>>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMa
>>>n
>>>agerImpl.java:1029)
>>> at 
>>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMa
>>>n
>>>agerImpl.java:5129)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at 
>>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
>>>a
>>>:57)
>>> at 
>>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
>>>I
>>>mpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:606)
>>> at 
>>>com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy
>>>.
>>>java:107)
>>> at 
>>>com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineMan
>>>a
>>>gerImpl.java:5274)
>>> at 
>>>com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
>>> at 
>>>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInCon
>>>t
>>>ext(AsyncJobManagerImpl.java:491)
>>> at 
>>>org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Manag
>>>e
>>>dContextRunnable.java:49)
>>> at 
>>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(
>>>D
>>>efaultManagedContext.java:56)
>>> at 
>>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWit
>>>h
>>>Context(DefaultManagedContext.java:103)
>>> at 
>>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWith
>>>C
>>>ontext(DefaultManagedContext.java:53)
>>> at 
>>>org.apache.cloudstack.managed.context.ManagedContextRunnable.run(Managed
>>>C
>>>ontextRunnable.java:46)
>>> at 
>>>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(Asyn
>>>c
>>>JobManagerImpl.java:448)
>>> at 
>>>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>>> at 
>>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
>>>a
>>>:1145)
>>> at 
>>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
>>>v
>>>a:615)
>>> at java.lang.Thread.run(Thread.java:744)
>>>
>>> On Thu, Mar 13, 2014 at 11:30 PM, Marcus  wrote:
 Min, in looking at this branch merge, I need to be reminded whether we
 are supposed to squash feature branches when they come in, or preserve
 history. It's nice to preserve history, but it's a lot easier to undo
 a squashed merge.

 On Thu, Mar 13, 2014 at 5:56 PM, Min Chen  wrote:
> IA

Re: Review Request 19039: CLOUDSTACK-2266: Adding automation tests for IP reservation feature

[Ashutosh Kelkar]

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

(Updated March 14, 2014, 4:44 p.m.)


Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.


Changes
---

Updated patch with next set of test cases.


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


Repository: cloudstack-git


Description
---

Adding first set of automation tests for IP reservation feature.


Diffs (updated)
-

  test/integration/component/test_ip_reservation.py 224212f 
  tools/marvin/marvin/config/config.cfg 356a291 

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


Testing
---

Yes. Log below.

test_RVR_network (test_ip_reservation.TestIpReservation) ... SKIP: Skip - WIP
test_ip_reservation_in_multiple_networks_same_account 
(test_ip_reservation.TestIpReservation) ... ok
test_nat_rules_nat rule (test_ip_reservation.TestIpReservation) ... ok
test_nat_rules_static nat rule (test_ip_reservation.TestIpReservation) ... ok
test_update_cidr_multiple_vms_not_all_inclusive 
(test_ip_reservation.TestIpReservation) ... ok
test_update_cidr_single_vm_not_inclusive 
(test_ip_reservation.TestIpReservation) ... ok
test_user_defined_cidr (test_ip_reservation.TestIpReservation) ... ok
test_vm_create_after_reservation_LB-NS (test_ip_reservation.TestIpReservation) 
... SKIP: Skipping - this test required netscaler configured in the network
test_vm_create_after_reservation_LB-VR (test_ip_reservation.TestIpReservation) 
... ok
test_vm_create_outside_cidr_after_reservation_LB-NS 
(test_ip_reservation.TestIpReservation) ... SKIP: Skipping - this test required 
netscaler configured in the network
test_vm_create_outside_cidr_after_reservation_LB-VR 
(test_ip_reservation.TestIpReservation) ... ok
--
Ran 11 tests in 3753.613s

OK

Two tests which require Netscaler configured are skipped due to netscaler was 
not available on setup.


Thanks,

Ashutosh Kelkar

Re: Master is broken?

[Antonio Fornié Casarrubios]

ApiDispatcher#dispatchAbout the previous questions, I think checkUuid()
 should be executed in any case. Actually this part was added recently,
before that there was already the return to avoid getting to the
cmd.execute(). So I think when the checkUuid was added it should have been
added for any case, and not only for the case when it's not enqueued and
returns. Can anybody confirm?



2014-03-14 17:33 GMT+01:00 Antonio Fornié Casarrubios <
antonio.for...@gmail.com>:

> Hi Talluri.
> I am trying to know what causes the issue you describe. Just to make sure
> I understand you, why do you think this issue is related with this change?
> Anybody knows anything else about it?
> Thanks. Cheers
> Antonio
>
>
> 2014-03-14 14:17 GMT+01:00 Srikanteswararao Talluri <
> srikanteswararao.tall...@citrix.com>:
>
> I am seeing another issue on master.
>> Filed a bug for this
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6239
>>
>> Thanks,
>> ~Talluri
>>
>> On 14/03/14 3:50 pm, "Daan Hoogland"  wrote:
>>
>> >On Fri, Mar 14, 2014 at 11:08 AM, Antonio Fornié Casarrubios
>> > wrote:
>> >> antonio.fornie
>> >
>> >
>> >is in
>> >
>> >--
>> >Daan
>>
>>
>

Re: [Merge] CloudStack IAM branch to master

[Min Chen]

Before merge, I did a sanity zone and VM deployment test, and worked fine
on my setup after fixing the issues introduced by Antonio's commit. I can
verify this again today. From the symptom, it seems not related to IAM
change.

Thanks
-min



On 3/14/14 1:07 AM, "Marcus"  wrote:

>creating a new router does the same...
>
>2014-03-14 02:06:41,446 DEBUG [vm.dao.VMInstanceDaoImpl]
>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Unable to update
>VM[DomainRouter|r-5-VM]: DB Data={Host=1; State=Running; updated=3;
>time=Fri Mar 14 02:06:11 MDT 2014} New Data: {Host=1; State=Running;
>updated=3; time=Fri Mar 14 02:06:11 MDT 2014} Stale Data: {Host=1;
>State=Starting; updated=2; time=Fri Mar 14 02:05:52 MDT 2014}
>2014-03-14 02:06:41,448 ERROR [cloud.vm.VirtualMachineManagerImpl]
>(Work-Job-Executor-5:Job-41/Job-42 ctx-91928df8) Failed to start
>instance VM[DomainRouter|r-5-VM]
>com.cloud.exception.ConcurrentOperationException: Unable to transition
>to a new state.
>at 
>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMana
>gerImpl.java:1029)
>at 
>com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerI
>mpl.java:775)
>
>On Fri, Mar 14, 2014 at 2:03 AM, Marcus  wrote:
>> I have no idea if its related to this branch merge or not, but I'm
>> unable to start the ssvm on master since I pulled about an hour ago. I
>> can deploy a fresh zone, and the ssvm will actually start, but it
>> can't transition state in the DB, so it kills the vm.
>>
>> 2014-03-14 01:57:46,356 DEBUG [vm.dao.VMInstanceDaoImpl]
>> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Unable to update
>> VM[SecondaryStorageVm|s-1-VM]: DB Data={Host=1; State=Running;
>> updated=19; time=Fri Mar 14 01:57:11 MDT 2014} New Data: {Host=1;
>> State=Running; updated=19; time=Fri Mar 14 01:57:11 MDT 2014} Stale
>> Data: {Host=1; State=Starting; updated=18; time=Fri Mar 14 01:56:38
>> MDT 2014}
>> 2014-03-14 01:57:46,359 ERROR [cloud.vm.VirtualMachineManagerImpl]
>> (Work-Job-Executor-1:Job-33/Job-34 ctx-5fc7b113) Failed to start
>> instance VM[SecondaryStorageVm|s-1-VM]
>> com.cloud.exception.ConcurrentOperationException: Unable to transition
>> to a new state.
>> at 
>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMan
>>agerImpl.java:1029)
>> at 
>>com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineMan
>>agerImpl.java:5129)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>>:57)
>> at 
>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>mpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at 
>>com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.
>>java:107)
>> at 
>>com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineMana
>>gerImpl.java:5274)
>> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
>> at 
>>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInCont
>>ext(AsyncJobManagerImpl.java:491)
>> at 
>>org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Manage
>>dContextRunnable.java:49)
>> at 
>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(D
>>efaultManagedContext.java:56)
>> at 
>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWith
>>Context(DefaultManagedContext.java:103)
>> at 
>>org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithC
>>ontext(DefaultManagedContext.java:53)
>> at 
>>org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedC
>>ontextRunnable.java:46)
>> at 
>>org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(Async
>>JobManagerImpl.java:448)
>> at 
>>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>> at 
>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
>>:1145)
>> at 
>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav
>>a:615)
>> at java.lang.Thread.run(Thread.java:744)
>>
>> On Thu, Mar 13, 2014 at 11:30 PM, Marcus  wrote:
>>> Min, in looking at this branch merge, I need to be reminded whether we
>>> are supposed to squash feature branches when they come in, or preserve
>>> history. It's nice to preserve history, but it's a lot easier to undo
>>> a squashed merge.
>>>
>>> On Thu, Mar 13, 2014 at 5:56 PM, Min Chen  wrote:
 IAM branch is now merged to master.

 Thanks
 -min

 On 3/13/14 10:13 AM, "Min Chen"  wrote:

>Since we haven't heard of any objections to this merge for 3 days, I
>am
>going to merge it to master today.
>
>Thanks
>-min
>
>On 3/11/14 12:23 PM, "Hugo Trippaers"  wrote:
>
>>
>>On 11 mrt. 2014, at 19:52, Min Chen  wrote:
>>
>>> Also, have already run FingBugs on our branch and addressed all ne

Re: [Merge] CloudStack IAM branch to master

[Min Chen]

Thanks Marcus. I am not aware of this convention, will remember that next
time when I do the merge.

-min

On 3/13/14 10:30 PM, "Marcus"  wrote:

>Min, in looking at this branch merge, I need to be reminded whether we
>are supposed to squash feature branches when they come in, or preserve
>history. It's nice to preserve history, but it's a lot easier to undo
>a squashed merge.
>
>On Thu, Mar 13, 2014 at 5:56 PM, Min Chen  wrote:
>> IAM branch is now merged to master.
>>
>> Thanks
>> -min
>>
>> On 3/13/14 10:13 AM, "Min Chen"  wrote:
>>
>>>Since we haven't heard of any objections to this merge for 3 days, I am
>>>going to merge it to master today.
>>>
>>>Thanks
>>>-min
>>>
>>>On 3/11/14 12:23 PM, "Hugo Trippaers"  wrote:
>>>

On 11 mrt. 2014, at 19:52, Min Chen  wrote:

> Also, have already run FingBugs on our branch and addressed all new
> findings introduced by our branch.

Awesome! :-)

>
> Thanks.
> -min
>
> On 3/10/14 7:33 PM, "Min Chen"  wrote:
>
>> No new jar dependencies.
>>
>> -min
>>
>> Sent from my iPhone
>>
>>> On Mar 10, 2014, at 7:22 PM, "Chiradeep Vittal"
>>>  wrote:
>>>
>>> Any new jar dependencies?
>>>
 On 3/10/14, 11:34 AM, "Min Chen"  wrote:

 Hi,

 Prachi and I would like to merge CloudStack Identity and Access
 Management(IAM) plugin services to the master branch. Development
for
 this effort has been done by Prachi and me on ACS rbac branch


(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlo
g;
h
=r
 ef
 s/heads/rbac).
 Checklists for the merge:
 1. JIRA ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-5920.
 2. Functional Specs:


https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+I
de
n
ti
 ty
 +and+Access+Management+%28IAM%29+Plugin. We have proposed this
feature
 back in Jan, and accommodated all the feedbacks in our
implementation.
 3. Unit tests for the feature are available at:
 services/iam/server/test
 (for iam server) and services/iam/plugin/test (for iam plugin).
 4. Marvin integration tests for the feature are available at:
 test/integration/smoke/test_vm_iam.py.
 5. Branch has been rebased with master branch up to commit
 63e3eea7905e22cab9466b28a2ab2a80b586aeed.
 6. RAT test has been passed.

 Thanks.
 -min
>>>
>

>>>
>>

Re: Master is broken?

[Antonio Fornié Casarrubios]

Hi Talluri.
I am trying to know what causes the issue you describe. Just to make sure I
understand you, why do you think this issue is related with this change?
Anybody knows anything else about it?
Thanks. Cheers
Antonio


2014-03-14 14:17 GMT+01:00 Srikanteswararao Talluri <
srikanteswararao.tall...@citrix.com>:

> I am seeing another issue on master.
> Filed a bug for this
> https://issues.apache.org/jira/browse/CLOUDSTACK-6239
>
> Thanks,
> ~Talluri
>
> On 14/03/14 3:50 pm, "Daan Hoogland"  wrote:
>
> >On Fri, Mar 14, 2014 at 11:08 AM, Antonio Fornié Casarrubios
> > wrote:
> >> antonio.fornie
> >
> >
> >is in
> >
> >--
> >Daan
>
>

RE: Differences between 4.3 and 4.3-forward

[Animesh Chaturvedi]

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Friday, March 14, 2014 7:43 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Differences between 4.3 and 4.3-forward
> 
> Yes, and we definitely cannot just take all of 4.3.1 and put it in 4.3 as many
> of those changes are intended for 4.3.1 and not 4.3.
[Animesh]  Yes that is correct. I was pulling in commits that I was asked to 
cherry-pick from 4.3-forward and the one that I thought were important. There 
were some that I had not picked up and had followed up with few folks like 
Marcus in case they need to be pulled in.

We cannot pull in 4.3-forward into 4.3. 4.3-forward branch will be merged into 
4.3 after 4.3 is released

> 
> 
> On Fri, Mar 14, 2014 at 8:40 AM, Sudha Ponnaganti <
> sudha.ponnaga...@citrix.com> wrote:
> 
> > Yes - 4.3-forward is unstable branch and should be merged while 4.3 is
> > going through RC. It is meant for maintenance release.
> >
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Friday, March 14, 2014 7:36 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Differences between 4.3 and 4.3-forward
> >
> > Right, I think it's dangerous to sync 4.3.1 to 4.3 because developers
> > might have changes in 4.3.1 that are not yet in master.
> >
> > This is not my situation personally, but I imagine some devs might be
> > in this state.
> >
> >
> > On Fri, Mar 14, 2014 at 8:18 AM, Sudha Ponnaganti <
> > sudha.ponnaga...@citrix.com> wrote:
> >
> > > Yes that is my understanding that all of these would go in to next
> > > maintenance that is why they are staged in forward branch.
> > >
> > > -Original Message-
> > > From: Paul Angus [mailto:paul.an...@shapeblue.com]
> > > Sent: Friday, March 14, 2014 1:38 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: RE: Differences between 4.3 and 4.3-forward
> > >
> > > Will these automatically go into 4.3.1, do we know if they've gone
> > > into master as well?
> > >
> > > Otherwise does this mean we have a load of bug fixes which we're not
> > > putting into 4.3.0 which could potentially become orphaned in the
> > > 4.3-forward branch? (this query may be just my ignorance regarding
> > > ACS
> > > branching)
> > >
> > > Regards,
> > >
> > > Paul Angus
> > > Cloud Architect
> > > S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
> > > paul.an...@shapeblue.com
> > >
> > > -Original Message-
> > > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> > > Sent: 12 March 2014 08:29
> > > To: 
> > > Subject: Differences between 4.3 and 4.3-forward
> > >
> > > Hey,
> > >
> > > There is a sizable number of differences between the two branch.
> > > Maybe it's time to ditch 4.3-forward and recreate it based on current 4.3?
> > >
> > > Cheers,
> > >
> > > Hugo
> > >
> > >
> > > Hugos-MacBook-Pro:cloudstack hugo (4.3-forward)$ git diff --stat
> > > 4.3-forward 4.3
> > >
> >
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCert
> > ToLoadBalancerCmd.java
> > >|3 +-
> > >
> >
> >
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCer
> t
> > FromLoadBalancerCmd.java
> > >  |2 +-
> > >  awsapi/pom.xml
> > >|2 +-
> > >  client/pom.xml
> > >|   20 ++-
> > >  client/tomcatconf/catalina.properties.in
> > >|2 +-
> > >  debian/changelog
> > >|7 +-
> > >  developer/pom.xml
> > >   |1 -
> > >  engine/components-
> api/src/com/cloud/template/TemplateManager.java
> > >   |9 +-
> > >
> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> > >|   36 +
> > >
> >
> > engine/orchestration/src/org/apache/cloudstack/engine/orchestration/Vo
> > lumeOrchestrator.java
> > > |   10 +-
> > >
> >
> > engine/schema/resources/META-INF/cloudstack/core/spring-engine-
> schema-
> > core-daos-context.xml
> > > |2 +-
> > >
> >
> >
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDa
> > taStoreDao.java
> > >   |2 -
> > >
> >
> >
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDa
> > taStoreDaoImpl.java
> > >   |   48 +-
> > >  engine/storage/integration-test/pom.xml
> > >   |5 -
> > >
> >
> > engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStorag
> > ePoolAllocator.java
> > >   |8 +-
> > >  framework/db/pom.xml
> > >|5 -
> > >  framework/db/src/com/cloud/utils/db/StaticStrategy.java

Re: [ACS4.4] RE: Git Push Summary : 4.4 feature branch

[Hugo Trippaers]

Fair enough, i’ll try to send a reminder for the next phases a bit earlier. 
Just wanted to make sure that people wouldn’t forget to put their merge 
requests in on time. 

I’m trying to be a bit strict about the timing, we are already seeing the 
strain on the 4.3 release which isn’t even out there yet. Breaking master in 
such a bad way now is quite unfortunate, but actually not uncommon for us so 
close to a feature freeze. I’m willing to gamble that extending the feature 
freeze would have made it worse.

Again, anybody with a Merge request currently open on the ML has a fair point 
to merge the changes into the 4.4 branch as well as into master.

 


Cheers,

Hugo


On 14 mrt. 2014, at 16:23, Marcus  wrote:

> Yes, you did. I for one was up until 2AM trying to test my branch
> against the current master to try to get it in, but gave up.
> 
> I think most people saw "Get your merge request in today because I'll
> be cutting the branch on Friday". At the time that most of us in the
> west read that email, "get your merge request in today" did not apply
> because it was technically already too late per your time spec.
> 
> On Fri, Mar 14, 2014 at 9:12 AM, Hugo Trippaers  wrote:
>> The branch is already cut and master has already been switched to 4.5.0. 
>> I've announced that the switch would be at 14:00 CET, you can't expect me to 
>> get up in the middle of the night to cut a release branch.
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> 
>> On 14 mrt. 2014, at 16:09, Sudha Ponnaganti  
>> wrote:
>> 
>>> Can time be given till PST EOD as many developers are also in this time 
>>> zone?
>>> If specific features are being pulled in to 4.4, we might as well cut 
>>> branch a little later where approved merge queue is cleared.
>>> 
>>> 
>>> -Original Message-
>>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
>>> Sent: Friday, March 14, 2014 7:56 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: Git Push Summary : 4.4 feature branch
>>> 
>>> Yes, I think we could have checked with people struggling to fix the master 
>>> and commit there features.
>>> -1 for the timing to cut the branch !
>>> 
>>> On 14/03/14 8:19 pm, "Murali Reddy"  wrote:
>>> 
 On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
 
> Repository: cloudstack
> Updated Branches:
> refs/heads/4.4 [created] 3ee1fc28d
> 
 
 Hugo,
 
 I was holding off merge to master, as it seems to be broken now. I see
 that you already created 4.4 branch. Can we wait till master is ready
 to be checked-in and then cut a branch?
 
 Thanks,
 Murali
 
>>> 
>> 

Re: Review Request 17736: CLOUDSTACK-5999: Virtual Router does not start if Guest VM is rebooted from CloudStack

[Saksham Srivastava]

> On March 13, 2014, 4:55 p.m., Alena Prokharchyk wrote:
> > Also why don't start routers in parallel? First, get all the router nics in 
> > one query like John suggested, then span start process for routers in 
> > separate threads, check the status of each job using Future.

Sure I will do that.


- Saksham


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


On March 13, 2014, 7:31 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17736/
> ---
> 
> (Updated March 13, 2014, 7:31 a.m.)
> 
> 
> Review request for cloudstack, John Burwell and Murali Reddy.
> 
> 
> Bugs: CLOUDSTACK-5999
> https://issues.apache.org/jira/browse/CLOUDSTACK-5999
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> When a guest is rebooted from CloudStack, if the virtual router managing the 
> guest network of that guest is down, CloudStack will not start the virtual 
> router.
> However the router is started in case the guest vm is stopped and then 
> started.
> To mantain similarity between the 2 process it is necessary to start the VR 
> in case it is not running.
> The fix will address the same.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java be00aa8 
> 
> Diff: https://reviews.apache.org/r/17736/diff/
> 
> 
> Testing
> ---
> 
> Testing:
> 1) vm in a single guest network :
>vm Reboot : If the VR is stopped: VR is first started and then 
> the VM reboots.
>vm Reboot : If the VR is running, VM reboots as it used to.
> vm Stop/Start continue to work the same.
> 
> 2)  vm having nics in multi networks :
>vm Reboot : If VR in any/all network is stopped: VRs are first 
> started and then the VM reboots.
>vm Reboot : If the VRs are running, VM reboots as it used to.
> vm Stop/Start continue to work the same.
> 
> 3) vpc :
>Tested the above scenarios for vpc also, works fine.
> 
> Patch applies cleanly.
> Build passes succesfully.
> FindBug is passed.
> Rebased against latest master.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request 17736: CLOUDSTACK-5999: Virtual Router does not start if Guest VM is rebooted from CloudStack

[Saksham Srivastava]

> On March 13, 2014, 4:46 p.m., John Burwell wrote:
> > server/src/com/cloud/vm/UserVmManagerImpl.java, line 756
> > 
> >
> > Two queries are executed in this for loop which puts stress on the 
> > database and slows down the application.  Furthermore, this for loop 
> > appears to be performing in-memory join and filter operations.  Please 
> > refactor into a single query performed by the most appropriate DAO.

I guess I completely misunderstood the last comment by you, now it makes 
complete sense to me. Thanks for the suggestion John, I will update my patch 
with a single query.


- Saksham


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


On March 13, 2014, 7:31 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17736/
> ---
> 
> (Updated March 13, 2014, 7:31 a.m.)
> 
> 
> Review request for cloudstack, John Burwell and Murali Reddy.
> 
> 
> Bugs: CLOUDSTACK-5999
> https://issues.apache.org/jira/browse/CLOUDSTACK-5999
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> When a guest is rebooted from CloudStack, if the virtual router managing the 
> guest network of that guest is down, CloudStack will not start the virtual 
> router.
> However the router is started in case the guest vm is stopped and then 
> started.
> To mantain similarity between the 2 process it is necessary to start the VR 
> in case it is not running.
> The fix will address the same.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java be00aa8 
> 
> Diff: https://reviews.apache.org/r/17736/diff/
> 
> 
> Testing
> ---
> 
> Testing:
> 1) vm in a single guest network :
>vm Reboot : If the VR is stopped: VR is first started and then 
> the VM reboots.
>vm Reboot : If the VR is running, VM reboots as it used to.
> vm Stop/Start continue to work the same.
> 
> 2)  vm having nics in multi networks :
>vm Reboot : If VR in any/all network is stopped: VRs are first 
> started and then the VM reboots.
>vm Reboot : If the VRs are running, VM reboots as it used to.
> vm Stop/Start continue to work the same.
> 
> 3) vpc :
>Tested the above scenarios for vpc also, works fine.
> 
> Patch applies cleanly.
> Build passes succesfully.
> FindBug is passed.
> Rebased against latest master.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 14:43, Wei ZHOU wrote:

Can you try to revert commit 175549f3ab952bbd39318c16c269c16526255475
on ./scripts/vm/network/security_group.py ?

git checkout
0898a264a5463b85c4cab3033f9c3161c5ef83f8 
./scripts/vm/network/security_group.py

scp to all hosts, and try again.



I got it from here:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/network/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0898a264a5463b85c4cab3033f9c3161c5ef83f8

And yes, it works with this one, ingress and egress rules seem to apply 
fine. Thanks!


Is there anything you can do for the ipset problem? 
https://issues.apache.org/jira/browse/CLOUDSTACK-6240


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Ove Ewerlid]

On 03/14/2014 03:29 PM, Wei ZHOU wrote:

Nux and Ove,

Did you test on fresh 4.2.1 platform?


Yes, fresh 4.2.1.

/Ove



-Wei


2014-03-14 15:07 GMT+01:00 Nux! :


On 14.03.2014 13:59, Wei ZHOU wrote:


Is this similar to CLOUDSTACK-5144?



Yes, but it's only exhibited on KVM.
My colleague who is testing 4.3 with Xenserver is reporting the SG rules
work as expected (though ipset update still requires VM stop/start).


Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro






--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706662363 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

Re: [ACS4.4] RE: Git Push Summary : 4.4 feature branch

[Marcus]

Yes, you did. I for one was up until 2AM trying to test my branch
against the current master to try to get it in, but gave up.

I think most people saw "Get your merge request in today because I'll
be cutting the branch on Friday". At the time that most of us in the
west read that email, "get your merge request in today" did not apply
because it was technically already too late per your time spec.

On Fri, Mar 14, 2014 at 9:12 AM, Hugo Trippaers  wrote:
> The branch is already cut and master has already been switched to 4.5.0. I've 
> announced that the switch would be at 14:00 CET, you can't expect me to get 
> up in the middle of the night to cut a release branch.
>
> Cheers,
>
> Hugo
>
>
> On 14 mrt. 2014, at 16:09, Sudha Ponnaganti  
> wrote:
>
>> Can time be given till PST EOD as many developers are also in this time zone?
>> If specific features are being pulled in to 4.4, we might as well cut branch 
>> a little later where approved merge queue is cleared.
>>
>>
>> -Original Message-
>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
>> Sent: Friday, March 14, 2014 7:56 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: Git Push Summary : 4.4 feature branch
>>
>> Yes, I think we could have checked with people struggling to fix the master 
>> and commit there features.
>> -1 for the timing to cut the branch !
>>
>> On 14/03/14 8:19 pm, "Murali Reddy"  wrote:
>>
>>> On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
>>>
 Repository: cloudstack
 Updated Branches:
 refs/heads/4.4 [created] 3ee1fc28d

>>>
>>> Hugo,
>>>
>>> I was holding off merge to master, as it seems to be broken now. I see
>>> that you already created 4.4 branch. Can we wait till master is ready
>>> to be checked-in and then cut a branch?
>>>
>>> Thanks,
>>> Murali
>>>
>>
>

Re: Git Push Summary : 4.4 feature branch

[Mike Tutkowski]

Since a lot of devs are basing their features that have not yet been placed
in Git off of master (which is now 4.5), we need to make sure it is clear
not to rebase yourself beyond 48f8a95b06b0348ba1349cb5434183c2c18710db or
4.5 code that should not be in 4.4 could be brought into 4.4.


On Fri, Mar 14, 2014 at 9:04 AM, Hugo Trippaers  wrote:

> I announced the time when i would cut the branch in advance, so it
> shouldn't be a surprise.
>
> But like i replied to Muralli, if you have a pending merge request on the
> ML i see no problem with merging it in in the next few hours because of the
> trouble with master. Just make sure it hits both master and the 4.4 branch.
> I'll even happily do it for you if you point me to the branch that needs to
> be merged into 4.4. Just make sure its rebased up to commit id
> 48f8a95b06b0348ba1349cb5434183c2c18710db and not further.
>
> Cheers,
>
> Hugo
>
> On 14 mrt. 2014, at 15:56, Abhinandan Prateek <
> abhinandan.prat...@citrix.com> wrote:
>
> > Yes, I think we could have checked with people struggling to fix the
> > master and commit there features.
> > -1 for the timing to cut the branch !
> >
> > On 14/03/14 8:19 pm, "Murali Reddy"  wrote:
> >
> >> On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
> >>
> >>> Repository: cloudstack
> >>> Updated Branches:
> >>> refs/heads/4.4 [created] 3ee1fc28d
> >>>
> >>
> >> Hugo,
> >>
> >> I was holding off merge to master, as it seems to be broken now. I see
> >> that you already created 4.4 branch. Can we wait till master is ready to
> >> be checked-in and then cut a branch?
> >>
> >> Thanks,
> >> Murali
> >>
> >
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: [ACS4.4] RE: Git Push Summary : 4.4 feature branch

[Hugo Trippaers]

The branch is already cut and master has already been switched to 4.5.0. I’ve 
announced that the switch would be at 14:00 CET, you can’t expect me to get up 
in the middle of the night to cut a release branch.

Cheers,

Hugo


On 14 mrt. 2014, at 16:09, Sudha Ponnaganti  wrote:

> Can time be given till PST EOD as many developers are also in this time zone? 
>  
> If specific features are being pulled in to 4.4, we might as well cut branch 
> a little later where approved merge queue is cleared. 
> 
> 
> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] 
> Sent: Friday, March 14, 2014 7:56 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Git Push Summary : 4.4 feature branch
> 
> Yes, I think we could have checked with people struggling to fix the master 
> and commit there features.
> -1 for the timing to cut the branch !
> 
> On 14/03/14 8:19 pm, "Murali Reddy"  wrote:
> 
>> On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
>> 
>>> Repository: cloudstack
>>> Updated Branches:
>>> refs/heads/4.4 [created] 3ee1fc28d
>>> 
>> 
>> Hugo,
>> 
>> I was holding off merge to master, as it seems to be broken now. I see 
>> that you already created 4.4 branch. Can we wait till master is ready 
>> to be checked-in and then cut a branch?
>> 
>> Thanks,
>> Murali
>> 
> 

Re: Git Push Summary : 4.4 feature branch

[Abhinandan Prateek]

Thanks Hugo ! Saw your reply bit late.

On 14/03/14 8:34 pm, "Hugo Trippaers"  wrote:

>I announced the time when i would cut the branch in advance, so it
>shouldn¹t be a surprise.
>
>But like i replied to Muralli, if you have a pending merge request on the
>ML i see no problem with merging it in in the next few hours because of
>the trouble with master. Just make sure it hits both master and the 4.4
>branch. I¹ll even happily do it for you if you point me to the branch
>that needs to be merged into 4.4. Just make sure its rebased up to commit
>id 48f8a95b06b0348ba1349cb5434183c2c18710db and not further.
>
>Cheers,
>
>Hugo
>
>On 14 mrt. 2014, at 15:56, Abhinandan Prateek
> wrote:
>
>> Yes, I think we could have checked with people struggling to fix the
>> master and commit there features.
>> -1 for the timing to cut the branch !
>> 
>> On 14/03/14 8:19 pm, "Murali Reddy"  wrote:
>> 
>>> On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
>>> 
 Repository: cloudstack
 Updated Branches:
 refs/heads/4.4 [created] 3ee1fc28d
 
>>> 
>>> Hugo,
>>> 
>>> I was holding off merge to master, as it seems to be broken now. I see
>>> that you already created 4.4 branch. Can we wait till master is ready
>>>to
>>> be checked-in and then cut a branch?
>>> 
>>> Thanks,
>>> Murali
>>> 
>> 
>

Re: Git Push Summary

[Murali Reddy]

On 14/03/14 8:24 PM, "Hugo Trippaers"  wrote:

>Hey Muralli,
>
>The branch is already cut and the jenkins builds are setup. So i¹m not
>going to recreate the 4.4 branch from master as all the version number
>are already updated.
>
>Which merge request are you merging in? If you can squash it it will be
>easy to pull into master and 4.4.

I am referring to region level VPC merge request. I will put squashed
commit in both 4.4 and master. Thanks for the clarification.

[1] http://www.mail-archive.com/dev@cloudstack.apache.org/msg24747.html

>
>
>Cheers,
>
>Hugo
>
>
>
>On 14 mrt. 2014, at 15:49, Murali Reddy  wrote:
>
>> On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
>> 
>>> Repository: cloudstack
>>> Updated Branches:
>>> refs/heads/4.4 [created] 3ee1fc28d
>>> 
>> 
>> Hugo,
>> 
>> I was holding off merge to master, as it seems to be broken now. I see
>> that you already created 4.4 branch. Can we wait till master is ready to
>> be checked-in and then cut a branch?
>> 
>> Thanks,
>> Murali
>> 
>
>

[ACS4.4] RE: Git Push Summary : 4.4 feature branch

[Sudha Ponnaganti]

Can time be given till PST EOD as many developers are also in this time zone?  
If specific features are being pulled in to 4.4, we might as well cut branch a 
little later where approved merge queue is cleared. 


-Original Message-
From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] 
Sent: Friday, March 14, 2014 7:56 AM
To: dev@cloudstack.apache.org
Subject: Re: Git Push Summary : 4.4 feature branch

Yes, I think we could have checked with people struggling to fix the master and 
commit there features.
-1 for the timing to cut the branch !

On 14/03/14 8:19 pm, "Murali Reddy"  wrote:

>On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
>
>>Repository: cloudstack
>>Updated Branches:
>>  refs/heads/4.4 [created] 3ee1fc28d
>>
>
>Hugo,
>
>I was holding off merge to master, as it seems to be broken now. I see 
>that you already created 4.4 branch. Can we wait till master is ready 
>to be checked-in and then cut a branch?
>
>Thanks,
>Murali
>

Re: Git Push Summary : 4.4 feature branch

[Hugo Trippaers]

I announced the time when i would cut the branch in advance, so it shouldn’t be 
a surprise.

But like i replied to Muralli, if you have a pending merge request on the ML i 
see no problem with merging it in in the next few hours because of the trouble 
with master. Just make sure it hits both master and the 4.4 branch. I’ll even 
happily do it for you if you point me to the branch that needs to be merged 
into 4.4. Just make sure its rebased up to commit id 
48f8a95b06b0348ba1349cb5434183c2c18710db and not further.

Cheers,

Hugo

On 14 mrt. 2014, at 15:56, Abhinandan Prateek  
wrote:

> Yes, I think we could have checked with people struggling to fix the
> master and commit there features.
> -1 for the timing to cut the branch !
> 
> On 14/03/14 8:19 pm, "Murali Reddy"  wrote:
> 
>> On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
>> 
>>> Repository: cloudstack
>>> Updated Branches:
>>> refs/heads/4.4 [created] 3ee1fc28d
>>> 
>> 
>> Hugo,
>> 
>> I was holding off merge to master, as it seems to be broken now. I see
>> that you already created 4.4 branch. Can we wait till master is ready to
>> be checked-in and then cut a branch?
>> 
>> Thanks,
>> Murali
>> 
> 

Re: Git Push Summary : 4.4 feature branch

[Abhinandan Prateek]

Yes, I think we could have checked with people struggling to fix the
master and commit there features.
-1 for the timing to cut the branch !

On 14/03/14 8:19 pm, "Murali Reddy"  wrote:

>On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
>
>>Repository: cloudstack
>>Updated Branches:
>>  refs/heads/4.4 [created] 3ee1fc28d
>>
>
>Hugo,
>
>I was holding off merge to master, as it seems to be broken now. I see
>that you already created 4.4 branch. Can we wait till master is ready to
>be checked-in and then cut a branch?
>
>Thanks,
>Murali
>

Re: Git Push Summary

[Hugo Trippaers]

Hey Muralli,

The branch is already cut and the jenkins builds are setup. So i’m not going to 
recreate the 4.4 branch from master as all the version number are already 
updated.

Which merge request are you merging in? If you can squash it it will be easy to 
pull into master and 4.4.


Cheers,

Hugo



On 14 mrt. 2014, at 15:49, Murali Reddy  wrote:

> On 14/03/14 7:09 PM, "h...@apache.org"  wrote:
> 
>> Repository: cloudstack
>> Updated Branches:
>> refs/heads/4.4 [created] 3ee1fc28d
>> 
> 
> Hugo,
> 
> I was holding off merge to master, as it seems to be broken now. I see
> that you already created 4.4 branch. Can we wait till master is ready to
> be checked-in and then cut a branch?
> 
> Thanks,
> Murali
> 

Assigning a JIRA ticket to someone

[Mike Tutkowski]

Hi,

I'm trying to assign a JIRA ticket to someone who has a JIRA account, but I
don't see his name in the list (I see plenty of other names in the list I
recognize, though).

Any thoughts on what I might be missing here?

Thanks!

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: 4.4 Feature Freeze

[Marcus]

The build is not broken. I, personally, just cannot start VMs in my
environment, even after starting afresh. It may still be something I'm
doing (like a missed behavioral change), but I've seen at least one
bug submitted overnight that looks like a stack trace I got. It would
be nice to see if anyone else is seeing issues.

On Fri, Mar 14, 2014 at 8:45 AM, Mike Tutkowski
 wrote:
> Yes, having a temp freeze of the codebase while a build is broken is
> standard procedure at several places I've worked at.
>
> We should probably employ such a technique here, too.
>
> It's nothing enforced by the VCS - just something devs control when they
> see such an e-mail.
>
>
> On Fri, Mar 14, 2014 at 8:42 AM, Sudha Ponnaganti <
> sudha.ponnaga...@citrix.com> wrote:
>
>> Other alternative is to block further check-ins till blocking issue is
>> fixed. As long as BVTs are good then it can be opened up for further check
>> ins.  Just a suggestion.
>>
>> -Original Message-
>> From: Marcus [mailto:shadow...@gmail.com]
>> Sent: Friday, March 14, 2014 7:40 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>>
>> It may even just be a behavioral change or something simple I missed that
>> is now required with a recent check-in. Obviously I don't feel comfortable
>> merging in my feature branch though when I pull from master and can no
>> longer run my own feature tests.
>>
>> On Fri, Mar 14, 2014 at 8:35 AM, Marcus  wrote:
>> > I'm not sure what the offending ones are at the moment, and there was
>> > recently a  feature merge that was not squashed, so it might be a
>> > little difficult to weed through.
>> >
>> > On Mar 14, 2014 7:45 AM, "Sudha Ponnaganti"
>> > 
>> > wrote:
>> >>
>> >> Can the offending check-ins be reverted or master be blocked for
>> >> further check-ins till blocking issue is fixed.
>> >> Talluri is running BVTs and can that be taken as basic passing
>> >> criteria to re-enable check-ins.
>> >>
>> >> -Original Message-
>> >> From: Marcus [mailto:shadow...@gmail.com]
>> >> Sent: Friday, March 14, 2014 6:36 AM
>> >> To: dev@cloudstack.apache.org
>> >> Subject: Re: 4.4 Feature Freeze
>> >>
>> >> Will be doing it today, however it seems that there have been some
>> >> new issues that have cropped up in master that break basic
>> functionality.
>> >> I'm not sure if anyone should merge or not while that is the case.  I
>> >> was attempting to validate that the latest merges played well in my
>> >> branch, but I couldn't even get a vm running with the current master,
>> >> and I see that while I was sleeping others have reported some of the
>> >> issues I was seeing as well.
>> >>
>> >> On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
>> >> > On 11.03.2014 15:28, Hugo Trippaers wrote:
>> >> >>
>> >> >> Hey guys,
>> >> >>
>> >> >> I didn't go and tally all the +1s and -1s for the shift of the
>> >> >> feature freeze, but with so many reactions i feel sticking to the
>> >> >> schedule is the only way to go. We should only change dates if
>> >> >> there is a consensus and there clearly is none at the moment.
>> >> >> Let's take this discussion to the 4.5 release if we need to or
>> >> >> focus on doing a high quality release for 4.4 so we can focus on
>> >> >> features again in 4.4
>> >> >>
>> >> >> This means that the feature freeze would be this friday and i
>> >> >> intend to cut the 4.4 branch around 14:00 CET
>> >> >>
>> >> >> As we have a 72 hour window for MERGE requests, please make sure
>> >> >> they are in today (if the feature is ready).
>> >> >>
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Hugo
>> >> >
>> >> >
>> >> > Can someone confirm if this has made it in?
>> >> > https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>> >> >
>> >> > Marcus requested the MERGE a couple of days ago.
>> >> > http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
>> >> >
>> >> > Lucian
>> >> >
>> >> > --
>> >> > Sent from the Delta quadrant using Borg technology!
>> >> >
>> >> > Nux!
>> >> > www.nux.ro
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 14:43, Wei ZHOU wrote:

Can you try to revert commit 175549f3ab952bbd39318c16c269c16526255475
on ./scripts/vm/network/security_group.py ?

git checkout
0898a264a5463b85c4cab3033f9c3161c5ef83f8 
./scripts/vm/network/security_group.py

scp to all hosts, and try again.


Do you happen to have an HTTP url for that? I do not have git atm.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

RE: 4.4 Feature Freeze

[Sudha Ponnaganti]

Other alternative is to block further check-ins till blocking issue is fixed. 
As long as BVTs are good then it can be opened up for further check ins.  Just 
a suggestion. 

-Original Message-
From: Marcus [mailto:shadow...@gmail.com] 
Sent: Friday, March 14, 2014 7:40 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze

It may even just be a behavioral change or something simple I missed that is 
now required with a recent check-in. Obviously I don't feel comfortable merging 
in my feature branch though when I pull from master and can no longer run my 
own feature tests.

On Fri, Mar 14, 2014 at 8:35 AM, Marcus  wrote:
> I'm not sure what the offending ones are at the moment, and there was 
> recently a  feature merge that was not squashed, so it might be a 
> little difficult to weed through.
>
> On Mar 14, 2014 7:45 AM, "Sudha Ponnaganti" 
> 
> wrote:
>>
>> Can the offending check-ins be reverted or master be blocked for 
>> further check-ins till blocking issue is fixed.
>> Talluri is running BVTs and can that be taken as basic passing 
>> criteria to re-enable check-ins.
>>
>> -Original Message-
>> From: Marcus [mailto:shadow...@gmail.com]
>> Sent: Friday, March 14, 2014 6:36 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>>
>> Will be doing it today, however it seems that there have been some 
>> new issues that have cropped up in master that break basic functionality.
>> I'm not sure if anyone should merge or not while that is the case.  I 
>> was attempting to validate that the latest merges played well in my 
>> branch, but I couldn't even get a vm running with the current master, 
>> and I see that while I was sleeping others have reported some of the 
>> issues I was seeing as well.
>>
>> On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
>> > On 11.03.2014 15:28, Hugo Trippaers wrote:
>> >>
>> >> Hey guys,
>> >>
>> >> I didn't go and tally all the +1s and -1s for the shift of the 
>> >> feature freeze, but with so many reactions i feel sticking to the 
>> >> schedule is the only way to go. We should only change dates if 
>> >> there is a consensus and there clearly is none at the moment. 
>> >> Let's take this discussion to the 4.5 release if we need to or 
>> >> focus on doing a high quality release for 4.4 so we can focus on 
>> >> features again in 4.4
>> >>
>> >> This means that the feature freeze would be this friday and i 
>> >> intend to cut the 4.4 branch around 14:00 CET
>> >>
>> >> As we have a 72 hour window for MERGE requests, please make sure 
>> >> they are in today (if the feature is ready).
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> Hugo
>> >
>> >
>> > Can someone confirm if this has made it in?
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>> >
>> > Marcus requested the MERGE a couple of days ago.
>> > http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
>> >
>> > Lucian
>> >
>> > --
>> > Sent from the Delta quadrant using Borg technology!
>> >
>> > Nux!
>> > www.nux.ro

Re: Git Push Summary

[Murali Reddy]

On 14/03/14 7:09 PM, "h...@apache.org"  wrote:

>Repository: cloudstack
>Updated Branches:
>  refs/heads/4.4 [created] 3ee1fc28d
>

Hugo,

I was holding off merge to master, as it seems to be broken now. I see
that you already created 4.4 branch. Can we wait till master is ready to
be checked-in and then cut a branch?

Thanks,
Murali

Re: 4.4 Feature Freeze

[Mike Tutkowski]

Yes, having a temp freeze of the codebase while a build is broken is
standard procedure at several places I've worked at.

We should probably employ such a technique here, too.

It's nothing enforced by the VCS - just something devs control when they
see such an e-mail.


On Fri, Mar 14, 2014 at 8:42 AM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:

> Other alternative is to block further check-ins till blocking issue is
> fixed. As long as BVTs are good then it can be opened up for further check
> ins.  Just a suggestion.
>
> -Original Message-
> From: Marcus [mailto:shadow...@gmail.com]
> Sent: Friday, March 14, 2014 7:40 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
>
> It may even just be a behavioral change or something simple I missed that
> is now required with a recent check-in. Obviously I don't feel comfortable
> merging in my feature branch though when I pull from master and can no
> longer run my own feature tests.
>
> On Fri, Mar 14, 2014 at 8:35 AM, Marcus  wrote:
> > I'm not sure what the offending ones are at the moment, and there was
> > recently a  feature merge that was not squashed, so it might be a
> > little difficult to weed through.
> >
> > On Mar 14, 2014 7:45 AM, "Sudha Ponnaganti"
> > 
> > wrote:
> >>
> >> Can the offending check-ins be reverted or master be blocked for
> >> further check-ins till blocking issue is fixed.
> >> Talluri is running BVTs and can that be taken as basic passing
> >> criteria to re-enable check-ins.
> >>
> >> -Original Message-
> >> From: Marcus [mailto:shadow...@gmail.com]
> >> Sent: Friday, March 14, 2014 6:36 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: 4.4 Feature Freeze
> >>
> >> Will be doing it today, however it seems that there have been some
> >> new issues that have cropped up in master that break basic
> functionality.
> >> I'm not sure if anyone should merge or not while that is the case.  I
> >> was attempting to validate that the latest merges played well in my
> >> branch, but I couldn't even get a vm running with the current master,
> >> and I see that while I was sleeping others have reported some of the
> >> issues I was seeing as well.
> >>
> >> On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
> >> > On 11.03.2014 15:28, Hugo Trippaers wrote:
> >> >>
> >> >> Hey guys,
> >> >>
> >> >> I didn't go and tally all the +1s and -1s for the shift of the
> >> >> feature freeze, but with so many reactions i feel sticking to the
> >> >> schedule is the only way to go. We should only change dates if
> >> >> there is a consensus and there clearly is none at the moment.
> >> >> Let's take this discussion to the 4.5 release if we need to or
> >> >> focus on doing a high quality release for 4.4 so we can focus on
> >> >> features again in 4.4
> >> >>
> >> >> This means that the feature freeze would be this friday and i
> >> >> intend to cut the 4.4 branch around 14:00 CET
> >> >>
> >> >> As we have a 72 hour window for MERGE requests, please make sure
> >> >> they are in today (if the feature is ready).
> >> >>
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Hugo
> >> >
> >> >
> >> > Can someone confirm if this has made it in?
> >> > https://issues.apache.org/jira/browse/CLOUDSTACK-6181
> >> >
> >> > Marcus requested the MERGE a couple of days ago.
> >> > http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
> >> >
> >> > Lucian
> >> >
> >> > --
> >> > Sent from the Delta quadrant using Borg technology!
> >> >
> >> > Nux!
> >> > www.nux.ro
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Wei ZHOU]

OK, then ignore my previous email. it looks no issue with  security_group.py


2014-03-14 15:43 GMT+01:00 Nux! :

> On 14.03.2014 14:29, Wei ZHOU wrote:
>
>> Nux and Ove,
>>
>> Did you test on fresh 4.2.1 platform?
>>
>>
> Yes. Fresh 4.2.1 doesn't have the problem, fresh 4.3 RC8 has the problem.
>
> HTH
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Wei ZHOU]

Can you try to revert commit 175549f3ab952bbd39318c16c269c16526255475
on ./scripts/vm/network/security_group.py ?

git checkout
0898a264a5463b85c4cab3033f9c3161c5ef83f8 ./scripts/vm/network/security_group.py
scp to all hosts, and try again.

-Wei


2014-03-14 15:07 GMT+01:00 Nux! :

> On 14.03.2014 13:59, Wei ZHOU wrote:
>
>> Is this similar to CLOUDSTACK-5144?
>>
>
> Yes, but it's only exhibited on KVM.
> My colleague who is testing 4.3 with Xenserver is reporting the SG rules
> work as expected (though ipset update still requires VM stop/start).
>
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 14:29, Wei ZHOU wrote:

Nux and Ove,

Did you test on fresh 4.2.1 platform?



Yes. Fresh 4.2.1 doesn't have the problem, fresh 4.3 RC8 has the 
problem.


HTH
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Differences between 4.3 and 4.3-forward

[Mike Tutkowski]

Yes, and we definitely cannot just take all of 4.3.1 and put it in 4.3 as
many of those changes are intended for 4.3.1 and not 4.3.


On Fri, Mar 14, 2014 at 8:40 AM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:

> Yes - 4.3-forward is unstable branch and should be merged while 4.3 is
> going through RC. It is meant for maintenance release.
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Friday, March 14, 2014 7:36 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Differences between 4.3 and 4.3-forward
>
> Right, I think it's dangerous to sync 4.3.1 to 4.3 because developers
> might have changes in 4.3.1 that are not yet in master.
>
> This is not my situation personally, but I imagine some devs might be in
> this state.
>
>
> On Fri, Mar 14, 2014 at 8:18 AM, Sudha Ponnaganti <
> sudha.ponnaga...@citrix.com> wrote:
>
> > Yes that is my understanding that all of these would go in to next
> > maintenance that is why they are staged in forward branch.
> >
> > -Original Message-
> > From: Paul Angus [mailto:paul.an...@shapeblue.com]
> > Sent: Friday, March 14, 2014 1:38 AM
> > To: dev@cloudstack.apache.org
> > Subject: RE: Differences between 4.3 and 4.3-forward
> >
> > Will these automatically go into 4.3.1, do we know if they've gone
> > into master as well?
> >
> > Otherwise does this mean we have a load of bug fixes which we're not
> > putting into 4.3.0 which could potentially become orphaned in the
> > 4.3-forward branch? (this query may be just my ignorance regarding ACS
> > branching)
> >
> > Regards,
> >
> > Paul Angus
> > Cloud Architect
> > S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
> > paul.an...@shapeblue.com
> >
> > -Original Message-
> > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> > Sent: 12 March 2014 08:29
> > To: 
> > Subject: Differences between 4.3 and 4.3-forward
> >
> > Hey,
> >
> > There is a sizable number of differences between the two branch. Maybe
> > it's time to ditch 4.3-forward and recreate it based on current 4.3?
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > Hugos-MacBook-Pro:cloudstack hugo (4.3-forward)$ git diff --stat
> > 4.3-forward 4.3
> >
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
> >|3 +-
> >
>  
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCertFromLoadBalancerCmd.java
> >  |2 +-
> >  awsapi/pom.xml
> >|2 +-
> >  client/pom.xml
> >|   20 ++-
> >  client/tomcatconf/catalina.properties.in
> >|2 +-
> >  debian/changelog
> >|7 +-
> >  developer/pom.xml
> >   |1 -
> >  engine/components-api/src/com/cloud/template/TemplateManager.java
> >   |9 +-
> >  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> >|   36 +
> >
>  
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
> > |   10 +-
> >
>  
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
> > |2 +-
> >
>  
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
> >   |2 -
> >
>  
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
> >   |   48 +-
> >  engine/storage/integration-test/pom.xml
> >   |5 -
> >
>  
> engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
> >   |8 +-
> >  framework/db/pom.xml
> >|5 -
> >  framework/db/src/com/cloud/utils/db/StaticStrategy.java
> >   |  130 
> > plugins/database/mysql-ha/pom.xml
> >   |   28 
> >  plugins/database/mysql-ha/src/com/cloud/utils/db/StaticStrategy.java
> >|  133 
> >
> plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentService.Designer.cs
> >|2 +-
> >  plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/App.config
> >|7 +-
> >
>  
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
> > |6 +-
> >
>  
> plugins/hypervisors/simulator/src/com/cloud/agent/manager/SimulatorManagerImpl.java
> > |6 +-
> >
> > plugins/hyp

RE: Differences between 4.3 and 4.3-forward

[Sudha Ponnaganti]

Yes - 4.3-forward is unstable branch and should be merged while 4.3 is going 
through RC. It is meant for maintenance release. 

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Friday, March 14, 2014 7:36 AM
To: dev@cloudstack.apache.org
Subject: Re: Differences between 4.3 and 4.3-forward

Right, I think it's dangerous to sync 4.3.1 to 4.3 because developers might 
have changes in 4.3.1 that are not yet in master.

This is not my situation personally, but I imagine some devs might be in this 
state.


On Fri, Mar 14, 2014 at 8:18 AM, Sudha Ponnaganti < 
sudha.ponnaga...@citrix.com> wrote:

> Yes that is my understanding that all of these would go in to next 
> maintenance that is why they are staged in forward branch.
>
> -Original Message-
> From: Paul Angus [mailto:paul.an...@shapeblue.com]
> Sent: Friday, March 14, 2014 1:38 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Differences between 4.3 and 4.3-forward
>
> Will these automatically go into 4.3.1, do we know if they've gone 
> into master as well?
>
> Otherwise does this mean we have a load of bug fixes which we're not 
> putting into 4.3.0 which could potentially become orphaned in the 
> 4.3-forward branch? (this query may be just my ignorance regarding ACS
> branching)
>
> Regards,
>
> Paul Angus
> Cloud Architect
> S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus 
> paul.an...@shapeblue.com
>
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: 12 March 2014 08:29
> To: 
> Subject: Differences between 4.3 and 4.3-forward
>
> Hey,
>
> There is a sizable number of differences between the two branch. Maybe 
> it's time to ditch 4.3-forward and recreate it based on current 4.3?
>
> Cheers,
>
> Hugo
>
>
> Hugos-MacBook-Pro:cloudstack hugo (4.3-forward)$ git diff --stat 
> 4.3-forward 4.3  
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
>|3 +-
>  
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCertFromLoadBalancerCmd.java
>  |2 +-
>  awsapi/pom.xml
>|2 +-
>  client/pom.xml
>|   20 ++-
>  client/tomcatconf/catalina.properties.in
>|2 +-
>  debian/changelog
>|7 +-
>  developer/pom.xml
>   |1 -
>  engine/components-api/src/com/cloud/template/TemplateManager.java
>   |9 +-
>  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>|   36 +
>  
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
> |   10 +-
>  
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
> |2 +-
>  
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>   |2 -
>  
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>   |   48 +-
>  engine/storage/integration-test/pom.xml
>   |5 -
>  
> engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
>   |8 +-
>  framework/db/pom.xml
>|5 -
>  framework/db/src/com/cloud/utils/db/StaticStrategy.java
>   |  130   
> plugins/database/mysql-ha/pom.xml
>   |   28 
>  plugins/database/mysql-ha/src/com/cloud/utils/db/StaticStrategy.java
>|  133   
> plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentService.Designer.cs
>|2 +-
>  plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/App.config
>|7 +-
>  
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
> |6 +-
>  
> plugins/hypervisors/simulator/src/com/cloud/agent/manager/SimulatorManagerImpl.java
> |6 +-
>  
> plugins/hypervisors/simulator/src/org/apache/cloudstack/storage/datast
> ore/driver/SimulatorImageStoreDriverImpl.java
> |6 -
>  
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
>   |   85 +-
>  
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/discoverer/XcpServerDiscoverer.java
>|7 +-
>  
> plugins/hypervisors/xen/src/com/c

Re: 4.4 Feature Freeze

[Marcus]

It may even just be a behavioral change or something simple I missed
that is now required with a recent check-in. Obviously I don't feel
comfortable merging in my feature branch though when I pull from
master and can no longer run my own feature tests.

On Fri, Mar 14, 2014 at 8:35 AM, Marcus  wrote:
> I'm not sure what the offending ones are at the moment, and there was
> recently a  feature merge that was not squashed, so it might be a little
> difficult to weed through.
>
> On Mar 14, 2014 7:45 AM, "Sudha Ponnaganti" 
> wrote:
>>
>> Can the offending check-ins be reverted or master be blocked for further
>> check-ins till blocking issue is fixed.
>> Talluri is running BVTs and can that be taken as basic passing criteria to
>> re-enable check-ins.
>>
>> -Original Message-
>> From: Marcus [mailto:shadow...@gmail.com]
>> Sent: Friday, March 14, 2014 6:36 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.4 Feature Freeze
>>
>> Will be doing it today, however it seems that there have been some new
>> issues that have cropped up in master that break basic functionality.
>> I'm not sure if anyone should merge or not while that is the case.  I was
>> attempting to validate that the latest merges played well in my branch, but
>> I couldn't even get a vm running with the current master, and I see that
>> while I was sleeping others have reported some of the issues I was seeing as
>> well.
>>
>> On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
>> > On 11.03.2014 15:28, Hugo Trippaers wrote:
>> >>
>> >> Hey guys,
>> >>
>> >> I didn't go and tally all the +1s and -1s for the shift of the
>> >> feature freeze, but with so many reactions i feel sticking to the
>> >> schedule is the only way to go. We should only change dates if there
>> >> is a consensus and there clearly is none at the moment. Let's take
>> >> this discussion to the 4.5 release if we need to or focus on doing a
>> >> high quality release for 4.4 so we can focus on features again in 4.4
>> >>
>> >> This means that the feature freeze would be this friday and i intend
>> >> to cut the 4.4 branch around 14:00 CET
>> >>
>> >> As we have a 72 hour window for MERGE requests, please make sure they
>> >> are in today (if the feature is ready).
>> >>
>> >>
>> >> Cheers,
>> >>
>> >> Hugo
>> >
>> >
>> > Can someone confirm if this has made it in?
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>> >
>> > Marcus requested the MERGE a couple of days ago.
>> > http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
>> >
>> > Lucian
>> >
>> > --
>> > Sent from the Delta quadrant using Borg technology!
>> >
>> > Nux!
>> > www.nux.ro

Re: Differences between 4.3 and 4.3-forward

[Mike Tutkowski]

Right, I think it's dangerous to sync 4.3.1 to 4.3 because developers might
have changes in 4.3.1 that are not yet in master.

This is not my situation personally, but I imagine some devs might be in
this state.


On Fri, Mar 14, 2014 at 8:18 AM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:

> Yes that is my understanding that all of these would go in to next
> maintenance that is why they are staged in forward branch.
>
> -Original Message-
> From: Paul Angus [mailto:paul.an...@shapeblue.com]
> Sent: Friday, March 14, 2014 1:38 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Differences between 4.3 and 4.3-forward
>
> Will these automatically go into 4.3.1, do we know if they've gone into
> master as well?
>
> Otherwise does this mean we have a load of bug fixes which we're not
> putting into 4.3.0 which could potentially become orphaned in the
> 4.3-forward branch? (this query may be just my ignorance regarding ACS
> branching)
>
> Regards,
>
> Paul Angus
> Cloud Architect
> S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
> paul.an...@shapeblue.com
>
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: 12 March 2014 08:29
> To: 
> Subject: Differences between 4.3 and 4.3-forward
>
> Hey,
>
> There is a sizable number of differences between the two branch. Maybe
> it's time to ditch 4.3-forward and recreate it based on current 4.3?
>
> Cheers,
>
> Hugo
>
>
> Hugos-MacBook-Pro:cloudstack hugo (4.3-forward)$ git diff --stat
> 4.3-forward 4.3
>  
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
>|3 +-
>  
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCertFromLoadBalancerCmd.java
>  |2 +-
>  awsapi/pom.xml
>|2 +-
>  client/pom.xml
>|   20 ++-
>  client/tomcatconf/catalina.properties.in
>|2 +-
>  debian/changelog
>|7 +-
>  developer/pom.xml
>   |1 -
>  engine/components-api/src/com/cloud/template/TemplateManager.java
>   |9 +-
>  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>|   36 +
>  
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
> |   10 +-
>  
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
> |2 +-
>  
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>   |2 -
>  
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>   |   48 +-
>  engine/storage/integration-test/pom.xml
>   |5 -
>  
> engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
>   |8 +-
>  framework/db/pom.xml
>|5 -
>  framework/db/src/com/cloud/utils/db/StaticStrategy.java
>   |  130 
>  plugins/database/mysql-ha/pom.xml
>   |   28 
>  plugins/database/mysql-ha/src/com/cloud/utils/db/StaticStrategy.java
>|  133 
>  
> plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentService.Designer.cs
>|2 +-
>  plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/App.config
>|7 +-
>  
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
> |6 +-
>  
> plugins/hypervisors/simulator/src/com/cloud/agent/manager/SimulatorManagerImpl.java
> |6 +-
>  
> plugins/hypervisors/simulator/src/org/apache/cloudstack/storage/datastore/driver/SimulatorImageStoreDriverImpl.java
> |6 -
>  
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
>   |   85 +-
>  
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/discoverer/XcpServerDiscoverer.java
>|7 +-
>  
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>   |   70 +++--
>  
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XcpOssResource.java
>   |5 +
>  
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerConnectionPool.java
>  

RE: 4.4 Feature Freeze

[Marcus]

I'm not sure what the offending ones are at the moment, and there was
recently a  feature merge that was not squashed, so it might be a little
difficult to weed through.
On Mar 14, 2014 7:45 AM, "Sudha Ponnaganti" 
wrote:

> Can the offending check-ins be reverted or master be blocked for further
> check-ins till blocking issue is fixed.
> Talluri is running BVTs and can that be taken as basic passing criteria to
> re-enable check-ins.
>
> -Original Message-
> From: Marcus [mailto:shadow...@gmail.com]
> Sent: Friday, March 14, 2014 6:36 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.4 Feature Freeze
>
> Will be doing it today, however it seems that there have been some new
> issues that have cropped up in master that break basic functionality.
> I'm not sure if anyone should merge or not while that is the case.  I was
> attempting to validate that the latest merges played well in my branch, but
> I couldn't even get a vm running with the current master, and I see that
> while I was sleeping others have reported some of the issues I was seeing
> as well.
>
> On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
> > On 11.03.2014 15:28, Hugo Trippaers wrote:
> >>
> >> Hey guys,
> >>
> >> I didn't go and tally all the +1s and -1s for the shift of the
> >> feature freeze, but with so many reactions i feel sticking to the
> >> schedule is the only way to go. We should only change dates if there
> >> is a consensus and there clearly is none at the moment. Let's take
> >> this discussion to the 4.5 release if we need to or focus on doing a
> >> high quality release for 4.4 so we can focus on features again in 4.4
> >>
> >> This means that the feature freeze would be this friday and i intend
> >> to cut the 4.4 branch around 14:00 CET
> >>
> >> As we have a 72 hour window for MERGE requests, please make sure they
> >> are in today (if the feature is ready).
> >>
> >>
> >> Cheers,
> >>
> >> Hugo
> >
> >
> > Can someone confirm if this has made it in?
> > https://issues.apache.org/jira/browse/CLOUDSTACK-6181
> >
> > Marcus requested the MERGE a couple of days ago.
> > http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
>

Re: Review Request 19021: Cloudbyte Elastistor storage plug-in

[Mike Tutkowski]

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

Ship it!


Ship It!

- Mike Tutkowski


On March 13, 2014, 9:16 a.m., punith s wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19021/
> ---
> 
> (Updated March 13, 2014, 9:16 a.m.)
> 
> 
> Review request for cloudstack, edison su and Mike Tutkowski.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch implements a basic storage plug-in for cloudbyte elastistor 
> v1.3.0, The plug-in is a new feature for cloudstack 4.4 and above.
> 
> this does not implement managed storage yet, it is been integrated only with 
> CreateStoragePool and DeleteStoragePool api's.
> 
> the desired behavior of the plugin are:
> 
> * Allow an Admin to create a primary storage at cluster level, hence creates 
> a volume in elastistor and gets attached to the host with the given 
> capacityiops and capacitybytes through CreateStoragePool api with provider 
> being elastistor.
> 
> *Allow an admin to delete a primary storage at cluster level, hence it 
> deletes the volume from host in cloudstack and deletes the respective volume 
> in elastistor.
> 
> * volume and datadisks fuctions performs the default storage fuctions, ie. 
> the driver extends the CloudStackPrimaryDataStoreDriverImpl.
> 
> * support for both nfs and icsci primary storage.
> 
> 
> Diffs
> -
> 
>   client/pom.xml af724b1 
>   plugins/pom.xml 097f224 
>   plugins/storage/volume/cloudbyte/pom.xml PRE-CREATION 
>   
> plugins/storage/volume/cloudbyte/resources/META-INF/cloudstack/storage-volume-cloudbyte/module.properties
>  PRE-CREATION 
>   
> plugins/storage/volume/cloudbyte/resources/META-INF/cloudstack/storage-volume-cloudbyte/spring-storage-volume-cloudbyte-context.xml
>  PRE-CREATION 
>   
> plugins/storage/volume/cloudbyte/src/org/apache/cloudstack/storage/datastore/driver/ElastistorPrimaryDataStoreDriver.java
>  PRE-CREATION 
>   
> plugins/storage/volume/cloudbyte/src/org/apache/cloudstack/storage/datastore/lifecycle/ElastistorPrimaryDataStoreLifeCycle.java
>  PRE-CREATION 
>   
> plugins/storage/volume/cloudbyte/src/org/apache/cloudstack/storage/datastore/provider/ElastistorHostListener.java
>  PRE-CREATION 
>   
> plugins/storage/volume/cloudbyte/src/org/apache/cloudstack/storage/datastore/provider/ElastistorPrimaryDataStoreProvider.java
>  PRE-CREATION 
>   
> plugins/storage/volume/cloudbyte/src/org/apache/cloudstack/storage/datastore/util/ElastistorUtil.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/19021/diff/
> 
> 
> Testing
> ---
> 
> Build test using, 
> 
> mvn -P developer,systemvm clean install, which is successful.
> 
> Manual testing has been performed using cloudmonkey.
> 
> * Creating a primary storage based on cloudbyte storage plugin.
> 
> cloudmonkey# create storagepool scope=cluster 
> zoneid=dac7223c-6d09-4dcb-82fb-bdecf7c657f5 
> podid=20a613c4-eccf-4fdc-b8ca-c51df483326f 
> clusterid=9a89bc12-bf00-496b-b1d8-8e92cdf1795f name=cloudbytevolume 
> provider=elastistor url=nfs://10.10.171.137/cloudbytetest capacityiops=500 
> capacitybytes=214748364800 tags=cloudbytetest
> storagepool:
> name = cloudbytevolume
> id = 57f70aa4-659b-3b53-b8ab-2f712474f107
> capacityiops = 500
> clusterid = 9a89bc12-bf00-496b-b1d8-8e92cdf1795f
> clustername = test000
> created = 2014-03-11T12:42:38+0530
> disksizeallocated = 0
> disksizetotal = 214748364800
> hypervisor = Any
> ipaddress = 10.10.171.137
> path = /cloudbytetest
> podid = 20a613c4-eccf-4fdc-b8ca-c51df483326f
> podname = test00
> scope = CLUSTER
> state = Up
> tags = cloudbytetest
> type = NetworkFilesystem
> zoneid = dac7223c-6d09-4dcb-82fb-bdecf7c657f5
> zonename = DevCloud0
> 
> * Deleting the primary storage based on cloudbyte storage plugin.
> 
> cloudmonkey# delete storagepool id=57f70aa4-659b-3b53-b8ab-2f712474f107
> success = true
> 
> * creation of primary storage with negative capacityiops throws an exception.
> 
> * creation of primary storage with already available name and ip throws an 
> exception.
> 
> * if the elastistor params which are required for plugin configuration are 
> not injected through spring-storage-volume-cloudbyte-context.xml, it can be 
> set from details map.
> 
> cloudmonkey# create storagepool scope=cluster 
> zoneid=afacc706-3f4d-4f50-82e6-bf0f82959ba8 
> podid=821ad540-6c98-43f3-935d-72a47a319b20 
> clusterid=e0ced156-532e-4941-99c0-f34ff1727544 name=nfsvol 
> provider=elastistor url=nfs://10.10.171.143/volnfs 
> details[0].esaccountid=9e9f67d5-e06f-4d63-a0b8-e7255cba84b8 
> details[1].espoolid=d2d15d11-0f06-3426-a097-3e6e8b36f85c 
> details[2].esdefaultgateway=10.10.1.1 details[3].essubnet=8  
> details[4].estntint

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Wei ZHOU]

Nux and Ove,

Did you test on fresh 4.2.1 platform?

-Wei


2014-03-14 15:07 GMT+01:00 Nux! :

> On 14.03.2014 13:59, Wei ZHOU wrote:
>
>> Is this similar to CLOUDSTACK-5144?
>>
>
> Yes, but it's only exhibited on KVM.
> My colleague who is testing 4.3 with Xenserver is reporting the SG rules
> work as expected (though ipset update still requires VM stop/start).
>
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

Re: [CS4.1] Error during ip range creation

[nicolas.lamirault]

any idea ?

Le 13/03/2014 16:55, nicolas.lamira...@orange.com a écrit :

Yes :

mysql> select * from vlan where vlan_gateway = '10.200.244.129' and
vlan_netmask = '255.255.255.192' ;
+-+-++-+---++++--+-+-+--+---+
| id  | vlan_id | vlan_gateway   | vlan_netmask| description
 | vlan_type  | data_center_id | network_id | uuid
| physical_network_id | ip6_gateway |
ip6_cidr | ip6_range |
+-+-++-+---++++--+-+-+--+---+
| 114 | 2046| 10.200.244.129 | 255.255.255.192 |
10.200.244.187-10.200.244.190 | DirectAttached |  1 |
   335 | 9339bbfb-c6e0-43b8-94e1-3b1c0b15d3ed | 200 |
NULL| NULL | NULL  |
| 117 | 2046| 10.200.244.129 | 255.255.255.192 |
10.200.244.187-10.200.244.190 | DirectAttached |  3 |
   338 | e39717b8-913b-44ba-85cb-449ad5cd8c9a | 202 |
NULL| NULL | NULL  |
| 141 | 2037| 10.200.244.129 | 255.255.255.192 |
10.200.244.154-10.200.244.158 | DirectAttached |  1 |
   365 | 658b4dbd-295e-4083-9ab2-6a73b324c21a | 200 |
NULL| NULL | NULL  |
| 144 | 2037| 10.200.244.129 | 255.255.255.192 |
10.200.244.186-10.200.244.190 | DirectAttached |  3 |
   368 | d91846f5-a5c7-40f6-9d59-0a2bc04563c2 | 202 |
NULL| NULL | NULL  |
| 172 | 2013| 10.200.244.129 | 255.255.255.192 |
10.200.244.185-10.200.244.190 | DirectAttached |  1 |
   396 | f7bd1314-5376-4fa5-b131-89fc37ea480d | 200 |
NULL| NULL | NULL  |
| 182 | 2013| 10.200.244.129 | 255.255.255.192 |
10.200.244.128-10.200.244.128 | DirectAttached |  1 |
   408 | 8c72cad9-2305-4105-8c26-17cc81af82c9 | 200 |
NULL| NULL | NULL  |
+-+-++-+---++++--+-+-+--+---+

and networks associated :

mysql> select * from networks where id in (335,338,365,396,408);
+-+--+--+--+---+---++---+--+-+-++---+-+-+---++--+--+---+++-++-+-+--+--+---+--++-+--+
| id  | name | display_text | traffic_type |
broadcast_domain_type | broadcast_uri | gateway| cidr
 | mode | network_offering_id | physical_network_id | data_center_id
| guru_name | state   | related | domain_id | account_id | dns1
| dns2 | guru_data | set_fields | guest_type | network_domain  |
reservation_id | created | removed | uuid
| restart_required | specify_ip_ranges |
acl_type | vpc_id | ip6_gateway | ip6_cidr |
+-+--+--+--+---+---++---+--+-+-++---+-+-+---++--+--+---+++-++-+-+--+--+---+--++-+--+
| 335 | PRS_ITG-ADMIN| PRS_ITG-ADMIN| Guest| Vlan
 | vlan://2046   | 10.200.244.129 | 10.200.244.128/26 | Dhcp
|   7 | 200 |  1 |
DirectNetworkGuru | Destroy | 335 | 1 |  1 | NULL |
NULL | NULL  |  0 | Shared | admin-dev.cloud.mbs | NULL
| 2014-01-13 15:43:35 | 2014-03-05 11:26:26 |
8ef8ae2b-c563-40ce-9255-cce3f7728e98 |0 |
1 | Domain   |   NULL | NULL| NULL |
| 338 | PRS_ITG-ADMIN| PRS_ITG-ADMIN| Guest| Vlan
 | vlan://2046   | 10.200.244.129 | 10.200.244.128/26 | Dhcp
|   7 | 202 |  3 |
DirectNetworkGuru | Destroy | 338 | 1 |  1 | NULL |
NULL | NULL  |  0 | Shared | admin-dev.cloud.mbs | NULL
| 2014-

RE: Differences between 4.3 and 4.3-forward

[Sudha Ponnaganti]

Yes that is my understanding that all of these would go in to next maintenance 
that is why they are staged in forward branch. 

-Original Message-
From: Paul Angus [mailto:paul.an...@shapeblue.com] 
Sent: Friday, March 14, 2014 1:38 AM
To: dev@cloudstack.apache.org
Subject: RE: Differences between 4.3 and 4.3-forward

Will these automatically go into 4.3.1, do we know if they've gone into master 
as well?

Otherwise does this mean we have a load of bug fixes which we're not putting 
into 4.3.0 which could potentially become orphaned in the 4.3-forward branch? 
(this query may be just my ignorance regarding ACS branching)

Regards,

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus 
paul.an...@shapeblue.com

-Original Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: 12 March 2014 08:29
To: 
Subject: Differences between 4.3 and 4.3-forward

Hey,

There is a sizable number of differences between the two branch. Maybe it's 
time to ditch 4.3-forward and recreate it based on current 4.3?

Cheers,

Hugo


Hugos-MacBook-Pro:cloudstack hugo (4.3-forward)$ git diff --stat 4.3-forward 4.3
 
api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignCertToLoadBalancerCmd.java
|3 +-
 
api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveCertFromLoadBalancerCmd.java
  |2 +-
 awsapi/pom.xml 
 |2 +-
 client/pom.xml 
 |   20 ++-
 client/tomcatconf/catalina.properties.in   
 |2 +-
 debian/changelog   
 |7 +-
 developer/pom.xml  
 |1 -
 engine/components-api/src/com/cloud/template/TemplateManager.java  
 |9 +-
 engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java   
 |   36 +
 
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 |   10 +-
 
engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
 |2 +-
 
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
   |2 -
 
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
   |   48 +-
 engine/storage/integration-test/pom.xml
 |5 -
 
engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
   |8 +-
 framework/db/pom.xml   
 |5 -
 framework/db/src/com/cloud/utils/db/StaticStrategy.java
 |  130 
 plugins/database/mysql-ha/pom.xml  
 |   28 
 plugins/database/mysql-ha/src/com/cloud/utils/db/StaticStrategy.java   
 |  133 
 
plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/AgentService.Designer.cs
|2 +-
 plugins/hypervisors/hyperv/DotNet/ServerResource/AgentShell/App.config 
 |7 +-
 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 |6 +-
 
plugins/hypervisors/simulator/src/com/cloud/agent/manager/SimulatorManagerImpl.java
 |6 +-
 
plugins/hypervisors/simulator/src/org/apache/cloudstack/storage/datastore/driver/SimulatorImageStoreDriverImpl.java
 |6 -
 
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
   |   85 +-
 
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/discoverer/XcpServerDiscoverer.java
|7 +-
 
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
   |   70 +++--
 
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XcpOssResource.java
   |5 +
 
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerConnectionPool.java
  |  452 

Re: Review Request 18964: Windowsfication of CloudStack Management Server - Changes to support windows OS

[daan Hoogland]

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



server/src/com/cloud/server/ConfigurationServerImpl.java


please move this to a private function so it can be mocked from a test.


- daan Hoogland


On March 14, 2014, 12:10 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18964/
> ---
> 
> (Updated March 14, 2014, 12:10 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Chiradeep Vittal, daan 
> Hoogland, and Donal Lafferty.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-6105
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-6105
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Windowsfication of CloudStack Management Server
> 
> 
> Diffs
> -
> 
>   scripts/installer/windows/acs.wxs PRE-CREATION 
>   scripts/installer/windows/client.wxs PRE-CREATION 
>   scripts/installer/windows/start.bat PRE-CREATION 
>   scripts/vm/systemvm/injectkeys.py PRE-CREATION 
>   server/src/com/cloud/server/ConfigurationServerImpl.java b8da4c8 
> 
> Diff: https://reviews.apache.org/r/18964/diff/
> 
> 
> Testing
> ---
> 
> Tested in Linux environment after changes 
> Also tested in Windows environment(For now tested on windows-8) to make sure 
> it is getting installed and management service is running.
> 
> Able to add zones, able to register templates, able to launch a VM when it is 
> running on windows.
> 
> Currently though it is getting added as a windows service, not able to start 
> the service through windows service control manager which I am looking into 
> currently. When run .exe file which is installed then server is getting up 
> and able to access cloud stack UI. 
> 
> For now The following assumptions are made:
> 1. SSH keys are already installed
> 2. JAVA is already installed
> 3. tomcat is already installed
> 
> This patch contains the following new files related to WiX tool (To compile 
> and run we need this tool)
> 1. acs.wxs
> The following command will be used to compile
>   "\bin\candle.exe" acs.wxs
> 2. client.wxs
> The following command will be used to generate the above file
>   "\bin\heat" dir client -gg -cg Test  -ke -sfrag 
> -template fragment -out client.wxs  -var wix.SourceClient -dr WEBAPPS
> The following command will be used to compile the above generated file
>   "\bin\candle.exe" client.wxs
> 3. The following command will be used to generate .msi file
>   "\bin\light.exe" acs.wixobj client.wixobj -out 
> acs.msi  -ext "C:\Program Files (x86)\WiX Toolset 
> v3.8\bin\WixUIExtension.dll" -dSourceClient=SourceDir\client
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 13:59, Wei ZHOU wrote:

Is this similar to CLOUDSTACK-5144?


Yes, but it's only exhibited on KVM.
My colleague who is testing 4.3 with Xenserver is reporting the SG 
rules work as expected (though ipset update still requires VM 
stop/start).


Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Jenkins build is back to normal : cloudstack-4.4-maven-build #2

[jenkins]

See 

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 13.03.2014 18:58, Nux! wrote:

On 13.03.2014 00:26, Animesh Chaturvedi wrote:

Hi All,


I've created a 4.3.0 release, with the following artifacts up for a
vote:


-1

In Adv SG zone assigning secondary IPs to a NIC doesn't update the
ipset accordingly on the agent/hv; it requires stopping/starting the
VM.
It's not a tragedy, but this was not the case in 4.2.1. Haven't
checked basic zone.

A quick fix for it anyone?



I have opened https://issues.apache.org/jira/browse/CLOUDSTACK-6240 for 
the ipset issue.



Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Build failed in Jenkins: build-master-slowbuild #428

[jenkins]

See 

Changes:

[koushik] CLOUDSTACK-6090: Virtual Router Service Failure Alerting

[Devdeep Singh] CLOUDSTACK-6143: Storage motion support for hyper-v. With these 
changes a volume on a shared

[muralimmreddy] -introduces 'DistributedRouter' as capability to 'Connectivity' 
service.

[muralimmreddy] -add check to ensure 'Connectivity' service provider specified 
in

[muralimmreddy] mark VPC to be using distributed router if VPC offerign supports

[muralimmreddy] make Ovs as VPC provider

[muralimmreddy] Scripts that use ovs-vsctl and ovs-ofctl to setup a bridge for 
VPC in

[muralimmreddy] introduce OvsNetworkTopologyGuru that has convinenace functions 
to

[muralimmreddy] some bug fixes

[muralimmreddy] adds hypervisor script to convert JSON routing polcies (ACL) 
config in

[muralimmreddy] adding distributed routing support for KVM OVS

[muralimmreddy] integration tests for VPC's enabled for distributed routing

[muralimmreddy] couple of bug fixes

[muralimmreddy] findbug fixes, added some comments, bug fixes

[muralimmreddy] fix RAT check failure

[muralimmreddy] findbug fixes

[muralimmreddy] fix unit-test failure

[rajesh.battala] CLOUDSTACK-6106 supporting VPC VR on Hyper-V

[rajesh.battala] CLOUDSTACK-6106 Agent side changes for VPC on Hyper-V

[rajesh.battala] Fixed all findbugs in hyperv plugin code

[sateesh] CLOUDSTACK-6092: Storage OverProvisioning as a Per Primary Basis 
Allow storage.overprovisioning.factor to be specified at storape pool level.

--
[...truncated 18044 lines...]

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-awsapi <<<
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cloud-awsapi ---
[INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/amazon/ec2/AmazonEC2SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/amazon/s3/AmazonS3SkeletonInterface.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SAcl.java.  Ensure this class was instrumented, and this 
data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SBucket.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/model/SHost.java.  Ensure this class was instrumented, and 
this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/BucketPolicyDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackAccountDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java.  Ensure this 
class was instrumented, and this data file contains the instrumentation 
information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java.  Ensure this class 
was instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not contain instrumentation information for the file 
com/cloud/bridge/persist/dao/CloudStackUserDao.java.  Ensure this class was 
instrumented, and this data file contains the instrumentation information.
[cobertura] INFO  [main] net.sourceforge.cobertura.reporting.html.HTMLReport - 
Data file does not co

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Wei ZHOU]

Is this similar to CLOUDSTACK-5144?


2014-03-14 14:57 GMT+01:00 Wei ZHOU :

> Did you test on fresh 4.2.1, or upgraded platform?
>
>

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Wei ZHOU]

Did you test on fresh 4.2.1, or upgraded platform?


2014-03-14 14:51 GMT+01:00 Ove Ewerlid :

> It should be noted that my tests use a single IP per VM.
> I believe NUX mentioned using multiple IP's.
> When SG in advanced zone is enabled, only one NIC can be assigned per VM.
> /Ove
>
>
> On 03/14/2014 02:41 PM, Ove Ewerlid wrote:
>
>> On 03/14/2014 01:57 PM, Nux! wrote:
>>
>>> On 14.03.2014 12:06, Nux! wrote:
>>>
 It looks like the traffic doesn't go in the right chains, all traffic
 is accepted as FORWARD is set to ACCEPT.
 There are zero packets going through BF-breth0-109.

 Here's outputs from:
 iptables-save: http://paste.fedoraproject.org/85337/47982321/raw/
 ebatables-save: http://paste.fedoraproject.org/85338/79831713/raw/
 ipset -L: http://paste.fedoraproject.org/85339/79832613/raw/

 I will install 4.2.1 as that one was working and try to compare the
 outputs.

>>>
>>> Ok, reinstalled with 4.2.1 and this one works as expected, all ingress
>>> is blocked unless stated otherwise. Here's the same outputs as earlier:
>>> iptables http://paste.fedoraproject.org/85350/1356139/raw/
>>> ebtables http://paste.fedoraproject.org/85351/80136613/raw/
>>> ipset -L http://paste.fedoraproject.org/85352/13948013/raw/
>>>
>>> Kindly look into this, it breaks a major feature.
>>>
>>> Lucian
>>>
>>>
>> I can confirm this observation.
>> The test was to install ACS42 and ACS43 in the same environment;
>>
>>- OEL65 (Oracle's variant of CentOS v65)
>>- KVM hypervisor
>>- Advanced with 3 shared networks (3 VLAN's)
>>- ACS421; official KVM system VM template
>>- ACS43; latest 64 bit KVM system VM template
>>- 24 hypervisors; 144Gbyte RAM / 24 Cores / 4TB local disk
>>
>> SG works as expected in ACS42.
>> In ACS43, the iptables forward chain on hypervisors is empty and in
>> policy ACCEPT, hence all traffic goes through.
>>
>> The same set of automated install scripts were used in both cases so the
>> installs are virtually identical.
>>
>> /Ove
>>
>>
>>
>
> --
> Ove Everlid
> System Administrator / Architect / SDN- & Automation- & Linux-hacker
> Mobile: +46706662363 (dedicated work mobile)
> Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)
>

Re: Review Request 19036: CLOUDSTACK-6092: Storage OverProvisioning as a Per Primary Basis

[ASF Subversion and Git Services]

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


Commit 48f8a95b06b0348ba1349cb5434183c2c18710db in cloudstack's branch 
refs/heads/4.4 from Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=48f8a95 ]

CLOUDSTACK-6092: Storage OverProvisioning as a Per Primary Basis Allow 
storage.overprovisioning.factor to be specified at storape pool level.

Signed-off-by: Sateesh Chodapuneedi 


- ASF Subversion and Git Services


On March 14, 2014, 12:10 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19036/
> ---
> 
> (Updated March 14, 2014, 12:10 p.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh, Likitha Shetty, Rajesh Battala, 
> and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-6092
> https://issues.apache.org/jira/browse/CLOUDSTACK-6092
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The feature allows CloudStack admins to define over-provisioning for 
> individual primary data storages. This will eliminate the tight dependency 
> over the global parameter to leverage underlying overprovisioning.
> admin can update an existing primary store by setting overprovisioning in the 
> per primary setting.
> This value will override the value at the global level. To fall back to the 
> global value, null value can be passed.
> Added overprovisioning as a part of Storage Pool response.
> Currently limited to NFS and VMFS data stores.
> Appropriate logs added to inform about capacity calculations.
> Upgraded setup will migrate the data from data_center_details table to 
> storage_pool_details
> FS : 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+OverProvisioning+as+Per+Primary+Basis
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 03a4f34 
>   engine/components-api/src/com/cloud/capacity/CapacityManager.java bd1a610 
>   server/src/com/cloud/api/query/dao/StoragePoolJoinDaoImpl.java 274bf1c 
>   server/src/com/cloud/capacity/StorageCapacityListener.java 4322ecf 
>   server/src/com/cloud/storage/StorageManagerImpl.java 913dc23 
>   setup/db/db/schema-430to440.sql 9298f72 
>   test/integration/smoke/test_over_provisioning.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/19036/diff/
> 
> 
> Testing
> ---
> 
> Build passes successfully.
> Rat build for the new file passes.
> Patch applies cleanly.
> 
> The following scenarios tested:
> setting and resetting of the overprovision factor.
> setting the factor to null
> adding new data stores
> capacity calculations
> 
> New Marvin test: test_over_provisioning.py added
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Build failed in Jenkins: cloudstack-4.4-maven-build #1

[jenkins]

See 

--
[...truncated 60 lines...]
[INFO] Apache CloudStack Plugin - Host Allocator Random
[INFO] Apache CloudStack Plugin - Dedicated Resources
[INFO] Apache CloudStack Plugin - Hypervisor OracleVM
[INFO] Apache CloudStack Plugin - Open vSwitch
[INFO] Apache CloudStack Plugin - Hypervisor Xen
[INFO] Apache CloudStack Plugin - Hypervisor KVM
[INFO] Apache CloudStack Plugin - RabbitMQ Event Bus
[INFO] Apache CloudStack Plugin - In Memory Event Bus
[INFO] Apache CloudStack Plugin - Hypervisor Baremetal
[INFO] Apache CloudStack Plugin - Hypervisor UCS
[INFO] Apache CloudStack Plugin - Hypervisor Hyper-V
[INFO] Apache CloudStack Plugin - Network Elastic Load Balancer
[INFO] Apache CloudStack Plugin - Network Internal Load Balancer
[INFO] Apache CloudStack Framework - Spring Life Cycle
[INFO] Apache CloudStack Plugin - Network Juniper Contrail
[INFO] Apache CloudStack Plugin - Palo Alto
[INFO] Apache CloudStack Plugin - Network Netscaler
[INFO] Apache CloudStack Plugin - Network Nicira NVP
[INFO] Apache CloudStack Plugin - BigSwitch Virtual Network Segment
[INFO] Apache CloudStack Plugin - Midokura Midonet
[INFO] Apache CloudStack Plugin - Stratosphere SSP
[INFO] Apache CloudStack Plugin - Network Opendaylight
[INFO] Apache CloudStack Plugin - Storage Allocator Random
[INFO] Apache CloudStack Plugin - User Authenticator LDAP
[INFO] Apache CloudStack Plugin - User Authenticator MD5
[INFO] Apache CloudStack Plugin - User Authenticator Plain Text
[INFO] Apache CloudStack Plugin - User Authenticator SHA256 Salted
[INFO] Apache CloudStack Plugin - Dns Notifier Example
[INFO] Apache CloudStack Plugin - Storage Image S3
[INFO] Apache CloudStack Plugin - Storage Image Swift provider
[INFO] Apache CloudStack Plugin - Storage Image default provider
[INFO] Apache CloudStack Plugin - Storage Image sample provider
[INFO] Apache CloudStack Plugin - Storage Volume Nexenta Provider
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider
[INFO] Apache CloudStack Plugin - Storage Volume default provider
[INFO] Apache CloudStack Plugin - Storage Volume sample provider
[INFO] Apache CloudStack Plugin - SNMP Alerts
[INFO] Apache CloudStack Plugin - Syslog Alerts
[INFO] Apache CloudStack Plugin - Network VXLAN
[INFO] Apache CloudStack Framework - Spring Module
[INFO] Apache CloudStack Secondary Storage Controller
[INFO] Apache CloudStack Client UI
[INFO] Apache CloudStack Console Proxy - RDP Client
[INFO] Apache CloudStack Console Proxy
[INFO] Apache CloudStack Console Proxy - Server
[INFO] Apache CloudStack IAM Service
[INFO] Apache CloudStack IAM - Server
[INFO] Apache CloudStack IAM - Plugin
[INFO] Apache CloudStack Framework - QuickCloud
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Developer Tools - Checkstyle Configuration 
4.4.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ checkstyle ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
checkstyle ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ checkstyle 
---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
checkstyle ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 

[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
checkstyle ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ checkstyle ---
[INFO] No tests to run.
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack 4.4.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloudstack ---
[INFO] Deleting 
 (includes = 
[target, dist], excludes = [])
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloudstack ---
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Maven Conventions Parent 4.4.0-SNAPSHOT
[INFO] -

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Ove Ewerlid]

It should be noted that my tests use a single IP per VM.
I believe NUX mentioned using multiple IP's.
When SG in advanced zone is enabled, only one NIC can be assigned per VM.
/Ove

On 03/14/2014 02:41 PM, Ove Ewerlid wrote:

On 03/14/2014 01:57 PM, Nux! wrote:

On 14.03.2014 12:06, Nux! wrote:

It looks like the traffic doesn't go in the right chains, all traffic
is accepted as FORWARD is set to ACCEPT.
There are zero packets going through BF-breth0-109.

Here's outputs from:
iptables-save: http://paste.fedoraproject.org/85337/47982321/raw/
ebatables-save: http://paste.fedoraproject.org/85338/79831713/raw/
ipset -L: http://paste.fedoraproject.org/85339/79832613/raw/

I will install 4.2.1 as that one was working and try to compare the
outputs.


Ok, reinstalled with 4.2.1 and this one works as expected, all ingress
is blocked unless stated otherwise. Here's the same outputs as earlier:
iptables http://paste.fedoraproject.org/85350/1356139/raw/
ebtables http://paste.fedoraproject.org/85351/80136613/raw/
ipset -L http://paste.fedoraproject.org/85352/13948013/raw/

Kindly look into this, it breaks a major feature.

Lucian



I can confirm this observation.
The test was to install ACS42 and ACS43 in the same environment;

   - OEL65 (Oracle's variant of CentOS v65)
   - KVM hypervisor
   - Advanced with 3 shared networks (3 VLAN's)
   - ACS421; official KVM system VM template
   - ACS43; latest 64 bit KVM system VM template
   - 24 hypervisors; 144Gbyte RAM / 24 Cores / 4TB local disk

SG works as expected in ACS42.
In ACS43, the iptables forward chain on hypervisors is empty and in
policy ACCEPT, hence all traffic goes through.

The same set of automated install scripts were used in both cases so the
installs are virtually identical.

/Ove





--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706662363 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Ove Ewerlid]

-1 given the regression in Security Groups for advanced zones.
I was able to duplicate NUX reported issues, e.g., works in ACS421 but 
does not work at all in ACS43.


/Ove

On 03/13/2014 01:26 AM, Animesh Chaturvedi wrote:

Hi All,



I've created a 4.3.0 release, with the following artifacts up for a

vote:





Git Branch and Commit SH:

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3
Commit: 6a6ec648099553a42f830dcd566eab2452428908



List of changes:

New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248

Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249

Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161

Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162







Source release (checksums and signatures are available at the same

location):

https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/



PGP release keys (signed using 94BE0D7C):

https://dist.apache.org/repos/dist/release/cloudstack/KEYS



Testing instructions are here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure



Vote will be open for 72 hours (Monday evening PST 5:30 PM)



For sanity in tallying the vote, can PMC members please be sure to indicate 
"(binding)" with their vote?



[ ] +1  approve

[ ] +0  no opinion

[ ] -1  disapprove (and reason why)



Thanks

Animesh





--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706662363 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

RE: 4.4 Feature Freeze

[Sudha Ponnaganti]

Can the offending check-ins be reverted or master be blocked for further 
check-ins till blocking issue is fixed. 
Talluri is running BVTs and can that be taken as basic passing criteria to 
re-enable check-ins. 

-Original Message-
From: Marcus [mailto:shadow...@gmail.com] 
Sent: Friday, March 14, 2014 6:36 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze

Will be doing it today, however it seems that there have been some new issues 
that have cropped up in master that break basic functionality.
I'm not sure if anyone should merge or not while that is the case.  I was 
attempting to validate that the latest merges played well in my branch, but I 
couldn't even get a vm running with the current master, and I see that while I 
was sleeping others have reported some of the issues I was seeing as well.

On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
> On 11.03.2014 15:28, Hugo Trippaers wrote:
>>
>> Hey guys,
>>
>> I didn't go and tally all the +1s and -1s for the shift of the 
>> feature freeze, but with so many reactions i feel sticking to the 
>> schedule is the only way to go. We should only change dates if there 
>> is a consensus and there clearly is none at the moment. Let's take 
>> this discussion to the 4.5 release if we need to or focus on doing a 
>> high quality release for 4.4 so we can focus on features again in 4.4
>>
>> This means that the feature freeze would be this friday and i intend 
>> to cut the 4.4 branch around 14:00 CET
>>
>> As we have a 72 hour window for MERGE requests, please make sure they 
>> are in today (if the feature is ready).
>>
>>
>> Cheers,
>>
>> Hugo
>
>
> Can someone confirm if this has made it in?
> https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>
> Marcus requested the MERGE a couple of days ago.
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro

Re: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Ove Ewerlid]

On 03/14/2014 01:57 PM, Nux! wrote:

On 14.03.2014 12:06, Nux! wrote:

It looks like the traffic doesn't go in the right chains, all traffic
is accepted as FORWARD is set to ACCEPT.
There are zero packets going through BF-breth0-109.

Here's outputs from:
iptables-save: http://paste.fedoraproject.org/85337/47982321/raw/
ebatables-save: http://paste.fedoraproject.org/85338/79831713/raw/
ipset -L: http://paste.fedoraproject.org/85339/79832613/raw/

I will install 4.2.1 as that one was working and try to compare the
outputs.


Ok, reinstalled with 4.2.1 and this one works as expected, all ingress
is blocked unless stated otherwise. Here's the same outputs as earlier:
iptables http://paste.fedoraproject.org/85350/1356139/raw/
ebtables http://paste.fedoraproject.org/85351/80136613/raw/
ipset -L http://paste.fedoraproject.org/85352/13948013/raw/

Kindly look into this, it breaks a major feature.

Lucian



I can confirm this observation.
The test was to install ACS42 and ACS43 in the same environment;

  - OEL65 (Oracle's variant of CentOS v65)
  - KVM hypervisor
  - Advanced with 3 shared networks (3 VLAN's)
  - ACS421; official KVM system VM template
  - ACS43; latest 64 bit KVM system VM template
  - 24 hypervisors; 144Gbyte RAM / 24 Cores / 4TB local disk

SG works as expected in ACS42.
In ACS43, the iptables forward chain on hypervisors is empty and in 
policy ACCEPT, hence all traffic goes through.


The same set of automated install scripts were used in both cases so the 
installs are virtually identical.


/Ove


--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706662363 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

Re: 4.4 Feature Freeze

[Marcus]

Will be doing it today, however it seems that there have been some new
issues that have cropped up in master that break basic functionality.
I'm not sure if anyone should merge or not while that is the case.  I
was attempting to validate that the latest merges played well in my
branch, but I couldn't even get a vm running with the current master,
and I see that while I was sleeping others have reported some of the
issues I was seeing as well.

On Fri, Mar 14, 2014 at 3:43 AM, Nux!  wrote:
> On 11.03.2014 15:28, Hugo Trippaers wrote:
>>
>> Hey guys,
>>
>> I didn't go and tally all the +1s and -1s for the shift of the
>> feature freeze, but with so many reactions i feel sticking to the
>> schedule is the only way to go. We should only change dates if there
>> is a consensus and there clearly is none at the moment. Let's take
>> this discussion to the 4.5 release if we need to or focus on doing a
>> high quality release for 4.4 so we can focus on features again in 4.4
>>
>> This means that the feature freeze would be this friday and i intend
>> to cut the 4.4 branch around 14:00 CET
>>
>> As we have a 72 hour window for MERGE requests, please make sure they
>> are in today (if the feature is ready).
>>
>>
>> Cheers,
>>
>> Hugo
>
>
> Can someone confirm if this has made it in?
> https://issues.apache.org/jira/browse/CLOUDSTACK-6181
>
> Marcus requested the MERGE a couple of days ago.
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg24793.html
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro

Re: Master is broken?

[Srikanteswararao Talluri]

I am seeing another issue on master.
Filed a bug for this
https://issues.apache.org/jira/browse/CLOUDSTACK-6239

Thanks,
~Talluri

On 14/03/14 3:50 pm, "Daan Hoogland"  wrote:

>On Fri, Mar 14, 2014 at 11:08 AM, Antonio Fornié Casarrubios
> wrote:
>> antonio.fornie
>
>
>is in
>
>-- 
>Daan

Re: Review Request 19021: Cloudbyte Elastistor storage plug-in

[Punith S]

hi guys,

i have resolved all issues with fixes and refactoring of plugin code, its
good to go now ,
i'll submit once i get the ship it message. thanks for the review.


On Fri, Mar 14, 2014 at 11:19 AM, punith s  wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19021/
>
> On March 14th, 2014, 3:54 a.m. IST, *Mike Tutkowski* wrote:
>
>
> plugins/storage/volume/cloudbyte/src/org/apache/cloudstack/storage/datastore/lifecycle/ElastistorPrimaryDataStoreLifeCycle.java
>  (Diff
> revision 5)
>
> 99
>
> if(details.get("esaccountid") != null)
>
>   Does this plug-in support multiple CloudByte SANs at the same time?
>
> It looks like whatever values you set most recently for ElastistorUtil will 
> be utilized if you don't provide them in the details. Is this OK if you don't 
> provide all of the details for your second or more SAN?
>
>  yes it will.
>
> yes, we are expecting admin to use cloudmonkey to create storage pool if the 
> elastistor params are not set for the first time.
> once the details are set he can use cloudstack UI to add or deleted storage 
> pools on the same SAN but if he wants to use different SAN
> we are expecting him to use cloudmonkey again to change elastistor params 
> through details map.
>
> thanks.
>
>
>
>
> - punith
>
> On March 13th, 2014, 2:46 p.m. IST, punith s wrote:
>   Review request for cloudstack, edison su and Mike Tutkowski.
> By punith s.
>
> *Updated March 13, 2014, 2:46 p.m.*
>  *Repository: * cloudstack-git
> Description
>
> This patch implements a basic storage plug-in for cloudbyte elastistor 
> v1.3.0, The plug-in is a new feature for cloudstack 4.4 and above.
>
> this does not implement managed storage yet, it is been integrated only with 
> CreateStoragePool and DeleteStoragePool api's.
>
> the desired behavior of the plugin are:
>
> * Allow an Admin to create a primary storage at cluster level, hence creates 
> a volume in elastistor and gets attached to the host with the given 
> capacityiops and capacitybytes through CreateStoragePool api with provider 
> being elastistor.
>
> *Allow an admin to delete a primary storage at cluster level, hence it 
> deletes the volume from host in cloudstack and deletes the respective volume 
> in elastistor.
>
> * volume and datadisks fuctions performs the default storage fuctions, ie. 
> the driver extends the CloudStackPrimaryDataStoreDriverImpl.
>
> * support for both nfs and icsci primary storage.
>
>   Testing
>
> Build test using,
>
> mvn -P developer,systemvm clean install, which is successful.
>
> Manual testing has been performed using cloudmonkey.
>
> * Creating a primary storage based on cloudbyte storage plugin.
>
> cloudmonkey# create storagepool scope=cluster 
> zoneid=dac7223c-6d09-4dcb-82fb-bdecf7c657f5 
> podid=20a613c4-eccf-4fdc-b8ca-c51df483326f 
> clusterid=9a89bc12-bf00-496b-b1d8-8e92cdf1795f name=cloudbytevolume 
> provider=elastistor url=nfs://10.10.171.137/cloudbytetest capacityiops=500 
> capacitybytes=214748364800 tags=cloudbytetest
> storagepool:
> name = cloudbytevolume
> id = 57f70aa4-659b-3b53-b8ab-2f712474f107
> capacityiops = 500
> clusterid = 9a89bc12-bf00-496b-b1d8-8e92cdf1795f
> clustername = test000
> created = 2014-03-11T12:42:38+0530
> disksizeallocated = 0
> disksizetotal = 214748364800
> hypervisor = Any
> ipaddress = 10.10.171.137
> path = /cloudbytetest
> podid = 20a613c4-eccf-4fdc-b8ca-c51df483326f
> podname = test00
> scope = CLUSTER
> state = Up
> tags = cloudbytetest
> type = NetworkFilesystem
> zoneid = dac7223c-6d09-4dcb-82fb-bdecf7c657f5
> zonename = DevCloud0
>
> * Deleting the primary storage based on cloudbyte storage plugin.
>
> cloudmonkey# delete storagepool id=57f70aa4-659b-3b53-b8ab-2f712474f107
> success = true
>
> * creation of primary storage with negative capacityiops throws an exception.
>
> * creation of primary storage with already available name and ip throws an 
> exception.
>
> * if the elastistor params which are required for plugin configuration are 
> not injected through spring-storage-volume-cloudbyte-context.xml, it can be 
> set from details map.
>
> cloudmonkey# create storagepool scope=cluster 
> zoneid=afacc706-3f4d-4f50-82e6-bf0f82959ba8 
> podid=821ad540-6c98-43f3-935d-72a47a319b20 
> clusterid=e0ced156-532e-4941-99c0-f34ff1727544 name=nfsvol 
> provider=elastistor url=nfs://10.10.171.143/volnfs 
> details[0].esaccountid=9e9f67d5-e06f-4d63-a0b8-e7255cba84b8 
> details[1].espoolid=d2d15d11-0f06-3426-a097-3e6e8b36f85c 
> details[2].esdefaultgateway=10.10.1.1 details[3].essubnet=8  
> details[4].estntinterface=em0 details[5].esmanagementip=10.10.171.180
> details[6].esapikey=PubSInZaCji8hrRfOsCxgbug2I2k_sRJ0i2a9qmAzZIiCTcFPmZelzx6uNK9TYgqkdohCmq1L2J9eYmUe9YO6A
>  capacityiops=100 capacitybytes=214748364800
>
> storagepool:
> name = nfsvol
> id = 7ea08bf6-777a-3553-8f1e-c3a9f9b626cb
> capacityiops = 100
> clusterid = e0ce

RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)

[Nux!]

On 14.03.2014 12:06, Nux! wrote:

It looks like the traffic doesn't go in the right chains, all traffic
is accepted as FORWARD is set to ACCEPT.
There are zero packets going through BF-breth0-109.

Here's outputs from:
iptables-save: http://paste.fedoraproject.org/85337/47982321/raw/
ebatables-save: http://paste.fedoraproject.org/85338/79831713/raw/
ipset -L: http://paste.fedoraproject.org/85339/79832613/raw/

I will install 4.2.1 as that one was working and try to compare the 
outputs.


Ok, reinstalled with 4.2.1 and this one works as expected, all ingress 
is blocked unless stated otherwise. Here's the same outputs as earlier:

iptables http://paste.fedoraproject.org/85350/1356139/raw/
ebtables http://paste.fedoraproject.org/85351/80136613/raw/
ipset -L http://paste.fedoraproject.org/85352/13948013/raw/

Kindly look into this, it breaks a major feature.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro