date:20131029



> On Oct. 29, 2013, 4:35 a.m., Toshiaki Hatano wrote:
> >
> 
> Toshiaki Hatano wrote:
> Actual issue is not "the physical interface name length must be shorter 
> than 5" but "generated bridge name cannot exceed 15 character".
>

If we check generated bridge name length, users will not face the exception 
before their cloudstack environment grow up. They will face the exception in 
production environment suddenly.
If we check physical interface name length, users can face the exception 
whenever bridge name length is not enough.


- Yoshikazu


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


On Oct. 29, 2013, 12:51 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15001/
> ---
> 
> (Updated Oct. 29, 2013, 12:51 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Guest network isn't created correctly when vxlan is used for isolation 
> method, VNI is bigger than 1000, and physical network interface name 
> length is longer than 4.
> This patch fix this issue by raising error when long interface name is 
> specified.
> 
> Issue remained: document that physical interface name length must be shorter 
> than 5.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/BridgeVifDriverTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15001/diff/
> 
> 
> Testing
> ---
> 
> I confirmed it passes the unit tests I add.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 15001: CLOUDSTACK-4967: Bugfix: Guest network isn't created correctly in rare case when vxlan is used for isolation method



> On Oct. 29, 2013, 4:35 a.m., Toshiaki Hatano wrote:
> > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java,
> >  line 158
> > 
> >
> > If we checked length here, generated brName should be checked, not a 
> > pifName.
> > 
> > We shouldn't block valid brName by this check, e.g. eth0.1000-9000.
> 
> Toshiaki Hatano wrote:
> s/eth0.1000-9000/breth0.100-9000/

It validates pifName, not brName. It validates pifName in the point of whether 
it is appropriate to be used for generating bridge name here.


- Yoshikazu


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


On Oct. 29, 2013, 12:51 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15001/
> ---
> 
> (Updated Oct. 29, 2013, 12:51 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Guest network isn't created correctly when vxlan is used for isolation 
> method, VNI is bigger than 1000, and physical network interface name 
> length is longer than 4.
> This patch fix this issue by raising error when long interface name is 
> specified.
> 
> Issue remained: document that physical interface name length must be shorter 
> than 5.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/BridgeVifDriverTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15001/diff/
> 
> 
> Testing
> ---
> 
> I confirmed it passes the unit tests I add.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 15001: CLOUDSTACK-4967: Bugfix: Guest network isn't created correctly in rare case when vxlan is used for isolation method

2013-10-29 Thread Toshiaki Hatano



> On Oct. 29, 2013, 4:35 a.m., Toshiaki Hatano wrote:
> >
> 
> Toshiaki Hatano wrote:
> Actual issue is not "the physical interface name length must be shorter 
> than 5" but "generated bridge name cannot exceed 15 character".
>
> 
> Yoshikazu Nojima wrote:
> If we check generated bridge name length, users will not face the 
> exception before their cloudstack environment grow up. They will face the 
> exception in production environment suddenly.
> If we check physical interface name length, users can face the exception 
> whenever bridge name length is not enough.
>

That's why we would note in document that such a situation can be happened when 
VXLAN isolated zone grows up, isn't it? 

It's too much to completely disable VXLAN isolation for pifName >=5, especially 
when we won't provide any workaround.
IMO when we try to introduce fool proof mechanism, like this patch, we first 
try to avoid creating restriction in non-fools' usage.

Let's check Marcus's patch.


- Toshiaki


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


On Oct. 29, 2013, 12:51 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15001/
> ---
> 
> (Updated Oct. 29, 2013, 12:51 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Guest network isn't created correctly when vxlan is used for isolation 
> method, VNI is bigger than 1000, and physical network interface name 
> length is longer than 4.
> This patch fix this issue by raising error when long interface name is 
> specified.
> 
> Issue remained: document that physical interface name length must be shorter 
> than 5.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/BridgeVifDriverTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15001/diff/
> 
> 
> Testing
> ---
> 
> I confirmed it passes the unit tests I add.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 15001: CLOUDSTACK-4967: Bugfix: Guest network isn't created correctly in rare case when vxlan is used for isolation method

2013-10-29 Thread Toshiaki Hatano



> On Oct. 29, 2013, 4:35 a.m., Toshiaki Hatano wrote:
> > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java,
> >  line 158
> > 
> >
> > If we checked length here, generated brName should be checked, not a 
> > pifName.
> > 
> > We shouldn't block valid brName by this check, e.g. eth0.1000-9000.
> 
> Toshiaki Hatano wrote:
> s/eth0.1000-9000/breth0.100-9000/
> 
> Yoshikazu Nojima wrote:
> It validates pifName, not brName. It validates pifName in the point of 
> whether it is appropriate to be used for generating bridge name here.

My apology if it was lack of talk.
What I trid to mean is, brName like "breth0.100-9000" are still valid bridge 
name despite pifName longer than 5, thus this check is too strong.


- Toshiaki


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


On Oct. 29, 2013, 12:51 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15001/
> ---
> 
> (Updated Oct. 29, 2013, 12:51 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Guest network isn't created correctly when vxlan is used for isolation 
> method, VNI is bigger than 1000, and physical network interface name 
> length is longer than 4.
> This patch fix this issue by raising error when long interface name is 
> specified.
> 
> Issue remained: document that physical interface name length must be shorter 
> than 5.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/BridgeVifDriverTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15001/diff/
> 
> 
> Testing
> ---
> 
> I confirmed it passes the unit tests I add.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 15001: CLOUDSTACK-4967: Bugfix: Guest network isn't created correctly in rare case when vxlan is used for isolation method



> On Oct. 29, 2013, 4:35 a.m., Toshiaki Hatano wrote:
> >
> 
> Toshiaki Hatano wrote:
> Actual issue is not "the physical interface name length must be shorter 
> than 5" but "generated bridge name cannot exceed 15 character".
>
> 
> Yoshikazu Nojima wrote:
> If we check generated bridge name length, users will not face the 
> exception before their cloudstack environment grow up. They will face the 
> exception in production environment suddenly.
> If we check physical interface name length, users can face the exception 
> whenever bridge name length is not enough.
>
> 
> Toshiaki Hatano wrote:
> That's why we would note in document that such a situation can be 
> happened when VXLAN isolated zone grows up, isn't it? 
> 
> It's too much to completely disable VXLAN isolation for pifName >=5, 
> especially when we won't provide any workaround.
> IMO when we try to introduce fool proof mechanism, like this patch, we 
> first try to avoid creating restriction in non-fools' usage.
> 
> Let's check Marcus's patch.

User can change a vlan interface name by configuration.
http://manpages.ubuntu.com/manpages/raring/man5/vlan-interfaces.5.html

I think it is enough workaround. isn't it?


- Yoshikazu


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


On Oct. 29, 2013, 12:51 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15001/
> ---
> 
> (Updated Oct. 29, 2013, 12:51 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Guest network isn't created correctly when vxlan is used for isolation 
> method, VNI is bigger than 1000, and physical network interface name 
> length is longer than 4.
> This patch fix this issue by raising error when long interface name is 
> specified.
> 
> Issue remained: document that physical interface name length must be shorter 
> than 5.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/BridgeVifDriverTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15001/diff/
> 
> 
> Testing
> ---
> 
> I confirmed it passes the unit tests I add.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

RE: Wiki access

2013-10-29 Thread Damoder Reddy

Please grant me edit access.. 
Email : damoder.re...@citrix.com
Username: Damoder.reddy

-Original Message-
From: Nitin Mehta [mailto:nitin.me...@citrix.com] 
Sent: Tuesday, 29 October 2013 7:18 AM
To: dev@cloudstack.apache.org
Subject: Re: Wiki access

Please grant me edit access.
Email - nitin.me...@citrix.com

On 28/10/13 5:17 AM, "Gaurav Aradhye"  wrote:

>Hi,
>
>My username is gauravaradhye.
>Can anyone grant me edit permission?
>
>I need to update test plan automation columns.
>
>
>Regards,
>Gaurav
>
>
>On Fri, Oct 18, 2013 at 5:26 PM, Kishan Kavala
>wrote:
>
>> Thanks Hugo.
>>
>> > -Original Message-
>> > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo 
>> > Trippaers
>> > Sent: Friday, 18 October 2013 4:39 PM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: Wiki access
>> >
>> > Hey Kishan,
>> >
>> > I've granted you permissions. There apparently is another Kishan 
>> > with
>> edit
>> > permission as well, so i got confused.
>> >
>> > Cheers,
>> >
>> > Hugo
>> >
>> > On 18 okt. 2013, at 12:38, Kishan Kavala 
>> wrote:
>> >
>> > > Hugo,
>> > > I've checked again. My account doesn't have edit permission.
>> > >
>> > >> -Original Message-
>> > >> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
>>Trippaers
>> > >> Sent: Wednesday, 16 October 2013 7:59 PM
>> > >> To: dev@cloudstack.apache.org
>> > >> Subject: Re: Wiki access
>> > >>
>> > >> Kishan,
>> > >>
>> > >> look like you have the permissions already on account kishan. 
>> > >> Can
>>you
>> check?
>> > >>
>> > >> Cheers,
>> > >>
>> > >> Hugo
>> > >>
>> > >>
>> > >> On Oct 16, 2013, at 3:45 PM, Kishan Kavala
>>
>> > wrote:
>> > >>
>> > >>> Please grant me edit access.
>> > >>> Email: kis...@cloud.com
>> > >>>
>> > >>> ~kishan
>> > >>>
>> >  -Original Message-
>> >  From: Radhika Puthiyetath 
>> >  [mailto:radhika.puthiyet...@citrix.com]
>> >  Sent: Wednesday, 16 October 2013 3:22 PM
>> >  To: dev@cloudstack.apache.org
>> >  Subject: RE: Wiki access
>> > 
>> >  Hi,
>> > 
>> >  I do not have the edit permissions. My username is radhikap.
>> > 
>> >  Kindly provide me with the necessary permissions.
>> > 
>> >  Thanks
>> >  -Radhika
>> > 
>> >  -Original Message-
>> >  From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> >  Sent: Friday, October 04, 2013 3:26 PM
>> >  To: dev
>> >  Subject: Re: Wiki access
>> > 
>> >  anshulg is in
>> > 
>> > 
>> >  On Fri, Oct 4, 2013 at 11:51 AM, Anshul Gangwar
>> >  wrote:
>> > 
>> > > need edit permissions , username: anshulg
>> > >
>> > > Regards,
>> > > Anshul
>> > >
>> > > On Friday 04 October 2013 02:47 PM, Saksham Srivastava wrote:
>> > >> Please provide me edit permissions, username: saksham
>> > >>
>> > >> Regards,
>> > >> Saksham
>> > >>
>> > >> -Original Message-
>> > >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> > >> Sent: Friday, October 04, 2013 10:46 AM
>> > >> To: dev@cloudstack.apache.org
>> > >> Subject: Re: Wiki access
>> > >>
>> > >> Mike, Tuna, Srinivas, Go, done.
>> > >>
>> > >> On 10/3/13 9:12 PM, "Mike Tutkowski"
>> > >> 
>> > > wrote:
>> > >>
>> > >>> I seem to need edit access, as well.
>> > >>>
>> > >>> I'm usually logged in by default, but I believe my username 
>> > >>> is mike-tutkowski (else please try mtutkowski).
>> > >>>
>> > >>> Thanks!
>> > >>>
>> > >>>
>> > >>> On Thu, Oct 3, 2013 at 7:07 PM, Go Chiba 
>> > >>> 
>> > wrote:
>> > >>>
>> >  Hi Chip,
>> > 
>> >  Please grant me to edit pages. My id is "gochiba".
>> > 
>> > 
>> >  On Thu, Oct 3, 2013 at 6:01 AM, Chip Childers 
>> >  > > > wrote:
>> > > Not all committers were easy to find, but those that I 
>> > > did should be
>> >  all
>> > > set.
>> > >
>> > > So committers / contributors = provide your confluence 
>> > > ID's
>>if
>> > > you
>> >  can't
>> > > add / edit pages.  PMC folks - help add them please.
>> > >
>> > >
>> > > On Wed, Oct 2, 2013 at 4:48 PM, Chip Childers
>> >  > > >> wrote:
>> > >> There were major issues with Spam on the wiki, so infra 
>> > >> changed the permissions.
>> > >>
>> > >> I've just gone and added all PMC members to the space as 
>> > >> space
>> >  admins.
>> > >> That means all PMC members can help deal with this issue
>>(or
>> > >> at
>> >  least
>> > >> those that I could find in the wiki user list).
>> > >>
>> > >> I'm going to deal with committers next.  That permission 
>> > >> level
>> >  needs to
>> > >> exclude space admin.  I'm using alena1108 a

Re: haPlanners error in fresh 4.2 checkout

2013-10-29 Thread sebgoa


On Oct 28, 2013, at 7:14 PM, Nitin Mehta  wrote:

> Probably cleaning up you workspace might help.

Dummy question of the day then, how do I do that ?
I did compile with `mvn clean install`


> 
> On 28/10/13 10:51 AM, "Prachi Damle"  wrote:
> 
>> I had encountered this sometime back ... you need to check if your
>> componentContext.xml or its equivalent has following defined. However I
>> do see it is present in the 4.2 branch
>> 
>> 
>>  
>>
>>
>>
>>  
>> 
>> 
>> -Original Message-
>> From: sebgoa [mailto:run...@gmail.com]
>> Sent: Monday, October 28, 2013 6:43 AM
>> To: dev@cloudstack.apache.org
>> Subject: haPlanners error in fresh 4.2 checkout
>> 
>> Hi,
>> 
>> I just checked out the latest from 4.2 and I get this:
>> 
>> INFO  [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:)
>> JSR-330 'javax.inject.Inject' annotation found and supported for
>> autowiring INFO  
>> [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:) JSR-330
>> 'javax.inject.Inject' annotation found and supported for autowiring INFO
>> [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:) JSR-330
>> 'javax.inject.Inject' annotation found and supported for autowiring
>> 2013-10-28 14:41:36.018:INFO::Started SelectChannelConnector@0.0.0.0:8080
>> [INFO] Started Jetty Server
>> Exception in thread "Timer-2"
>> org.springframework.beans.factory.BeanExpressionException: Expression
>> parsing failed; nested exception is
>> org.springframework.expression.spel.SpelEvaluationException: EL1008E:(pos
>> 0): Field or property 'haPlanners' cannot be found on object of type
>> 'org.springframework.beans.factory.config.BeanExpressionContext'
>>  at 
>> org.springframework.context.expression.StandardBeanExpressionResolver.eval
>> uate(StandardBeanExpressionResolver.java:142)
>>  at 
>> org.springframework.beans.factory.support.AbstractBeanFactory.evaluateBean
>> DefinitionString(AbstractBeanFactory.java:1299)
>>  at 
>> org.springframework.beans.factory.support.BeanDefinitionValueResolver.eval
>> uate(BeanDefinitionValueResolver.java:210)
>>  at 
>> org.springframework.beans.factory.support.BeanDefinitionValueResolver.reso
>> lveValueIfNecessary(BeanDefinitionValueResolver.java:182)
>>  at 
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto
>> ry.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
>>  at 
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto
>> ry.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
>>  at 
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFacto
>> ry.configureBean(AbstractAutowireCapableBeanFactory.java:314)
>>  at 
>> com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(Compone
>> ntContext.java:71)
>>  at 
>> com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54)
>>  at java.util.TimerThread.mainLoop(Timer.java:555)
>>  at java.util.TimerThread.run(Timer.java:505)
>> Caused by: org.springframework.expression.spel.SpelEvaluationException:
>> EL1008E:(pos 0): Field or property 'haPlanners' cannot be found on object
>> of type 'org.springframework.beans.factory.config.BeanExpressionContext'
>>  at 
>> org.springframework.expression.spel.ast.PropertyOrFieldReference.readPrope
>> rty(PropertyOrFieldReference.java:208)
>>  at 
>> org.springframework.expression.spel.ast.PropertyOrFieldReference.getValueI
>> nternal(PropertyOrFieldReference.java:72)
>>  at 
>> org.springframework.expression.spel.ast.CompoundExpression.getValueInterna
>> l(CompoundExpression.java:52)
>>  at 
>> org.springframework.expression.spel.ast.SpelNodeImpl.getValue(SpelNodeImpl
>> .java:93)
>>  at 
>> org.springframework.expression.spel.standard.SpelExpression.getValue(SpelE
>> xpression.java:88)
>>  at 
>> org.springframework.context.expression.StandardBeanExpressionResolver.eval
>> uate(StandardBeanExpressionResolver.java:139)
>>  ... 10 more
>> 
>> 
>> Any thoughts ?
>> 
>> -sebastien
>

Enable SSL (https) for Cloudstack 4.2.0 management server

2013-10-29 Thread Indra Pramana

Dear all,

Any documentation on how to enable SSL (https) for Cloudstack 4.2.0
management server? I am using Ubuntu 12.04.2. I tried to follow the
instruction here, is it still valid?

http://support.citrix.com/article/CTX132008

I have managed to come to the step of creating the PKS12 format keystore:

root@cs-mgmt-01:~/ssl-cert# openssl pkcs12 -export -in server.crt -inkey
server.key -name cloud -passout pass:password > cloud-localhost.pk12
Enter pass phrase for server.key:
root@cs-mgmt-01:~/ssl-cert# ls -la cloud-localhost.pk12
-rw-r--r-- 1 root root 3000 Oct 29 16:11 cloud-localhost.pk12

However, I am not too sure where should I put the file, and how can I
configure Tomcat to use the file? On the above documentation, it says that
I need to put the file on:

/usr/share/cloud/management/conf/

The 4.2 equivalent of the above folder I believe should be

/usr/share/cloudstack-management/conf

I have put the cloud-localhost.pk12 on the folder. What's next? :)

I noted there are these files on the same folder:

-rw-r--r-- 1 root root  10211 Jun  5 02:45 server-nonssl.xml
-rw-r--r-- 1 root root  12094 Sep 24 16:31 server-ssl.xml
lrwxrwxrwx 1 root root 17 Oct 12 23:37 server.xml -> server-nonssl.xml
lrwxrwxrwx 1 root root 19 Oct 12 23:37 tomcat6.conf ->
tomcat6-nonssl.conf
-rw-r--r-- 1 root root   2712 Jun  5 02:45 tomcat6-nonssl.conf
-rw-r--r-- 1 root root   2841 Sep 24 16:31 tomcat6-ssl.conf

I tried to point the symbolic links for server.xml and tomcat6.conf to
server-ssl.xml and tomcat6-ssl.conf respectively, and restarted
cloudstack-management service. But I am not able to access the Cloudstack
GUI, even using https:// in front. It seems that Tomcat is not able to
recognize the pk12 certificate file that I have put?

Looking forward to your reply, thank you.

Cheers.

Re: Review Request 14867: api call to import ldap users to the same domains in cloudstack

2013-10-29 Thread Ian Duffy


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

Ship it!


Ship It!

- Ian Duffy


On Oct. 23, 2013, 5:26 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14867/
> ---
> 
> (Updated Oct. 23, 2013, 5:26 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Ian Duffy.
> 
> 
> Bugs: CLOUDSTACK-4866
> https://issues.apache.org/jira/browse/CLOUDSTACK-4866
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added an api call to import all the ldap users to the same domains(ou's) in 
> cloudstack
> 
> TODO:
> 1. error handling of no domains present, nested hierarchy
> 2. handling the case when the api call fails for a specific user/users
> 3. test cases for LdapUserManager
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/user/DomainService.java 7c302e3 
>   client/tomcatconf/commands.properties.in 0296de0 
>   
> plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LdapImportUsersCmd.java
>  PRE-CREATION 
>   
> plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/response/LdapUserResponse.java
>  9b21c8f 
>   
> plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapConfiguration.java
>  0cfb37c 
>   
> plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapManagerImpl.java
>  87406ad 
>   
> plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapUser.java 
> 18ad7d9 
>   
> plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapUserManager.java
>  7494346 
>   
> plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapConfigurationSpec.groovy
>  c593959 
>   
> plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapImportUsersCmdSpec.groovy
>  PRE-CREATION 
>   
> plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapListUsersCmdSpec.groovy
>  5039443 
>   
> plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapManagerImplSpec.groovy
>  d681eac 
>   
> plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapSearchUserCmdSpec.groovy
>  fce299d 
>   
> plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapUserResponseSpec.groovy
>  f1978fa 
>   
> plugins/user-authenticators/ldap/test/groovy/org/apache/cloudstack/ldap/LdapUserSpec.groovy
>  8fd1ccc 
>   server/src/com/cloud/user/DomainManagerImpl.java b885c48 
>   server/test/com/cloud/user/MockDomainManagerImpl.java 616e12d 
> 
> Diff: https://reviews.apache.org/r/14867/diff/
> 
> 
> Testing
> ---
> 
> testing is done except for LdapUserManager(for which i am facing some issues 
> locally) and DomainService(for which no test cases exist currently)
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Enable SSL (https) for Cloudstack 4.2.0 management server

2013-10-29 Thread Nux!


On 29.10.2013 09:02, Indra Pramana wrote:

Dear all,

Any documentation on how to enable SSL (https) for Cloudstack 4.2.0
management server? I am using Ubuntu 12.04.2. I tried to follow the
instruction here, is it still valid?

http://support.citrix.com/article/CTX132008

I have managed to come to the step of creating the PKS12 format 
keystore:


Wow, that looks convoluted. Don't know if it would work, but my 
instinct is just "yum install mod_ssl" and proxy requests.


Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Review Request 15018: CLOUDSTACK-4908: CPU socket count of host

2013-10-29 Thread Harikrishna Patnala


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

Review request for cloudstack and Kishan Kavala.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-4908: CPU socket count of host 
Adding cpu socket count of the host in hostresponse


Diffs
-

  api/src/com/cloud/host/Host.java 17b0ba8 
  api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java 
95b9ac3 
  api/src/org/apache/cloudstack/api/response/HostResponse.java 687687d 
  core/src/com/cloud/agent/api/StartupRoutingCommand.java d52666b 
  core/test/org/apache/cloudstack/api/agent/test/CheckOnHostCommandTest.java 
1b68276 
  
engine/orchestration/src/org/apache/cloudstack/engine/datacenter/entity/api/db/EngineHostVO.java
 249c2db 
  engine/schema/src/com/cloud/host/HostVO.java c814b94 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 286d0f7 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 423abe6 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 6c1efe7 
  server/src/com/cloud/api/query/QueryManagerImpl.java a7d85cf 
  server/src/com/cloud/api/query/dao/HostJoinDaoImpl.java 97f8bf9 
  server/src/com/cloud/api/query/vo/HostJoinVO.java fbc59cd 
  server/src/com/cloud/resource/ResourceManagerImpl.java e9d5193 
  setup/db/db/schema-421to430.sql 0e78875 
  vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java 108a3ec 
  vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHost.java 
f7288f1 
  
vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHostResourceSummary.java
 fa11dc3 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 15001: CLOUDSTACK-4967: Bugfix: Guest network isn't created correctly in rare case when vxlan is used for isolation method



> On Oct. 29, 2013, 4:35 a.m., Toshiaki Hatano wrote:
> >
> 
> Toshiaki Hatano wrote:
> Actual issue is not "the physical interface name length must be shorter 
> than 5" but "generated bridge name cannot exceed 15 character".
>
> 
> Yoshikazu Nojima wrote:
> If we check generated bridge name length, users will not face the 
> exception before their cloudstack environment grow up. They will face the 
> exception in production environment suddenly.
> If we check physical interface name length, users can face the exception 
> whenever bridge name length is not enough.
>
> 
> Toshiaki Hatano wrote:
> That's why we would note in document that such a situation can be 
> happened when VXLAN isolated zone grows up, isn't it? 
> 
> It's too much to completely disable VXLAN isolation for pifName >=5, 
> especially when we won't provide any workaround.
> IMO when we try to introduce fool proof mechanism, like this patch, we 
> first try to avoid creating restriction in non-fools' usage.
> 
> Let's check Marcus's patch.
> 
> Yoshikazu Nojima wrote:
> User can change a vlan interface name by configuration.
> http://manpages.ubuntu.com/manpages/raring/man5/vlan-interfaces.5.html
> 
> I think it is enough workaround. isn't it?

>From what I've tried in the past, given the Vlan tag 1000, you can implement 
>that via name "eth0.1000" or "vlan1000", but that's it. Unless something has 
>changed, you can't create an arbitrary short name. So that leaves only 3-4 
>characters for vni.

Ah, see set_name_type for vconfig, it describes these allowed names.


- Marcus


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


On Oct. 29, 2013, 12:51 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15001/
> ---
> 
> (Updated Oct. 29, 2013, 12:51 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Guest network isn't created correctly when vxlan is used for isolation 
> method, VNI is bigger than 1000, and physical network interface name 
> length is longer than 4.
> This patch fix this issue by raising error when long interface name is 
> specified.
> 
> Issue remained: document that physical interface name length must be shorter 
> than 5.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/BridgeVifDriverTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15001/diff/
> 
> 
> Testing
> ---
> 
> I confirmed it passes the unit tests I add.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 14593: CLOUDSTACK-1833: Automation - Adding scale virtual machine test cases


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


test_19 is failing

- SrikanteswaraRao Talluri


On Oct. 21, 2013, 12:54 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14593/
> ---
> 
> (Updated Oct. 21, 2013, 12:54 p.m.)
> 
> 
> Review request for cloudstack, Nitin Mehta and SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Some of the basic P1 test cases for scaling up CPU and RAM for running VMs.
> More tests to be added on top of this - in progress.
> 
> DDT library needed to run the test case.
> It can be installed with pip install ddt command.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_scale_vm.py PRE-CREATION 
>   tools/marvin/marvin/integration/lib/base.py 4f15137 
>   tools/marvin/marvin/integration/lib/common.py 164ef20 
>   tools/marvin/setup.py eeed3bf 
> 
> Diff: https://reviews.apache.org/r/14593/diff/
> 
> 
> Testing
> ---
> 
> Tested on XenServer. Not attaching logs because different test cases were run 
> at different time, not all at once.
> All test cases running on XenServer, if at all needed, will add log after 
> running them once again.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Review Request 15021: Fixed Bug: 4899 : Added Configuration Support to Marvin.

2013-10-29 Thread Santhosh Edukulla


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

Review request for cloudstack and Prasanna Santhanam.


Repository: cloudstack-git


Description
---

 Added Configuration Support to Marvin.

1. It provides the basic configuration facilities to marvin.

2. User can just add configuration files for his tests, deployment
  etc, under one config folder before running their tests.
  cs/tools/marvin/marvin/config.
  They can remove all hard coded values from code and separate
  it out as config at this location.
  Either add this to the existing setup.cfg as separate section
  or add new configuration.
3. This will thus removes hard coded tests and separate
  data from tests.

4. This API is provided as an additional facility under
  cloudstackTestClient and users can get the
  configuration object as similar to apiclient,dbconnection
  etc to drive their test.

5. They just add their configuration for a test,
  setup etc,at one single place under configuration dir
  and use "getConfigParser" API of cloudstackTestClient
  It will give them "configObj".They can either pass their own
  config file for parsing to "getConfig" or it will use
  default config file @ config/setup.cfg.
6. They will then get the dictionary of parsed
  configuration and can use it further to drive their tests or
  config drive
7. Test features, can  drive their setups thus removing hard coded
  values. Configuration default file will be under config and as
  setup.cfg.
8. Users can use their own configuration file passed to
  "getConfig" API,once configObj is returned.

Another such case where we are using sed or bash script is  in between a build 
run for replacing hard coded ldap ip for region\setup specific. We can now 
change all parameters before run under configuration, the test features will 
use configuration object and thus values, rather hard coded strings which 
avoids replacement through shell script.


Diffs
-

  tools/marvin/marvin/cloudstackTestClient.py be93f35 
  tools/marvin/marvin/config/setup.cfg PRE-CREATION 
  tools/marvin/marvin/configGenerator.py 0cfad30 
  tools/marvin/marvin/integration/lib/utils.py 7d662af 

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


Testing
---

Basic check to retrieve configuration values is done.


Thanks,

Santhosh Edukulla

Re: Review Request 14990: added formatter setting xml file for eclipse

2013-10-29 Thread daan Hoogland


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

Ship it!


Ship It!

- daan Hoogland


On Oct. 28, 2013, 2:25 p.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14990/
> ---
> 
> (Updated Oct. 28, 2013, 2:25 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added formatter setting xml file for eclipse
> 
> 
> Diffs
> -
> 
>   tools/eclipse/ApacheCloudStack.xml PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/14990/diff/
> 
> 
> Testing
> ---
> 
> Yes. Manually on eclipse kepler and intellij 12 Community edition running on 
> ubuntu 13.04
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Review Request 14990: added formatter setting xml file for eclipse

2013-10-29 Thread daan Hoogland



> On Oct. 29, 2013, 1:21 p.m., daan Hoogland wrote:
> > Ship It!

4c6add84d866babcbc312ae441f615870087ac3d


- daan


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


On Oct. 28, 2013, 2:25 p.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14990/
> ---
> 
> (Updated Oct. 28, 2013, 2:25 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added formatter setting xml file for eclipse
> 
> 
> Diffs
> -
> 
>   tools/eclipse/ApacheCloudStack.xml PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/14990/diff/
> 
> 
> Testing
> ---
> 
> Yes. Manually on eclipse kepler and intellij 12 Community edition running on 
> ubuntu 13.04
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: [DISCUSS] Leaky abstractions [was review requests 13238, 13896, 14320]

2013-10-29 Thread nfoata.ext

Hello,

Concerning the last message
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201310.mbox/%3ccagqtxvyvzplcycge1vmwuxfvt5px0xdxwxmb5bwv5edcewu...@mail.gmail.com%3e

and the following patches
https://reviews.apache.org/r/13238/
https://reviews.apache.org/r/14320/
https://reviews.apache.org/r/13896/
a wiki discussion seems to be launched and/or done.

Does a such discussion exist on the wiki ? And where could we access it ?
Otherwise, how could we start it ?

Have a good day,

Best regards,

[cid:image001.gif@01CED4B6.6AAB4A30]

Nicolas Foata
O/OF/DSIF/DFY/SDFY/RnB
Sophia Antipolis
FRANCE
[cid:image002.gif@01CED4B6.6AAB4A30]

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

Re: LXC and SSVM/CPVM on the host

2013-10-29 Thread Francois Gaudreault


Kelven,

This is what I get in the LXC host agent log when I try to check the 
console from CS:


2013-10-29 10:07:42,079 WARN  [cloud.agent.Agent] 
(agentRequest-Handler-4:null) Caught:

java.lang.NullPointerException
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2711)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1216)

at com.cloud.agent.Agent.processRequest(Agent.java:525)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
at com.cloud.utils.nio.Task.run(Task.java:83)
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:744)

This is the error on the CS side:

2013-10-29 10:12:58,215 DEBUG [agent.manager.AgentManagerImpl] 
(catalina-exec-16:null) Details from executing class 
com.cloud.agent.api.GetVncPortCommand: java.lang.NullPointerException
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2711)
at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1216)

at com.cloud.agent.Agent.processRequest(Agent.java:525)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
at com.cloud.utils.nio.Task.run(Task.java:83)
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:744)

2013-10-29 10:12:58,215 ERROR [cloud.servlet.ConsoleProxyServlet] 
(catalina-exec-16:null) Unexepected exception in ConsoleProxyServlet
java.lang.ClassCastException: com.cloud.agent.api.Answer cannot be cast 
to com.cloud.agent.api.GetVncPortAnswer
at 
com.cloud.server.ManagementServerImpl.getVncPort(ManagementServerImpl.java:2193)
at 
com.cloud.servlet.ConsoleProxyServlet.composeConsoleAccessUrl(ConsoleProxyServlet.java:381)
at 
com.cloud.servlet.ConsoleProxyServlet.handleAccessRequest(ConsoleProxyServlet.java:269)
at 
com.cloud.servlet.ConsoleProxyServlet.doGet(ConsoleProxyServlet.java:171)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at 
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
at 
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:679)


On 10/28/2013, 9:05 PM, Kelven Yang wrote:

As long as the container VNC console is reachable from console proxy
agent, I don't see a technical issue here. Need some log details to
understand the situation. For example, what information does LXC
hypervisor resource agent returns on GetVncPort command?

Kelven
  


On 10/28/13 10:59 AM, "Francois Gaudreault" 
wrote:


Thanks! Is the console proxy issue will be fixed at some point in the
future or this won't be possible?

Francois

On 10/28/2013, 1:57 PM, Phong Nguyen wrote:

Yes, the console proxy VM is unable to connect to the LXC console. Use
virsh to connect from the host.

virsh -c lxc:/// console i-2-20-VM

-Phong


On Mon, Oct 28, 2013 at 1:22 PM, Francois Gaudreault
mailto:fgaudrea...@cloudops.com>> wrote:

 Ok, I followed Chiradeep's comment here, and it now works fine. I
 have CentOS 6 containers running.

 My only other questions would be:
 - Is it normal that the console proxy VM cannot proxy the
 container's console?
 - How can I access the container console from the host? (I am on
 CentOS) I can ssh to the container tho.

 Thanks!

 Francois


 On 10/24/2013, 7:00 PM, Chiradeep Vitta

Re: Review Request 15001: CLOUDSTACK-4967: Bugfix: Guest network isn't created correctly in rare case when vxlan is used for isolation method



> On Oct. 29, 2013, 4:35 a.m., Toshiaki Hatano wrote:
> >
> 
> Toshiaki Hatano wrote:
> Actual issue is not "the physical interface name length must be shorter 
> than 5" but "generated bridge name cannot exceed 15 character".
>
> 
> Yoshikazu Nojima wrote:
> If we check generated bridge name length, users will not face the 
> exception before their cloudstack environment grow up. They will face the 
> exception in production environment suddenly.
> If we check physical interface name length, users can face the exception 
> whenever bridge name length is not enough.
>
> 
> Toshiaki Hatano wrote:
> That's why we would note in document that such a situation can be 
> happened when VXLAN isolated zone grows up, isn't it? 
> 
> It's too much to completely disable VXLAN isolation for pifName >=5, 
> especially when we won't provide any workaround.
> IMO when we try to introduce fool proof mechanism, like this patch, we 
> first try to avoid creating restriction in non-fools' usage.
> 
> Let's check Marcus's patch.
> 
> Yoshikazu Nojima wrote:
> User can change a vlan interface name by configuration.
> http://manpages.ubuntu.com/manpages/raring/man5/vlan-interfaces.5.html
> 
> I think it is enough workaround. isn't it?
> 
> Marcus Sorensen wrote:
> From what I've tried in the past, given the Vlan tag 1000, you can 
> implement that via name "eth0.1000" or "vlan1000", but that's it. Unless 
> something has changed, you can't create an arbitrary short name. So that 
> leaves only 3-4 characters for vni.
> 
> Ah, see set_name_type for vconfig, it describes these allowed names.
> 
>

Oh, I didn't know that.. It breaks this patch's assumption.


- Yoshikazu


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


On Oct. 29, 2013, 12:51 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15001/
> ---
> 
> (Updated Oct. 29, 2013, 12:51 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Guest network isn't created correctly when vxlan is used for isolation 
> method, VNI is bigger than 1000, and physical network interface name 
> length is longer than 4.
> This patch fix this issue by raising error when long interface name is 
> specified.
> 
> Issue remained: document that physical interface name length must be shorter 
> than 5.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/BridgeVifDriverTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15001/diff/
> 
> 
> Testing
> ---
> 
> I confirmed it passes the unit tests I add.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

listVolumes pool id

I almost can't believe this doesn't already exist, but I noticed that
listing a volume doesn't show you the id of the storage pool the
volume belongs to. It shows the pool name, but it seems that doesn't
have to be unique.  Does anyone have a problem with me adding that to
the listVolumes response?  Are there any tests that might fail due to
hardcoded response expectations?

RE: [Merge] hyperv branch to master

2013-10-29 Thread Donal Lafferty

+1

> -Original Message-
> From: Chiradeep Vittal
> Sent: 29 October 2013 06:43
> To: dev@cloudstack.apache.org
> Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
> Subject: Re: [Merge] hyperv branch to master
> 
> +1
> 
> On 10/28/13 4:41 AM, "Devdeep Singh"  wrote:
> 
> >Hi,
> >
> >I would like to merge the support for Hyperv to the master branch.
> >Development for this has been done by Donal, Rajesh, Anshul and I on
> >branch [1]. The feature was proposed for merge earlier [3] but unit
> >tests for hyperv agent code were requested [4].
> >
> >Checklist:
> >The development for the feature was earlier done in branch [2] but
> >later moved to [1].
> >Jira ticket for the feature is here [5].
> >The FS can be found at [6] and [7].
> >Unit tests for the feature are available at [8]
> >
> >This link [7] also provides details of third party libraries used by
> >the plugin including their licenses. No source for these libraries is
> >used, and the binaries are downloaded from their distributors at build
> >time. No proprietary tools are required for the build.  For instance,
> >C# compiled with Mono has been tested. Mono setup details can be found
> here [9].
> >
> >[1]
> >https://git-wip-us.apache.org/repos/asf/cloudstack/repo?p=cloudstack.gi
> >t;a
> >=shortlog;h=refs/heads/hyperv
> >[2] https://github.com/lafferty/cloudstack/tree/hyperv_plugin
> >[3]
> >http://markmail.org/message/cm7kdwh6l2ea772e?q=list:org%2Eapache%2
> Eincu
> >bat or%2Ecloudstack-%2A+Minimal+Hyperv+plugin
> >[4]
> >http://markmail.org/message/vxknappvyovhmeyp?q=list:org%2Eapache%
> 2Eincu
> >bat
> >or%2Ecloudstack-%2A+Minimal+Hyperv+plugin&page=3
> >[5] https://issues.apache.org/jira/browse/CLOUDSTACK-999
> >[6]
> >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hyper-
> V+2012+%28
> >3.0
> >%29+Support
> >[7] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Progress
> >[8]
> >https://git-wip-us.apache.org/repos/asf/cloudstack/repo?p=cloudstack.gi
> >t;a
> >=blob;f=plugins/hypervisors/hyperv/DotNet/ServerResource/ServerResou
> rce
> >.Te
> >sts/HypervResourceController1Test.cs;h=ec91e9ff21742bde78873ed7cee49
> f24
> >23e
> >425b9;hb=refs/heads/hyperv
> >[9]
> >http://dlafferty.blogspot.co.uk/2013/08/building-your-microsoft-solutio
> >n-w
> >ith.html
> >
> >Regards,
> >Devdeep
> >
> >

Re: Issues deploying with marvin

When I build with:  mvn -P developer,systemvm -Dnonoss clean install -X

I get the error below.  I have completely rebuilt my system from scratch
and I still get this...  Any ideas?

If I run the same command, but without the 'developer' profile, everything
builds correctly.
(eg: mvn -P systemvm -Dnonoss clean install -X)

Are there specific requirements needed to build the developer profile?

---

[INFO] Installing
/mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/pom.xml to
/root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/cloud-marvin-4.3.0-SNAPSHOT.pom

[DEBUG] Writing resolution tracking file
/root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/_maven.repositories

[DEBUG] Installing
org.apache.cloudstack:cloud-marvin:4.3.0-SNAPSHOT/maven-metadata.xml to
/root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/maven-metadata-local.xml

[DEBUG] Installing org.apache.cloudstack:cloud-marvin/maven-metadata.xml to
/root/.m2/repository/org/apache/cloudstack/cloud-marvin/maven-metadata-local.xml

[INFO]

[INFO] --- exec-maven-plugin:1.2.1:exec (install) @ cloud-marvin ---

[DEBUG] Configuring mojo org.codehaus.mojo:exec-maven-plugin:1.2.1:exec
from plugin realm
ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent:
sun.misc.Launcher$AppClassLoader@5acac268]

[DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec'
with basic configurator -->

[DEBUG]   (f) arguments = [setup.py, sdist]

[DEBUG]   (f) basedir =
/mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin

[DEBUG]   (f) classpathScope = runtime

[DEBUG]   (f) executable = python

[DEBUG]   (f) longClasspath = false

[DEBUG]   (f) project = MavenProject:
org.apache.cloudstack:cloud-marvin:4.3.0-SNAPSHOT @
/mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/pom.xml

[DEBUG]   (f) session = org.apache.maven.execution.MavenSession@6d3cba41

[DEBUG]   (f) skip = false

[DEBUG] -- end configuration --

[DEBUG] Executing command line: python setup.py sdist

running sdist

running egg_info

writing requirements to Marvin.egg-info/requires.txt

writing Marvin.egg-info/PKG-INFO

writing top-level names to Marvin.egg-info/top_level.txt

writing dependency_links to Marvin.egg-info/dependency_links.txt

writing entry points to Marvin.egg-info/entry_points.txt

reading manifest file 'Marvin.egg-info/SOURCES.txt'

reading manifest template 'MANIFEST.in'

warning: no files found matching '*.txt' under directory 'docs'

writing manifest file 'Marvin.egg-info/SOURCES.txt'

making hard links in Marvin-0.1.0...

hard linking CHANGES.txt -> Marvin-0.1.0

error: Operation not permitted

[INFO]


[INFO] Reactor Summary:

[INFO]

[INFO] Apache CloudStack . SUCCESS [4.341s]

[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.089s]

[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [4.999s]

[INFO] Apache CloudStack Utils ... SUCCESS [17.555s]

[INFO] Apache CloudStack Framework ... SUCCESS [0.125s]

[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [9.514s]

[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [5.700s]

[INFO] Apache CloudStack API . SUCCESS [26.885s]

[INFO] Apache CloudStack Framework - REST  SUCCESS [3.394s]

[INFO] Apache CloudStack Framework - IPC . SUCCESS [8.755s]

[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.091s]

[INFO] Apache CloudStack Cloud Engine API  SUCCESS [7.934s]

[INFO] Apache CloudStack Core  SUCCESS [13.925s]

[INFO] Apache CloudStack Agents .. SUCCESS [7.509s]

[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [4.550s]

[INFO] Apache CloudStack Framework - Jobs  SUCCESS [4.811s]

[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [17.694s]

[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [2.665s]

[INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS
[4.491s]

[INFO] Apache CloudStack Server .. SUCCESS [56.473s]

[INFO] Apache CloudStack Usage Server  SUCCESS [8.747s]

[INFO] Apache XenSource XAPI . SUCCESS [8.695s]

[INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS
[10.341s]

[INFO] Apache CloudStack Cloud Services .. SUCCESS [0.207s]

[INFO] Apache CloudStack Secondary Storage Service ... SUCCESS [5.918s]

[INFO] Apache CloudStack Engine Storage Component  SUCCESS [5.974s]

[INFO] Apache CloudStack Engine Storage Volume Component . SUCCESS [5.936s]

[INFO] Apache CloudStack Engine Storage Image Component .. SUCCESS [3.533s]

[INFO] Apache CloudStack Engine Storage Data Motion Compo

RE: ifconfig and MacAddress

2013-10-29 Thread Alex Huang

I can confirm the code's only there because Java didn't have it before.

--Alex

From: Laszlo Hornyak [mailto:laszlo.horn...@gmail.com]
Sent: Monday, October 28, 2013 11:50 PM
To: dev@cloudstack.apache.org
Cc: Alex Huang; Kelven Yang
Subject: Re: ifconfig and MacAddress

Hi,

I noticed other problem with the MacAddress, it appears that it does not handle 
the Windows ipconfig output.
(see related patch) https://reviews.apache.org/r/14514/ I tested it with win8, 
7, and XP outputs
As far as I remember this may be a problem when running CS cluster on windows, 
since each node determines the default as id.

On Sun, Oct 27, 2013 at 1:11 AM, Darren Shepherd 
mailto:darren.s.sheph...@gmail.com>> wrote:
Is there a specific reason that in MacAddress it uses "ifconfig" or
other utilities to grab the Mac Address as opposed to the java API
java.net.NetworkInterface?  There's a comment in that code that says
that code was copied from some public domain utility.  So I'm guessing
its there just because that's what somebody wrote back before Java 6
introduced NetworkInteface.getHardwareAddress().  I'd like to rewrite
this code to use the standard API, grab the Mac deterministically and
also not use ifconfig which was deprecated 3 years ago.

Darren

--

EOF

Re: Issues deploying with marvin

I know that I will have to change the 'nonoss' flag when I pull in the
latest master from this weekend...


On Tue, Oct 29, 2013 at 11:27 AM, Will Stevens wrote:

> When I build with:  mvn -P developer,systemvm -Dnonoss clean install -X
>
> I get the error below.  I have completely rebuilt my system from scratch
> and I still get this...  Any ideas?
>
> If I run the same command, but without the 'developer' profile, everything
> builds correctly.
> (eg: mvn -P systemvm -Dnonoss clean install -X)
>
> Are there specific requirements needed to build the developer profile?
>
> ---
>
> [INFO] Installing
> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/pom.xml to
> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/cloud-marvin-4.3.0-SNAPSHOT.pom
>
> [DEBUG] Writing resolution tracking file
> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/_maven.repositories
>
> [DEBUG] Installing
> org.apache.cloudstack:cloud-marvin:4.3.0-SNAPSHOT/maven-metadata.xml to
> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/maven-metadata-local.xml
>
> [DEBUG] Installing org.apache.cloudstack:cloud-marvin/maven-metadata.xml
> to
> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/maven-metadata-local.xml
>
> [INFO]
>
> [INFO] --- exec-maven-plugin:1.2.1:exec (install) @ cloud-marvin ---
>
> [DEBUG] Configuring mojo org.codehaus.mojo:exec-maven-plugin:1.2.1:exec
> from plugin realm
> ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent:
> sun.misc.Launcher$AppClassLoader@5acac268]
>
> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec'
> with basic configurator -->
>
> [DEBUG]   (f) arguments = [setup.py, sdist]
>
> [DEBUG]   (f) basedir =
> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin
>
> [DEBUG]   (f) classpathScope = runtime
>
> [DEBUG]   (f) executable = python
>
> [DEBUG]   (f) longClasspath = false
>
> [DEBUG]   (f) project = MavenProject:
> org.apache.cloudstack:cloud-marvin:4.3.0-SNAPSHOT @
> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/pom.xml
>
> [DEBUG]   (f) session = org.apache.maven.execution.MavenSession@6d3cba41
>
> [DEBUG]   (f) skip = false
>
> [DEBUG] -- end configuration --
>
> [DEBUG] Executing command line: python setup.py sdist
>
> running sdist
>
> running egg_info
>
> writing requirements to Marvin.egg-info/requires.txt
>
> writing Marvin.egg-info/PKG-INFO
>
> writing top-level names to Marvin.egg-info/top_level.txt
>
> writing dependency_links to Marvin.egg-info/dependency_links.txt
>
> writing entry points to Marvin.egg-info/entry_points.txt
>
> reading manifest file 'Marvin.egg-info/SOURCES.txt'
>
> reading manifest template 'MANIFEST.in'
>
> warning: no files found matching '*.txt' under directory 'docs'
>
> writing manifest file 'Marvin.egg-info/SOURCES.txt'
>
> making hard links in Marvin-0.1.0...
>
> hard linking CHANGES.txt -> Marvin-0.1.0
>
> error: Operation not permitted
>
> [INFO]
> 
>
> [INFO] Reactor Summary:
>
> [INFO]
>
> [INFO] Apache CloudStack . SUCCESS [4.341s]
>
> [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [0.089s]
>
> [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [4.999s]
>
> [INFO] Apache CloudStack Utils ... SUCCESS
> [17.555s]
>
> [INFO] Apache CloudStack Framework ... SUCCESS [0.125s]
>
> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [9.514s]
>
> [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [5.700s]
>
> [INFO] Apache CloudStack API . SUCCESS
> [26.885s]
>
> [INFO] Apache CloudStack Framework - REST  SUCCESS [3.394s]
>
> [INFO] Apache CloudStack Framework - IPC . SUCCESS [8.755s]
>
> [INFO] Apache CloudStack Cloud Engine  SUCCESS [0.091s]
>
> [INFO] Apache CloudStack Cloud Engine API  SUCCESS [7.934s]
>
> [INFO] Apache CloudStack Core  SUCCESS
> [13.925s]
>
> [INFO] Apache CloudStack Agents .. SUCCESS [7.509s]
>
> [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [4.550s]
>
> [INFO] Apache CloudStack Framework - Jobs  SUCCESS [4.811s]
>
> [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS
> [17.694s]
>
> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [2.665s]
>
> [INFO] Apache CloudStack Cloud Engine Internal Components API  SUCCESS
> [4.491s]
>
> [INFO] Apache CloudStack Server .. SUCCESS
> [56.473s]
>
> [INFO] Apache CloudStack Usage Server  SUCCESS [8.747s]
>
> [INFO] Apache XenSource XAPI . SUCCESS [8.695s]
>
> [INFO] Apache CloudStack Cloud Engine Orchestration Component  SUCCESS
> [10.341s]
>
> [INFO] Apache CloudStack Cloud Service

Re: Issues deploying with marvin

I will pull and make this change because apparently this has been in for a
little while...

I will update this if with more news when I have it.


On Tue, Oct 29, 2013 at 11:57 AM, Will Stevens wrote:

> I know that I will have to change the 'nonoss' flag when I pull in the
> latest master from this weekend...
>
>
> On Tue, Oct 29, 2013 at 11:27 AM, Will Stevens wrote:
>
>> When I build with:  mvn -P developer,systemvm -Dnonoss clean install -X
>>
>> I get the error below.  I have completely rebuilt my system from scratch
>> and I still get this...  Any ideas?
>>
>> If I run the same command, but without the 'developer' profile,
>> everything builds correctly.
>> (eg: mvn -P systemvm -Dnonoss clean install -X)
>>
>> Are there specific requirements needed to build the developer profile?
>>
>> ---
>>
>> [INFO] Installing
>> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/pom.xml to
>> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/cloud-marvin-4.3.0-SNAPSHOT.pom
>>
>> [DEBUG] Writing resolution tracking file
>> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/_maven.repositories
>>
>> [DEBUG] Installing
>> org.apache.cloudstack:cloud-marvin:4.3.0-SNAPSHOT/maven-metadata.xml to
>> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/maven-metadata-local.xml
>>
>> [DEBUG] Installing org.apache.cloudstack:cloud-marvin/maven-metadata.xml
>> to
>> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/maven-metadata-local.xml
>>
>> [INFO]
>>
>> [INFO] --- exec-maven-plugin:1.2.1:exec (install) @ cloud-marvin ---
>>
>> [DEBUG] Configuring mojo org.codehaus.mojo:exec-maven-plugin:1.2.1:exec
>> from plugin realm
>> ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent:
>> sun.misc.Launcher$AppClassLoader@5acac268]
>>
>> [DEBUG] Configuring mojo 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec'
>> with basic configurator -->
>>
>> [DEBUG]   (f) arguments = [setup.py, sdist]
>>
>> [DEBUG]   (f) basedir =
>> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin
>>
>> [DEBUG]   (f) classpathScope = runtime
>>
>> [DEBUG]   (f) executable = python
>>
>> [DEBUG]   (f) longClasspath = false
>>
>> [DEBUG]   (f) project = MavenProject:
>> org.apache.cloudstack:cloud-marvin:4.3.0-SNAPSHOT @
>> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/pom.xml
>>
>> [DEBUG]   (f) session = org.apache.maven.execution.MavenSession@6d3cba41
>>
>> [DEBUG]   (f) skip = false
>>
>> [DEBUG] -- end configuration --
>>
>> [DEBUG] Executing command line: python setup.py sdist
>>
>> running sdist
>>
>> running egg_info
>>
>> writing requirements to Marvin.egg-info/requires.txt
>>
>> writing Marvin.egg-info/PKG-INFO
>>
>> writing top-level names to Marvin.egg-info/top_level.txt
>>
>> writing dependency_links to Marvin.egg-info/dependency_links.txt
>>
>> writing entry points to Marvin.egg-info/entry_points.txt
>>
>> reading manifest file 'Marvin.egg-info/SOURCES.txt'
>>
>> reading manifest template 'MANIFEST.in'
>>
>> warning: no files found matching '*.txt' under directory 'docs'
>>
>> writing manifest file 'Marvin.egg-info/SOURCES.txt'
>>
>> making hard links in Marvin-0.1.0...
>>
>> hard linking CHANGES.txt -> Marvin-0.1.0
>>
>> error: Operation not permitted
>>
>> [INFO]
>> 
>>
>> [INFO] Reactor Summary:
>>
>> [INFO]
>>
>> [INFO] Apache CloudStack . SUCCESS
>> [4.341s]
>>
>> [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS
>> [0.089s]
>>
>> [INFO] Apache CloudStack Framework - Managed Context . SUCCESS
>> [4.999s]
>>
>> [INFO] Apache CloudStack Utils ... SUCCESS
>> [17.555s]
>>
>> [INFO] Apache CloudStack Framework ... SUCCESS
>> [0.125s]
>>
>> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
>> [9.514s]
>>
>> [INFO] Apache CloudStack Framework - Configuration ... SUCCESS
>> [5.700s]
>>
>> [INFO] Apache CloudStack API . SUCCESS
>> [26.885s]
>>
>> [INFO] Apache CloudStack Framework - REST  SUCCESS
>> [3.394s]
>>
>> [INFO] Apache CloudStack Framework - IPC . SUCCESS
>> [8.755s]
>>
>> [INFO] Apache CloudStack Cloud Engine  SUCCESS
>> [0.091s]
>>
>> [INFO] Apache CloudStack Cloud Engine API  SUCCESS
>> [7.934s]
>>
>> [INFO] Apache CloudStack Core  SUCCESS
>> [13.925s]
>>
>> [INFO] Apache CloudStack Agents .. SUCCESS
>> [7.509s]
>>
>> [INFO] Apache CloudStack Framework - Clustering .. SUCCESS
>> [4.550s]
>>
>> [INFO] Apache CloudStack Framework - Jobs  SUCCESS
>> [4.811s]
>>
>> [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS
>> [17.694s]
>>
>> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
>> [2.665s]
>>
>> [INFO] Apache CloudStack Cloud Engine Internal Components API

RE: [Merge] hyperv branch to master

2013-10-29 Thread Rajesh Battala

+1.

Thanks
Rajesh Battala

-Original Message-
From: Devdeep Singh 
Sent: Monday, October 28, 2013 5:11 PM
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: [Merge] hyperv branch to master

Hi,

I would like to merge the support for Hyperv to the master branch. Development 
for this has been done by Donal, Rajesh, Anshul and I on branch [1]. The 
feature was proposed for merge earlier [3] but unit tests for hyperv agent code 
were requested [4].

Checklist:
The development for the feature was earlier done in branch [2] but later moved 
to [1].
Jira ticket for the feature is here [5].
The FS can be found at [6] and [7].
Unit tests for the feature are available at [8]

This link [7] also provides details of third party libraries used by the plugin 
including their licenses. No source for these libraries is used, and the 
binaries are downloaded from their distributors at build time. No proprietary 
tools are required for the build.  For instance, C# compiled with Mono has been 
tested. Mono setup details can be found here [9].

[1] 
https://git-wip-us.apache.org/repos/asf/cloudstack/repo?p=cloudstack.git;a=shortlog;h=refs/heads/hyperv
[2] https://github.com/lafferty/cloudstack/tree/hyperv_plugin
[3] 
http://markmail.org/message/cm7kdwh6l2ea772e?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Minimal+Hyperv+plugin
[4] 
http://markmail.org/message/vxknappvyovhmeyp?q=list:org%2Eapache%2Eincubator%2Ecloudstack-%2A+Minimal+Hyperv+plugin&page=3
[5] https://issues.apache.org/jira/browse/CLOUDSTACK-999
[6] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hyper-V+2012+%283.0%29+Support
[7] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Progress
[8] 
https://git-wip-us.apache.org/repos/asf/cloudstack/repo?p=cloudstack.git;a=blob;f=plugins/hypervisors/hyperv/DotNet/ServerResource/ServerResource.Tests/HypervResourceController1Test.cs;h=ec91e9ff21742bde78873ed7cee49f2423e425b9;hb=refs/heads/hyperv
[9] 
http://dlafferty.blogspot.co.uk/2013/08/building-your-microsoft-solution-with.html

Regards,
Devdeep

Re: listVolumes pool id

2013-10-29 Thread Alena Prokharchyk

Marcus,

I fixed it in the latest master code some time ago. The parameter is returned 
to the ROOT admin only as only the user of this type knows the DC details 
(hosts, storage pools, networks, etc).

-Alena.

From: Marcus Sorensen mailto:shadow...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, October 29, 2013 7:21 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: listVolumes pool id

I almost can't believe this doesn't already exist, but I noticed that
listing a volume doesn't show you the id of the storage pool the
volume belongs to. It shows the pool name, but it seems that doesn't
have to be unique.  Does anyone have a problem with me adding that to
the listVolumes response?  Are there any tests that might fail due to
hardcoded response expectations?

Re: [Merge] hyperv branch to master

2013-10-29 Thread David Nalley

On Mon, Oct 28, 2013 at 7:41 AM, Devdeep Singh  wrote:
> Hi,
>
> I would like to merge the support for Hyperv to the master branch. 
> Development for this has been done by Donal, Rajesh, Anshul and I on branch 
> [1]. The feature was proposed for merge earlier [3] but unit tests for hyperv 
> agent code were requested [4].
>

I know this has been discussed several times, but what was the
decision about making the agent code live in its own repo?
It's C#, might need to be signed to actually run easily on Windows, etc.

--David

[MERGE] network-guru-orchestration into master

2013-10-29 Thread Hugo Trippaers

Hey guys,

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

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

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

What do you guys think?

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

Cheers,

Hugo

Re: Review Request 15012: CLOUDSTACK-4984: decrement MAX_VXLAN_VNI to be aligned with Linux kernel


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

Ship it!


Toshiaki, please commit.

- Marcus Sorensen


On Oct. 29, 2013, 5 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15012/
> ---
> 
> (Updated Oct. 29, 2013, 5 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Linux vxlan interface doesn't accept VNI:16777215.
> https://github.com/torvalds/linux/blob/master/drivers/net/vxlan.c#L2140
> 
> As far as I read internet draft ( 
> http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-05 ),
> 16777215 is a valid VNI, but it cannot be used in Linux now.
> 
> This patch decrements MAX_VXLAN_VNI to 16777214.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/network/NetworkServiceImpl.java 61c070a 
> 
> Diff: https://reviews.apache.org/r/15012/diff/
> 
> 
> Testing
> ---
> 
> I confirmed VNI validation works by specifying 16777215-16777215 to id range 
> via add zone wizard.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix

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

(Updated Oct. 29, 2013, 4:48 p.m.)

Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.

Changes
---

Updated to validate VNI range isn't used on a different physical network in
zone. Tested with VNI 3000-3500 on guest eth0 and VNI 3500-4000 on guest eth2.
This failed with "VNI 3500 already exists on another network in zone, please
specify a unique range". Changing physical net eth2's range to 3501-4000 was
success. Editing ranges similarly throws the error.

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

Repository: cloudstack-git

Description
---

1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can
host guest traffic type with vxlan isolation, so long as they don't use the
same VNI range.

2) Guest traffic labels can be physical interface if bridge by given name is
not found. Normally we take traffic label name, find the matching bridge, then
resolve that to a physical interface. Then we create guest bridges on that
interface. Now we can just specify the interface.

This patch may need some refinement, but I want to get it to the vxlan devs for
review.

Diffs (updated)
-

plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
f945b74

plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
286d0f7
scripts/vm/network/vnet/modifyvxlan.sh a3ec71f
server/src/com/cloud/network/NetworkServiceImpl.java cf419f3

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

Testing
---

I created two physical networks hosting guest traffic, one as a vlan isolation
type, the other a vxlan isolation type. The vlan isolation type has traffic
label 'cloudbr0', on physical eth0, and the vxlan has traffic label 'eth2' on
physical network eth2.

This patch would still allow multiple guest networks to use vxlan isolation,
just not the same VNI numbers. It doesn't enforce this though.

Here they are running side by side:

root@devcloud-kvm-u:~# brctl show
bridge name bridge id STP enabled interfaces
breth0-3905 8000.000c29d82947 no eth0.3905
vnet8
brvx-12130438000.a6e6026f7fbb no vnet9
vxlan1213043
brvx-15891698000.663d4e875e78 no vnet10
vxlan1589169
cloud0 8000.fe00a9fe0069 no vnet0
vnet2
vnet3
cloudbr08000.000c29d82947 no eth0
vnet4
vnet6
cloudbr18000.000c29d82951 no eth1
vnet1
vnet5
vnet7

root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
56: vxlan1213043: mtu 1450 qdisc noqueue
master brvx-1213043 state UNKNOWN mode DEFAULT group default
vxlan id 1213043 group 239.18.130.115 dev eth2 port 32768 61000 ttl 10
ageing 300
59: vxlan1589169: mtu 1450 qdisc noqueue
master brvx-1589169 state UNKNOWN mode DEFAULT group default
vxlan id 1589169 group 239.24.63.177 dev eth2 port 32768 61000 ttl 10
ageing 300
62: vxlan1638510: mtu 1450 qdisc noqueue
master brvx-1638510 state UNKNOWN mode DEFAULT group default
vxlan id 1638510 group 239.25.0.110 dev eth2 port 32768 61000 ttl 10 ageing
300
root@devcloud-kvm-u:~/cloudstack# ip route show
default via 192.168.100.1 dev cloudbr1 metric 100
169.254.0.0/16 dev cloud0 proto kernel scope link src 169.254.0.1
172.17.10.0/24 dev cloudbr0 proto kernel scope link src 172.17.10.10
192.168.100.0/24 dev cloudbr1 proto kernel scope link src 192.168.100.10
239.18.130.115 dev eth2 scope link
239.24.63.177 dev eth2 scope link
239.25.0.110 dev eth2 scope link

Thanks,

Marcus Sorensen

Re: listVolumes pool id

Thanks!

On Tue, Oct 29, 2013 at 10:23 AM, Alena Prokharchyk
 wrote:
> Marcus,
>
> I fixed it in the latest master code some time ago. The parameter is returned 
> to the ROOT admin only as only the user of this type knows the DC details 
> (hosts, storage pools, networks, etc).
>
> -Alena.
>
> From: Marcus Sorensen mailto:shadow...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Date: Tuesday, October 29, 2013 7:21 AM
> To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Subject: listVolumes pool id
>
> I almost can't believe this doesn't already exist, but I noticed that
> listing a volume doesn't show you the id of the storage pool the
> volume belongs to. It shows the pool name, but it seems that doesn't
> have to be unique.  Does anyone have a problem with me adding that to
> the listVolumes response?  Are there any tests that might fail due to
> hardcoded response expectations?
>

Re: Issues deploying with marvin

I believe the issues I am running into stem from the fact that the CS code
is in a shared directory from my Mac to VMware Fusion.  Because of this the
'ln' command is failing when building marvin...

I may have to find a work around for this problem in order to build the
developer profile.

Will


On Tue, Oct 29, 2013 at 11:59 AM, Will Stevens wrote:

> I will pull and make this change because apparently this has been in for a
> little while...
>
> I will update this if with more news when I have it.
>
>
> On Tue, Oct 29, 2013 at 11:57 AM, Will Stevens wrote:
>
>> I know that I will have to change the 'nonoss' flag when I pull in the
>> latest master from this weekend...
>>
>>
>> On Tue, Oct 29, 2013 at 11:27 AM, Will Stevens wrote:
>>
>>> When I build with:  mvn -P developer,systemvm -Dnonoss clean install -X
>>>
>>> I get the error below.  I have completely rebuilt my system from scratch
>>> and I still get this...  Any ideas?
>>>
>>> If I run the same command, but without the 'developer' profile,
>>> everything builds correctly.
>>> (eg: mvn -P systemvm -Dnonoss clean install -X)
>>>
>>> Are there specific requirements needed to build the developer profile?
>>>
>>> ---
>>>
>>> [INFO] Installing
>>> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/pom.xml to
>>> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/cloud-marvin-4.3.0-SNAPSHOT.pom
>>>
>>> [DEBUG] Writing resolution tracking file
>>> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/_maven.repositories
>>>
>>> [DEBUG] Installing
>>> org.apache.cloudstack:cloud-marvin:4.3.0-SNAPSHOT/maven-metadata.xml to
>>> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/4.3.0-SNAPSHOT/maven-metadata-local.xml
>>>
>>> [DEBUG] Installing org.apache.cloudstack:cloud-marvin/maven-metadata.xml
>>> to
>>> /root/.m2/repository/org/apache/cloudstack/cloud-marvin/maven-metadata-local.xml
>>>
>>> [INFO]
>>>
>>> [INFO] --- exec-maven-plugin:1.2.1:exec (install) @ cloud-marvin ---
>>>
>>> [DEBUG] Configuring mojo org.codehaus.mojo:exec-maven-plugin:1.2.1:exec
>>> from plugin realm
>>> ClassRealm[plugin>org.codehaus.mojo:exec-maven-plugin:1.2.1, parent:
>>> sun.misc.Launcher$AppClassLoader@5acac268]
>>>
>>> [DEBUG] Configuring mojo
>>> 'org.codehaus.mojo:exec-maven-plugin:1.2.1:exec' with basic configurator -->
>>>
>>> [DEBUG]   (f) arguments = [setup.py, sdist]
>>>
>>> [DEBUG]   (f) basedir =
>>> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin
>>>
>>> [DEBUG]   (f) classpathScope = runtime
>>>
>>> [DEBUG]   (f) executable = python
>>>
>>> [DEBUG]   (f) longClasspath = false
>>>
>>> [DEBUG]   (f) project = MavenProject:
>>> org.apache.cloudstack:cloud-marvin:4.3.0-SNAPSHOT @
>>> /mnt/hgfs/palo_alto/incubator-cloudstack/tools/marvin/pom.xml
>>>
>>> [DEBUG]   (f) session = org.apache.maven.execution.MavenSession@6d3cba41
>>>
>>> [DEBUG]   (f) skip = false
>>>
>>> [DEBUG] -- end configuration --
>>>
>>> [DEBUG] Executing command line: python setup.py sdist
>>>
>>> running sdist
>>>
>>> running egg_info
>>>
>>> writing requirements to Marvin.egg-info/requires.txt
>>>
>>> writing Marvin.egg-info/PKG-INFO
>>>
>>> writing top-level names to Marvin.egg-info/top_level.txt
>>>
>>> writing dependency_links to Marvin.egg-info/dependency_links.txt
>>>
>>> writing entry points to Marvin.egg-info/entry_points.txt
>>>
>>> reading manifest file 'Marvin.egg-info/SOURCES.txt'
>>>
>>> reading manifest template 'MANIFEST.in'
>>>
>>> warning: no files found matching '*.txt' under directory 'docs'
>>>
>>> writing manifest file 'Marvin.egg-info/SOURCES.txt'
>>>
>>> making hard links in Marvin-0.1.0...
>>>
>>> hard linking CHANGES.txt -> Marvin-0.1.0
>>>
>>> error: Operation not permitted
>>>
>>> [INFO]
>>> 
>>>
>>> [INFO] Reactor Summary:
>>>
>>> [INFO]
>>>
>>> [INFO] Apache CloudStack . SUCCESS
>>> [4.341s]
>>>
>>> [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS
>>> [0.089s]
>>>
>>> [INFO] Apache CloudStack Framework - Managed Context . SUCCESS
>>> [4.999s]
>>>
>>> [INFO] Apache CloudStack Utils ... SUCCESS
>>> [17.555s]
>>>
>>> [INFO] Apache CloudStack Framework ... SUCCESS
>>> [0.125s]
>>>
>>> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
>>> [9.514s]
>>>
>>> [INFO] Apache CloudStack Framework - Configuration ... SUCCESS
>>> [5.700s]
>>>
>>> [INFO] Apache CloudStack API . SUCCESS
>>> [26.885s]
>>>
>>> [INFO] Apache CloudStack Framework - REST  SUCCESS
>>> [3.394s]
>>>
>>> [INFO] Apache CloudStack Framework - IPC . SUCCESS
>>> [8.755s]
>>>
>>> [INFO] Apache CloudStack Cloud Engine  SUCCESS
>>> [0.091s]
>>>
>>> [INFO] Apache CloudStack Cloud Engine API  SUCCESS
>>> [7.934s]
>>>
>>> [INFO] Apache CloudStack Core  SUCCESS

Re: listVolumes pool id

2013-10-29 Thread Nitin Mehta

I guess it should be fine. Adding a parameter shouldn't break the
compatibility and if it does then it should be corrected from the client
side.

On 29/10/13 7:21 AM, "Marcus Sorensen"  wrote:

>I almost can't believe this doesn't already exist, but I noticed that
>listing a volume doesn't show you the id of the storage pool the
>volume belongs to. It shows the pool name, but it seems that doesn't
>have to be unique.  Does anyone have a problem with me adding that to
>the listVolumes response?  Are there any tests that might fail due to
>hardcoded response expectations?

Re: [Merge] hyperv branch to master

2013-10-29 Thread Darren Shepherd

+1

When you merge you will get a conflict in the spring configuration.
componentContext.xml and others are gone now in master.  You will need
to update to the new style.  The easiest will be to refer to XenServer
spring config for an example of how to do it.  You can largely copy
and paste the contents of
plugins/hypervisors/xen/resources/META-INF/cloudstack and replace
xenserver with hyperv.  You can also refer to
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Plug-ins%2C+Modules%2C+and+Extensions
for more in depth explaination of the changes.

Darren

On Tue, Oct 29, 2013 at 9:35 AM, David Nalley  wrote:
> On Mon, Oct 28, 2013 at 7:41 AM, Devdeep Singh  
> wrote:
>> Hi,
>>
>> I would like to merge the support for Hyperv to the master branch. 
>> Development for this has been done by Donal, Rajesh, Anshul and I on branch 
>> [1]. The feature was proposed for merge earlier [3] but unit tests for 
>> hyperv agent code were requested [4].
>>
>
> I know this has been discussed several times, but what was the
> decision about making the agent code live in its own repo?
> It's C#, might need to be signed to actually run easily on Windows, etc.
>
> --David

Re: [Merge] hyperv branch to master

2013-10-29 Thread Chiradeep Vittal

That could be a decision to put off for later.
The release process deals with single repos for now.
The signing will come up during the build right? How do other OSS C#
projects deal with it?
Perhaps they release binaries in addition to source?

On 10/29/13 9:35 AM, "David Nalley"  wrote:

>On Mon, Oct 28, 2013 at 7:41 AM, Devdeep Singh 
>wrote:
>> Hi,
>>
>> I would like to merge the support for Hyperv to the master branch.
>>Development for this has been done by Donal, Rajesh, Anshul and I on
>>branch [1]. The feature was proposed for merge earlier [3] but unit
>>tests for hyperv agent code were requested [4].
>>
>
>I know this has been discussed several times, but what was the
>decision about making the agent code live in its own repo?
>It's C#, might need to be signed to actually run easily on Windows, etc.
>
>--David

Re: [Merge] hyperv branch to master

2013-10-29 Thread David Nalley

Well - other projects within the ASF are finding a need to 'sign'
their convenience binaries, and folks are exploring those options now
to find something workable.

Why put it off? Creating a repo takes 5 minutes. IF putting it in its
own repo and adjusting our release processes is the right thing to do,
I'd rather do it now than later. If it isn't the right thing to do,
then staying put is fine as well.

--David

On Tue, Oct 29, 2013 at 1:29 PM, Chiradeep Vittal
 wrote:
> That could be a decision to put off for later.
> The release process deals with single repos for now.
> The signing will come up during the build right? How do other OSS C#
> projects deal with it?
> Perhaps they release binaries in addition to source?
>
> On 10/29/13 9:35 AM, "David Nalley"  wrote:
>
>>On Mon, Oct 28, 2013 at 7:41 AM, Devdeep Singh 
>>wrote:
>>> Hi,
>>>
>>> I would like to merge the support for Hyperv to the master branch.
>>>Development for this has been done by Donal, Rajesh, Anshul and I on
>>>branch [1]. The feature was proposed for merge earlier [3] but unit
>>>tests for hyperv agent code were requested [4].
>>>
>>
>>I know this has been discussed several times, but what was the
>>decision about making the agent code live in its own repo?
>>It's C#, might need to be signed to actually run easily on Windows, etc.
>>
>>--David
>

Re: ifconfig and MacAddress

2013-10-29 Thread Kelven Yang

Windows ipconfig is not supported, a fix is welcome.

To run a CS management server cluster on Windows. manual configuration is 
required. cluster.node.ip needs to configured correctly in db.properties

Kelven

From: Alex Huang mailto:alex.hu...@citrix.com>>
Date: Tuesday, October 29, 2013 at 8:43 AM
To: Laszlo Hornyak mailto:laszlo.horn...@gmail.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: Kelven Yang mailto:kelven.y...@citrix.com>>
Subject: RE: ifconfig and MacAddress

I can confirm the code’s only there because Java didn’t have it before.

--Alex

From: Laszlo Hornyak [mailto:laszlo.horn...@gmail.com]
Sent: Monday, October 28, 2013 11:50 PM
To: dev@cloudstack.apache.org
Cc: Alex Huang; Kelven Yang
Subject: Re: ifconfig and MacAddress

Hi,

I noticed other problem with the MacAddress, it appears that it does not handle 
the Windows ipconfig output.
(see related patch) https://reviews.apache.org/r/14514/ I tested it with win8, 
7, and XP outputs
As far as I remember this may be a problem when running CS cluster on windows, 
since each node determines the default as id.

On Sun, Oct 27, 2013 at 1:11 AM, Darren Shepherd 
mailto:darren.s.sheph...@gmail.com>> wrote:
Is there a specific reason that in MacAddress it uses "ifconfig" or
other utilities to grab the Mac Address as opposed to the java API
java.net.NetworkInterface?  There's a comment in that code that says
that code was copied from some public domain utility.  So I'm guessing
its there just because that's what somebody wrote back before Java 6
introduced NetworkInteface.getHardwareAddress().  I'd like to rewrite
this code to use the standard API, grab the Mac deterministically and
also not use ifconfig which was deprecated 3 years ago.

Darren

--

EOF

Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix


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



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


'");' seems gone.


- Yoshikazu Nojima


On Oct. 29, 2013, 4:48 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15014/
> ---
> 
> (Updated Oct. 29, 2013, 4:48 p.m.)
> 
> 
> Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can 
> host guest traffic type with vxlan isolation, so long as they don't use the 
> same VNI range.
> 
> 2) Guest traffic labels can be physical interface if bridge by given name is 
> not found. Normally we take traffic label name, find the matching bridge, 
> then resolve that to a physical interface. Then we create guest bridges on 
> that interface. Now we can just specify the interface.
> 
> This patch may need some refinement, but I want to get it to the vxlan devs 
> for review.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  286d0f7 
>   scripts/vm/network/vnet/modifyvxlan.sh a3ec71f 
>   server/src/com/cloud/network/NetworkServiceImpl.java cf419f3 
> 
> Diff: https://reviews.apache.org/r/15014/diff/
> 
> 
> Testing
> ---
> 
> I created two physical networks hosting guest traffic, one as a vlan 
> isolation type, the other a vxlan isolation type. The vlan isolation type has 
> traffic label 'cloudbr0', on physical eth0, and the vxlan has traffic label 
> 'eth2' on physical network eth2.
> 
> This patch would still allow multiple guest networks to use vxlan isolation, 
> just not the same VNI numbers. It doesn't enforce this though.
> 
> Here they are running side by side:
> 
> root@devcloud-kvm-u:~# brctl show
> bridge name   bridge id   STP enabled interfaces
> breth0-3905   8000.000c29d82947   no  eth0.3905
>   vnet8
> brvx-1213043  8000.a6e6026f7fbb   no  vnet9
>   vxlan1213043
> brvx-1589169  8000.663d4e875e78   no  vnet10
>   vxlan1589169
> cloud08000.fe00a9fe0069   no  vnet0
>   vnet2
>   vnet3
> cloudbr0  8000.000c29d82947   no  eth0
>   vnet4
>   vnet6
> cloudbr1  8000.000c29d82951   no  eth1
>   vnet1
>   vnet5
>   vnet7
> 
> root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
> 56: vxlan1213043:  mtu 1450 qdisc noqueue 
> master brvx-1213043 state UNKNOWN mode DEFAULT group default
> vxlan id 1213043 group 239.18.130.115 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> 59: vxlan1589169:  mtu 1450 qdisc noqueue 
> master brvx-1589169 state UNKNOWN mode DEFAULT group default
> vxlan id 1589169 group 239.24.63.177 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> 62: vxlan1638510:  mtu 1450 qdisc noqueue 
> master brvx-1638510 state UNKNOWN mode DEFAULT group default
> vxlan id 1638510 group 239.25.0.110 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> root@devcloud-kvm-u:~/cloudstack# ip route show
> default via 192.168.100.1 dev cloudbr1  metric 100
> 169.254.0.0/16 dev cloud0  proto kernel  scope link  src 169.254.0.1
> 172.17.10.0/24 dev cloudbr0  proto kernel  scope link  src 172.17.10.10
> 192.168.100.0/24 dev cloudbr1  proto kernel  scope link  src 192.168.100.10
> 239.18.130.115 dev eth2  scope link
> 239.24.63.177 dev eth2  scope link
> 239.25.0.110 dev eth2  scope link
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>

Re: LXC and SSVM/CPVM on the host

2013-10-29 Thread Kelven Yang

It looks like a LXC resource agent bug. LXC resource agent needs to
respond VNC command correctly in order to get console work on LXC.

Could you file a bug against LXC resource agent component?

Kelven

On 10/29/13, 7:13 AM, "Francois Gaudreault" 
wrote:

>Kelven,
>
>This is what I get in the LXC host agent log when I try to check the
>console from CS:
>
>2013-10-29 10:07:42,079 WARN  [cloud.agent.Agent]
>(agentRequest-Handler-4:null) Caught:
>java.lang.NullPointerException
> at 
>com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(Libvirt
>ComputingResource.java:2711)
> at 
>com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(
>LibvirtComputingResource.java:1216)
> at com.cloud.agent.Agent.processRequest(Agent.java:525)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
> at com.cloud.utils.nio.Task.run(Task.java:83)
> 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:744)
>
>This is the error on the CS side:
>
>2013-10-29 10:12:58,215 DEBUG [agent.manager.AgentManagerImpl]
>(catalina-exec-16:null) Details from executing class
>com.cloud.agent.api.GetVncPortCommand: java.lang.NullPointerException
> at 
>com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(Libvirt
>ComputingResource.java:2711)
> at 
>com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(
>LibvirtComputingResource.java:1216)
> at com.cloud.agent.Agent.processRequest(Agent.java:525)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
> at com.cloud.utils.nio.Task.run(Task.java:83)
> 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:744)
>
>2013-10-29 10:12:58,215 ERROR [cloud.servlet.ConsoleProxyServlet]
>(catalina-exec-16:null) Unexepected exception in ConsoleProxyServlet
>java.lang.ClassCastException: com.cloud.agent.api.Answer cannot be cast
>to com.cloud.agent.api.GetVncPortAnswer
> at 
>com.cloud.server.ManagementServerImpl.getVncPort(ManagementServerImpl.java
>:2193)
> at 
>com.cloud.servlet.ConsoleProxyServlet.composeConsoleAccessUrl(ConsoleProxy
>Servlet.java:381)
> at 
>com.cloud.servlet.ConsoleProxyServlet.handleAccessRequest(ConsoleProxyServ
>let.java:269)
> at 
>com.cloud.servlet.ConsoleProxyServlet.doGet(ConsoleProxyServlet.java:171)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at 
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>onFilterChain.java:290)
> at 
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.java:206)
> at 
>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
>java:233)
> at 
>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
>java:191)
> at 
>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
>27)
> at 
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
>02)
> at 
>org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
> at 
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
>va:109)
> at 
>org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298
>)
> at 
>org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.jav
>a:889)
> at 
>org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process
>(Http11NioProtocol.java:721)
> at 
>org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.jav
>a:2268)
> at 
>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
>1146)
> at 
>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
>:615)
> at java.lang.Thread.run(Thread.java:679)
>
>
>On 10/28/2013, 9:05 PM, Kelven Yang wrote:
>> As long as the container VNC console is reachable from console proxy
>> agent, I don't see a technical issue here. Need some log details to
>> understand the situation. For example, what information does LXC
>> hypervisor resource agent returns on GetVncPort command?
>>
>> Kelven
>>   
>>
>> On 10/28/13 10:59 AM, "Francois Gaudreault" 
>> wrote:
>>
>>> Thanks! Is the console proxy issue will be fixed at some point in the
>>> future or this won't be possible?
>>>
>>> Francois
>>>
>>> On 10/28/2013, 1:57 PM, Phong Nguyen wrote:
 Yes, the console proxy VM is unable to connect to the LXC console. Use
 virsh to connect from the host.

 virsh -c lxc:/// console i-2-20-VM

 -Phong


 On Mon, Oct 28, 2013 at

Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix


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

(Updated Oct. 29, 2013, 5:51 p.m.)


Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.


Changes
---

Fix mangled patch formatting.


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


Repository: cloudstack-git


Description
---

1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can 
host guest traffic type with vxlan isolation, so long as they don't use the 
same VNI range.

2) Guest traffic labels can be physical interface if bridge by given name is 
not found. Normally we take traffic label name, find the matching bridge, then 
resolve that to a physical interface. Then we create guest bridges on that 
interface. Now we can just specify the interface.

This patch may need some refinement, but I want to get it to the vxlan devs for 
review.


Diffs (updated)
-

  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
 f945b74 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 286d0f7 
  scripts/vm/network/vnet/modifyvxlan.sh a3ec71f 
  server/src/com/cloud/network/NetworkServiceImpl.java cf419f3 

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


Testing
---

I created two physical networks hosting guest traffic, one as a vlan isolation 
type, the other a vxlan isolation type. The vlan isolation type has traffic 
label 'cloudbr0', on physical eth0, and the vxlan has traffic label 'eth2' on 
physical network eth2.

This patch would still allow multiple guest networks to use vxlan isolation, 
just not the same VNI numbers. It doesn't enforce this though.

Here they are running side by side:

root@devcloud-kvm-u:~# brctl show
bridge name bridge id   STP enabled interfaces
breth0-3905 8000.000c29d82947   no  eth0.3905
vnet8
brvx-12130438000.a6e6026f7fbb   no  vnet9
vxlan1213043
brvx-15891698000.663d4e875e78   no  vnet10
vxlan1589169
cloud0  8000.fe00a9fe0069   no  vnet0
vnet2
vnet3
cloudbr08000.000c29d82947   no  eth0
vnet4
vnet6
cloudbr18000.000c29d82951   no  eth1
vnet1
vnet5
vnet7

root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
56: vxlan1213043:  mtu 1450 qdisc noqueue 
master brvx-1213043 state UNKNOWN mode DEFAULT group default
vxlan id 1213043 group 239.18.130.115 dev eth2 port 32768 61000 ttl 10 
ageing 300
59: vxlan1589169:  mtu 1450 qdisc noqueue 
master brvx-1589169 state UNKNOWN mode DEFAULT group default
vxlan id 1589169 group 239.24.63.177 dev eth2 port 32768 61000 ttl 10 
ageing 300
62: vxlan1638510:  mtu 1450 qdisc noqueue 
master brvx-1638510 state UNKNOWN mode DEFAULT group default
vxlan id 1638510 group 239.25.0.110 dev eth2 port 32768 61000 ttl 10 ageing 
300
root@devcloud-kvm-u:~/cloudstack# ip route show
default via 192.168.100.1 dev cloudbr1  metric 100
169.254.0.0/16 dev cloud0  proto kernel  scope link  src 169.254.0.1
172.17.10.0/24 dev cloudbr0  proto kernel  scope link  src 172.17.10.10
192.168.100.0/24 dev cloudbr1  proto kernel  scope link  src 192.168.100.10
239.18.130.115 dev eth2  scope link
239.24.63.177 dev eth2  scope link
239.25.0.110 dev eth2  scope link


Thanks,

Marcus Sorensen

Re: Review Request 15021: Fixed Bug: 4899 : Added Configuration Support to Marvin.

2013-10-29 Thread Santhosh Edukulla


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

(Updated Oct. 29, 2013, 6 p.m.)


Review request for cloudstack and Prasanna Santhanam.


Repository: cloudstack-git


Description (updated)
---

 Added Configuration Support to Marvin.

1. It provides the basic configuration facilities to marvin.

2. User can just add configuration files for his tests, deployment
  etc, under one config folder before running their tests.
  cs/tools/marvin/marvin/config.
  They can remove all hard coded values from code and separate
  it out as config at this location.
  Either add this to the existing setup.cfg as separate section
  or add new configuration.
3. This will thus removes hard coded tests and separate
  data from tests.

4. This API is provided as an additional facility under
  cloudstackTestClient and users can get the
  configuration object as similar to apiclient,dbconnection
  etc to drive their test.

5. They just add their configuration for a test,
  setup etc,at one single place under configuration dir
  and use "getConfigParser" API of cloudstackTestClient
  It will give them "configObj".They can either pass their own
  config file for parsing to "getConfig" or it will use
  default config file @ config/setup.cfg.
6. They will then get the dictionary of parsed
  configuration and can use it further to drive their tests or
  config drive
7. Test features, can  drive their setups thus removing hard coded
  values. Configuration default file will be under config and as
  setup.cfg.
8. Users can use their own configuration file passed to
  "getConfig" API,once configObj is returned.

Another such case where we are using sed or bash script is  in between a build 
run for replacing hard coded ldap ip for region\setup specific. We can now 
change all parameters before run under configuration, the test features will 
use configuration object and thus values, rather hard coded strings which 
avoids replacement through shell script.

 Also, did few naming convention changes. Its better to follow uniform naming 
conventions. Currently, wherever iam seeing a specific notation not followed. 
We are incorporating those changes.

ToDo:
clean up of current config at places, making configuration required for 
marvin\tests unified and available at one place and clean up of files\code 
related to it. 


Diffs
-

  tools/marvin/marvin/cloudstackTestClient.py be93f35 
  tools/marvin/marvin/config/setup.cfg PRE-CREATION 
  tools/marvin/marvin/configGenerator.py 0cfad30 
  tools/marvin/marvin/integration/lib/utils.py 7d662af 

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


Testing
---

Basic check to retrieve configuration values is done.


Thanks,

Santhosh Edukulla

Re: LXC and SSVM/CPVM on the host

2013-10-29 Thread Francois Gaudreault


Filed as : https://issues.apache.org/jira/browse/CLOUDSTACK-4990

On 10/29/2013, 1:45 PM, Kelven Yang wrote:

It looks like a LXC resource agent bug. LXC resource agent needs to
respond VNC command correctly in order to get console work on LXC.

Could you file a bug against LXC resource agent component?

Kelven

On 10/29/13, 7:13 AM, "Francois Gaudreault" 
wrote:


Kelven,

This is what I get in the LXC host agent log when I try to check the
console from CS:

2013-10-29 10:07:42,079 WARN  [cloud.agent.Agent]
(agentRequest-Handler-4:null) Caught:
java.lang.NullPointerException
 at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(Libvirt
ComputingResource.java:2711)
 at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(
LibvirtComputingResource.java:1216)
 at com.cloud.agent.Agent.processRequest(Agent.java:525)
 at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
 at com.cloud.utils.nio.Task.run(Task.java:83)
 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:744)

This is the error on the CS side:

2013-10-29 10:12:58,215 DEBUG [agent.manager.AgentManagerImpl]
(catalina-exec-16:null) Details from executing class
com.cloud.agent.api.GetVncPortCommand: java.lang.NullPointerException
 at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(Libvirt
ComputingResource.java:2711)
 at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(
LibvirtComputingResource.java:1216)
 at com.cloud.agent.Agent.processRequest(Agent.java:525)
 at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
 at com.cloud.utils.nio.Task.run(Task.java:83)
 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:744)

2013-10-29 10:12:58,215 ERROR [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-16:null) Unexepected exception in ConsoleProxyServlet
java.lang.ClassCastException: com.cloud.agent.api.Answer cannot be cast
to com.cloud.agent.api.GetVncPortAnswer
 at
com.cloud.server.ManagementServerImpl.getVncPort(ManagementServerImpl.java
:2193)
 at
com.cloud.servlet.ConsoleProxyServlet.composeConsoleAccessUrl(ConsoleProxy
Servlet.java:381)
 at
com.cloud.servlet.ConsoleProxyServlet.handleAccessRequest(ConsoleProxyServ
let.java:269)
 at
com.cloud.servlet.ConsoleProxyServlet.doGet(ConsoleProxyServlet.java:171)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
onFilterChain.java:290)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
Chain.java:206)
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
java:233)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
java:191)
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
27)
 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
02)
 at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
va:109)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298
)
 at
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.jav
a:889)
 at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process
(Http11NioProtocol.java:721)
 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.jav
a:2268)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
1146)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
:615)
 at java.lang.Thread.run(Thread.java:679)


On 10/28/2013, 9:05 PM, Kelven Yang wrote:

As long as the container VNC console is reachable from console proxy
agent, I don't see a technical issue here. Need some log details to
understand the situation. For example, what information does LXC
hypervisor resource agent returns on GetVncPort command?

Kelven
   


On 10/28/13 10:59 AM, "Francois Gaudreault" 
wrote:


Thanks! Is the console proxy issue will be fixed at some point in the
future or this won't be possible?

Francois

On 10/28/2013, 1:57 PM, Phong Nguyen wrote:

Yes, the console proxy VM is unable to connect to the LXC console. Use
virsh to connect from the host.

virsh -c lxc:/// console i-2-20-VM

-Phong


On Mon, Oct 28, 2013 at 1:22 PM, Francois Gaudreault
mailto:fgaudrea...@cloudops.com>> wrote:

  Ok, I followed Chiradeep's commen

Re: Review Request 14319: CLOUDSTACK 2238: Automation - Non Contiguous VLAN Ranges


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

Ship it!


- SrikanteswaraRao Talluri


On Oct. 24, 2013, 2:07 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14319/
> ---
> 
> (Updated Oct. 24, 2013, 2:07 p.m.)
> 
> 
> Review request for cloudstack, bharat kumar and sanjeev n.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Adding Automation test cases for feature - Non Contiguous VLAN ranges
> CLOUDSTACk 2238.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_non_contiguous_vlan.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/14319/diff/
> 
> 
> Testing
> ---
> 
> Tested again after review changes:
> 
> Log:
> 
> test_01_add_non_contiguous_ranges 
> (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok
> test_02_add_existing_vlan_range 
> (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok
> test_03_extend_contiguous_range 
> (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok
> test_04_remove_unused_range 
> (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok
> test_05_remove_used_range 
> (test_non_contiguous_vlan.TestNonContiguousVLANRanges) ... ok
> 
> --
> Ran 5 tests in 345.586s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix


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



plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java


I feel odds with the parameter name 'trafficLabel'.
In L.135, you specify "public" to this parameter, but is it trafficLabel?
I'm not familiar with CloudStack terminology, but in my understanding, it 
is trafic type.

I think leaving 2nd parameter "nic" and making pif lookup logic outside of 
this method are better. 

How do you think?




- Yoshikazu Nojima


On Oct. 29, 2013, 5:51 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15014/
> ---
> 
> (Updated Oct. 29, 2013, 5:51 p.m.)
> 
> 
> Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can 
> host guest traffic type with vxlan isolation, so long as they don't use the 
> same VNI range.
> 
> 2) Guest traffic labels can be physical interface if bridge by given name is 
> not found. Normally we take traffic label name, find the matching bridge, 
> then resolve that to a physical interface. Then we create guest bridges on 
> that interface. Now we can just specify the interface.
> 
> This patch may need some refinement, but I want to get it to the vxlan devs 
> for review.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  286d0f7 
>   scripts/vm/network/vnet/modifyvxlan.sh a3ec71f 
>   server/src/com/cloud/network/NetworkServiceImpl.java cf419f3 
> 
> Diff: https://reviews.apache.org/r/15014/diff/
> 
> 
> Testing
> ---
> 
> I created two physical networks hosting guest traffic, one as a vlan 
> isolation type, the other a vxlan isolation type. The vlan isolation type has 
> traffic label 'cloudbr0', on physical eth0, and the vxlan has traffic label 
> 'eth2' on physical network eth2.
> 
> This patch would still allow multiple guest networks to use vxlan isolation, 
> just not the same VNI numbers. It doesn't enforce this though.
> 
> Here they are running side by side:
> 
> root@devcloud-kvm-u:~# brctl show
> bridge name   bridge id   STP enabled interfaces
> breth0-3905   8000.000c29d82947   no  eth0.3905
>   vnet8
> brvx-1213043  8000.a6e6026f7fbb   no  vnet9
>   vxlan1213043
> brvx-1589169  8000.663d4e875e78   no  vnet10
>   vxlan1589169
> cloud08000.fe00a9fe0069   no  vnet0
>   vnet2
>   vnet3
> cloudbr0  8000.000c29d82947   no  eth0
>   vnet4
>   vnet6
> cloudbr1  8000.000c29d82951   no  eth1
>   vnet1
>   vnet5
>   vnet7
> 
> root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
> 56: vxlan1213043:  mtu 1450 qdisc noqueue 
> master brvx-1213043 state UNKNOWN mode DEFAULT group default
> vxlan id 1213043 group 239.18.130.115 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> 59: vxlan1589169:  mtu 1450 qdisc noqueue 
> master brvx-1589169 state UNKNOWN mode DEFAULT group default
> vxlan id 1589169 group 239.24.63.177 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> 62: vxlan1638510:  mtu 1450 qdisc noqueue 
> master brvx-1638510 state UNKNOWN mode DEFAULT group default
> vxlan id 1638510 group 239.25.0.110 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> root@devcloud-kvm-u:~/cloudstack# ip route show
> default via 192.168.100.1 dev cloudbr1  metric 100
> 169.254.0.0/16 dev cloud0  proto kernel  scope link  src 169.254.0.1
> 172.17.10.0/24 dev cloudbr0  proto kernel  scope link  src 172.17.10.10
> 192.168.100.0/24 dev cloudbr1  proto kernel  scope link  src 192.168.100.10
> 239.18.130.115 dev eth2  scope link
> 239.24.63.177 dev eth2  scope li

Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix


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



plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java


It is indeed traffic label if one exists. _pifs contains map "trafficLabel 
=> physical nic", but also contains the general keys 'private' (for guest 
traffic type) and 'public' (for public traffic type) for default values. If you 
prefer we can change the variable name to "pifKey" in order to reduce confusion.

If we pull the "_pifs.get(trafficLabel)" out of here, we have to add 
several lines or a new method just prior to every point where createVnetBr is 
called to see if we can get a nic, then check for physical interface if no 
mapping was found to pass it as nic.  I'm ok with doing a new method if you 
feel strongly that this needs to be split out. It would be better if it were 
within createVnetBr or wrapped createVnetBr so that one doesn't have to 
remember to call it every time prior to createVnetBr.


- Marcus Sorensen


On Oct. 29, 2013, 5:51 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15014/
> ---
> 
> (Updated Oct. 29, 2013, 5:51 p.m.)
> 
> 
> Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can 
> host guest traffic type with vxlan isolation, so long as they don't use the 
> same VNI range.
> 
> 2) Guest traffic labels can be physical interface if bridge by given name is 
> not found. Normally we take traffic label name, find the matching bridge, 
> then resolve that to a physical interface. Then we create guest bridges on 
> that interface. Now we can just specify the interface.
> 
> This patch may need some refinement, but I want to get it to the vxlan devs 
> for review.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  286d0f7 
>   scripts/vm/network/vnet/modifyvxlan.sh a3ec71f 
>   server/src/com/cloud/network/NetworkServiceImpl.java cf419f3 
> 
> Diff: https://reviews.apache.org/r/15014/diff/
> 
> 
> Testing
> ---
> 
> I created two physical networks hosting guest traffic, one as a vlan 
> isolation type, the other a vxlan isolation type. The vlan isolation type has 
> traffic label 'cloudbr0', on physical eth0, and the vxlan has traffic label 
> 'eth2' on physical network eth2.
> 
> This patch would still allow multiple guest networks to use vxlan isolation, 
> just not the same VNI numbers. It doesn't enforce this though.
> 
> Here they are running side by side:
> 
> root@devcloud-kvm-u:~# brctl show
> bridge name   bridge id   STP enabled interfaces
> breth0-3905   8000.000c29d82947   no  eth0.3905
>   vnet8
> brvx-1213043  8000.a6e6026f7fbb   no  vnet9
>   vxlan1213043
> brvx-1589169  8000.663d4e875e78   no  vnet10
>   vxlan1589169
> cloud08000.fe00a9fe0069   no  vnet0
>   vnet2
>   vnet3
> cloudbr0  8000.000c29d82947   no  eth0
>   vnet4
>   vnet6
> cloudbr1  8000.000c29d82951   no  eth1
>   vnet1
>   vnet5
>   vnet7
> 
> root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
> 56: vxlan1213043:  mtu 1450 qdisc noqueue 
> master brvx-1213043 state UNKNOWN mode DEFAULT group default
> vxlan id 1213043 group 239.18.130.115 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> 59: vxlan1589169:  mtu 1450 qdisc noqueue 
> master brvx-1589169 state UNKNOWN mode DEFAULT group default
> vxlan id 1589169 group 239.24.63.177 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> 62: vxlan1638510:  mtu 1450 qdisc noqueue 
> master brvx-1638510 state UNKNOWN mode DEFAULT group default
> vxlan id 1638510 group 23

RE: [Merge] hyperv branch to master

2013-10-29 Thread Donal Lafferty

Hi David,

I can assure you that if we knew of a reason to breakup our plugins into 
separate repos, it would have been brought up weeks ago.  

It is far, far easier to create a Master than to merge with Master :)


DL


> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us]
> Sent: 29 October 2013 17:37
> To: dev@cloudstack.apache.org
> Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
> Subject: Re: [Merge] hyperv branch to master
> 
> Well - other projects within the ASF are finding a need to 'sign'
> their convenience binaries, and folks are exploring those options now to find
> something workable.
> 
> Why put it off? Creating a repo takes 5 minutes. IF putting it in its own repo
> and adjusting our release processes is the right thing to do, I'd rather do it
> now than later. If it isn't the right thing to do, then staying put is fine 
> as well.
> 
> --David
> 
> On Tue, Oct 29, 2013 at 1:29 PM, Chiradeep Vittal
>  wrote:
> > That could be a decision to put off for later.
> > The release process deals with single repos for now.
> > The signing will come up during the build right? How do other OSS C#
> > projects deal with it?
> > Perhaps they release binaries in addition to source?
> >
> > On 10/29/13 9:35 AM, "David Nalley"  wrote:
> >
> >>On Mon, Oct 28, 2013 at 7:41 AM, Devdeep Singh
> >>
> >>wrote:
> >>> Hi,
> >>>
> >>> I would like to merge the support for Hyperv to the master branch.
> >>>Development for this has been done by Donal, Rajesh, Anshul and I on
> >>>branch [1]. The feature was proposed for merge earlier [3] but unit
> >>>tests for hyperv agent code were requested [4].
> >>>
> >>
> >>I know this has been discussed several times, but what was the
> >>decision about making the agent code live in its own repo?
> >>It's C#, might need to be signed to actually run easily on Windows, etc.
> >>
> >>--David
> >

Re: Review Request 13841: Missing tests from QA repo to ASF - 3 tests from test_vmware_drs.py


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



test/integration/component/test_vmware_drs.py


self.account_name is no where initialised.
it should have been self.account



test/integration/component/test_vmware_drs.py


self.account_name is no where initialised.
it should have been self.account


- SrikanteswaraRao Talluri


On Oct. 28, 2013, 5:54 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13841/
> ---
> 
> (Updated Oct. 28, 2013, 5:54 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Harikrishna Patnala.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> New File added: test_vmware_drs.py
> Tests added   : def test_vm_creation_in_fully_automated_mode(self):
> def test_vmware_anti_affinity(self):
> def test_vmware_affinity(self):
> 
> The tests need manual setup and therefore have been marked as WIP and
> skipped for the moment
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_vmware_drs.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/13841/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> One test case is working, two are skipped (one due to unavailability of 
> particular setup and other die to feature not available in cloudstack yet)
> 
> Run Log:
> ==> client.log <==
> 2013-10-08 02:27:43,371 - DEBUG - test_vm_creation_in_fully_automated_mode 
> (test_vmware_drs.TestVMPlacement) - max memory: 14911
> 
> ==> result.log <==
> test_vmware_affinity (test_vmware_drs.TestAffinityRules)
> Test Set up affinity rules ... skipped 'Skip'
> test_vmware_anti_affinity (test_vmware_drs.TestAntiAffinityRules)
> Test Set up anti-affinity rules ... skipped 'Skip'
> test_vm_creation_in_fully_automated_mode (test_vmware_drs.TestVMPlacement)
> Test VM Creation in  automation mode = Fully automated ...
> ==> client.log <==
> 2013-10-08 02:28:53,855 - DEBUG - test_vm_creation_in_fully_automated_mode 
> (test_vmware_drs.TestVMPlacement) - Deploying VM in account: test-R7LY31
> 
> ==> result.log <==
> ok
> 
> --
> Ran 3 tests in 241.612s
> 
> OK (skipped=2)
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: haPlanners error in fresh 4.2 checkout

2013-10-29 Thread Nitin Mehta

Yeah, that should have cleaned the workspace. Did you see what Prachi
recommended below ?

On 29/10/13 2:02 AM, "sebgoa"  wrote:

>
>On Oct 28, 2013, at 7:14 PM, Nitin Mehta  wrote:
>
>> Probably cleaning up you workspace might help.
>
>Dummy question of the day then, how do I do that ?
>I did compile with `mvn clean install`
>
>
>> 
>> On 28/10/13 10:51 AM, "Prachi Damle"  wrote:
>> 
>>> I had encountered this sometime back ... you need to check if your
>>> componentContext.xml or its equivalent has following defined. However I
>>> do see it is present in the 4.2 branch
>>> 
>>> 
>>>  
>>>
>>>
>>>
>>>  
>>> 
>>> 
>>> -Original Message-
>>> From: sebgoa [mailto:run...@gmail.com]
>>> Sent: Monday, October 28, 2013 6:43 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: haPlanners error in fresh 4.2 checkout
>>> 
>>> Hi,
>>> 
>>> I just checked out the latest from 4.2 and I get this:
>>> 
>>> INFO  [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:)
>>> JSR-330 'javax.inject.Inject' annotation found and supported for
>>> autowiring INFO
>>> [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:)
>>>JSR-330
>>> 'javax.inject.Inject' annotation found and supported for autowiring
>>>INFO
>>> [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:)
>>>JSR-330
>>> 'javax.inject.Inject' annotation found and supported for autowiring
>>> 2013-10-28 14:41:36.018:INFO::Started
>>>SelectChannelConnector@0.0.0.0:8080
>>> [INFO] Started Jetty Server
>>> Exception in thread "Timer-2"
>>> org.springframework.beans.factory.BeanExpressionException: Expression
>>> parsing failed; nested exception is
>>> org.springframework.expression.spel.SpelEvaluationException:
>>>EL1008E:(pos
>>> 0): Field or property 'haPlanners' cannot be found on object of type
>>> 'org.springframework.beans.factory.config.BeanExpressionContext'
>>> at 
>>> 
>>>org.springframework.context.expression.StandardBeanExpressionResolver.ev
>>>al
>>> uate(StandardBeanExpressionResolver.java:142)
>>> at 
>>> 
>>>org.springframework.beans.factory.support.AbstractBeanFactory.evaluateBe
>>>an
>>> DefinitionString(AbstractBeanFactory.java:1299)
>>> at 
>>> 
>>>org.springframework.beans.factory.support.BeanDefinitionValueResolver.ev
>>>al
>>> uate(BeanDefinitionValueResolver.java:210)
>>> at 
>>> 
>>>org.springframework.beans.factory.support.BeanDefinitionValueResolver.re
>>>so
>>> lveValueIfNecessary(BeanDefinitionValueResolver.java:182)
>>> at 
>>> 
>>>org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
>>>to
>>> ry.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
>>> at 
>>> 
>>>org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
>>>to
>>> ry.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
>>> at 
>>> 
>>>org.springframework.beans.factory.support.AbstractAutowireCapableBeanFac
>>>to
>>> ry.configureBean(AbstractAutowireCapableBeanFactory.java:314)
>>> at 
>>> 
>>>com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(Compo
>>>ne
>>> ntContext.java:71)
>>> at 
>>> 
>>>com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54)
>>> at java.util.TimerThread.mainLoop(Timer.java:555)
>>> at java.util.TimerThread.run(Timer.java:505)
>>> Caused by: org.springframework.expression.spel.SpelEvaluationException:
>>> EL1008E:(pos 0): Field or property 'haPlanners' cannot be found on
>>>object
>>> of type 
>>>'org.springframework.beans.factory.config.BeanExpressionContext'
>>> at 
>>> 
>>>org.springframework.expression.spel.ast.PropertyOrFieldReference.readPro
>>>pe
>>> rty(PropertyOrFieldReference.java:208)
>>> at 
>>> 
>>>org.springframework.expression.spel.ast.PropertyOrFieldReference.getValu
>>>eI
>>> nternal(PropertyOrFieldReference.java:72)
>>> at 
>>> 
>>>org.springframework.expression.spel.ast.CompoundExpression.getValueInter
>>>na
>>> l(CompoundExpression.java:52)
>>> at 
>>> 
>>>org.springframework.expression.spel.ast.SpelNodeImpl.getValue(SpelNodeIm
>>>pl
>>> .java:93)
>>> at 
>>> 
>>>org.springframework.expression.spel.standard.SpelExpression.getValue(Spe
>>>lE
>>> xpression.java:88)
>>> at 
>>> 
>>>org.springframework.context.expression.StandardBeanExpressionResolver.ev
>>>al
>>> uate(StandardBeanExpressionResolver.java:139)
>>> ... 10 more
>>> 
>>> 
>>> Any thoughts ?
>>> 
>>> -sebastien
>> 
>

Re: ifconfig and MacAddress

2013-10-29 Thread Laszlo Hornyak

Hi,

I will update my patch with a fix, but I also like Darran's solution: just
delete the class and/or use InetAddress




On Tue, Oct 29, 2013 at 6:42 PM, Kelven Yang  wrote:

>  Windows ipconfig is not supported, a fix is welcome.
>
>  To run a CS management server cluster on Windows. manual configuration
> is required. cluster.node.ip needs to configured correctly in db.properties
>
>  Kelven
>
>   From: Alex Huang 
> Date: Tuesday, October 29, 2013 at 8:43 AM
> To: Laszlo Hornyak , "dev@cloudstack.apache.org"
> 
> Cc: Kelven Yang 
> Subject: RE: ifconfig and MacAddress
>
>   I can confirm the code’s only there because Java didn’t have it before.*
> ***
>
> ** **
>
> --Alex
>
> ** **
>
> *From:* Laszlo Hornyak 
> [mailto:laszlo.horn...@gmail.com]
>
> *Sent:* Monday, October 28, 2013 11:50 PM
> *To:* dev@cloudstack.apache.org
> *Cc:* Alex Huang; Kelven Yang
> *Subject:* Re: ifconfig and MacAddress
>
> ** **
>
> Hi,
>
> I noticed other problem with the MacAddress, it appears that it does not
> handle the Windows ipconfig output.
>
> (see related patch) https://reviews.apache.org/r/14514/ I tested it with
> win8, 7, and XP outputs
>
> As far as I remember this may be a problem when running CS cluster on
> windows, since each node determines the default as id.
>
> ** **
>
> On Sun, Oct 27, 2013 at 1:11 AM, Darren Shepherd <
> darren.s.sheph...@gmail.com> wrote:
>
> Is there a specific reason that in MacAddress it uses "ifconfig" or
> other utilities to grab the Mac Address as opposed to the java API
> java.net.NetworkInterface?  There's a comment in that code that says
> that code was copied from some public domain utility.  So I'm guessing
> its there just because that's what somebody wrote back before Java 6
> introduced NetworkInteface.getHardwareAddress().  I'd like to rewrite
> this code to use the standard API, grab the Mac deterministically and
> also not use ifconfig which was deprecated 3 years ago.
>
> Darren
>
>
>
>
> --
>
> EOF 
>



-- 

EOF

Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix



> On Oct. 29, 2013, 6:26 p.m., Marcus Sorensen wrote:
> > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java,
> >  line 164
> > 
> >
> > It is indeed traffic label if one exists. _pifs contains map 
> > "trafficLabel => physical nic", but also contains the general keys 
> > 'private' (for guest traffic type) and 'public' (for public traffic type) 
> > for default values. If you prefer we can change the variable name to 
> > "pifKey" in order to reduce confusion.
> > 
> > If we pull the "_pifs.get(trafficLabel)" out of here, we have to add 
> > several lines or a new method just prior to every point where createVnetBr 
> > is called to see if we can get a nic, then check for physical interface if 
> > no mapping was found to pass it as nic.  I'm ok with doing a new method if 
> > you feel strongly that this needs to be split out. It would be better if it 
> > were within createVnetBr or wrapped createVnetBr so that one doesn't have 
> > to remember to call it every time prior to createVnetBr.

Previous comment is just a comment, not a strong one. Changing the 2nd param 
name to "pifKey" seems better for me.


- Yoshikazu


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


On Oct. 29, 2013, 5:51 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15014/
> ---
> 
> (Updated Oct. 29, 2013, 5:51 p.m.)
> 
> 
> Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can 
> host guest traffic type with vxlan isolation, so long as they don't use the 
> same VNI range.
> 
> 2) Guest traffic labels can be physical interface if bridge by given name is 
> not found. Normally we take traffic label name, find the matching bridge, 
> then resolve that to a physical interface. Then we create guest bridges on 
> that interface. Now we can just specify the interface.
> 
> This patch may need some refinement, but I want to get it to the vxlan devs 
> for review.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  286d0f7 
>   scripts/vm/network/vnet/modifyvxlan.sh a3ec71f 
>   server/src/com/cloud/network/NetworkServiceImpl.java cf419f3 
> 
> Diff: https://reviews.apache.org/r/15014/diff/
> 
> 
> Testing
> ---
> 
> I created two physical networks hosting guest traffic, one as a vlan 
> isolation type, the other a vxlan isolation type. The vlan isolation type has 
> traffic label 'cloudbr0', on physical eth0, and the vxlan has traffic label 
> 'eth2' on physical network eth2.
> 
> This patch would still allow multiple guest networks to use vxlan isolation, 
> just not the same VNI numbers. It doesn't enforce this though.
> 
> Here they are running side by side:
> 
> root@devcloud-kvm-u:~# brctl show
> bridge name   bridge id   STP enabled interfaces
> breth0-3905   8000.000c29d82947   no  eth0.3905
>   vnet8
> brvx-1213043  8000.a6e6026f7fbb   no  vnet9
>   vxlan1213043
> brvx-1589169  8000.663d4e875e78   no  vnet10
>   vxlan1589169
> cloud08000.fe00a9fe0069   no  vnet0
>   vnet2
>   vnet3
> cloudbr0  8000.000c29d82947   no  eth0
>   vnet4
>   vnet6
> cloudbr1  8000.000c29d82951   no  eth1
>   vnet1
>   vnet5
>   vnet7
> 
> root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
> 56: vxlan1213043:  mtu 1450 qdisc noqueue 
> master brvx-1213043 state UNKNOWN mode DEFAULT group default
> vxlan id 1213043 group 239.18.130.115 dev eth2 port 32768 61000 ttl 10 
> ageing 300
> 59: vxlan1589169:  mtu 1450 qdisc noqueue 
> master brvx-1589169 st

Review Request 15047: Add support for multiple networks in the 'per account' source nat type setting


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

Review request for cloudstack and Sheng Yang.


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


Repository: cloudstack-git


Description
---

Patch to fix: https://issues.apache.org/jira/browse/CLOUDSTACK-4991

Please review the attached PDF and the issue and contact me if anything is 
unclear.


Diffs
-

  server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java 629bef5 

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


Testing
---

I have been using this patch for 3 months without issues.


File Attachments


Email thread from mailing list
  
https://reviews.apache.org/media/uploaded/files/2013/10/29/Supported_Source_NAT_Type.pdf


Thanks,

Will Stevens

Re: Review Request 15047: Add support for multiple networks in the 'per account' source nat type setting


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

(Updated Oct. 29, 2013, 8:24 p.m.)


Review request for cloudstack and Sheng Yang.


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


Repository: cloudstack-git


Description
---

Patch to fix: https://issues.apache.org/jira/browse/CLOUDSTACK-4991

Please review the attached PDF and the issue and contact me if anything is 
unclear.


Diffs
-

  server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java 629bef5 

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


Testing
---

I have been using this patch for 3 months without issues.


File Attachments


Email thread from mailing list
  
https://reviews.apache.org/media/uploaded/files/2013/10/29/Supported_Source_NAT_Type.pdf


Thanks,

Will Stevens

Re: Wiki access

I also need access.
un: wstevens
email: wstev...@cloudops.com


On Tue, Oct 29, 2013 at 5:02 AM, Damoder Reddy wrote:

> Please grant me edit access..
> Email : damoder.re...@citrix.com
> Username: Damoder.reddy
>
> -Original Message-
> From: Nitin Mehta [mailto:nitin.me...@citrix.com]
> Sent: Tuesday, 29 October 2013 7:18 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Wiki access
>
> Please grant me edit access.
> Email - nitin.me...@citrix.com
>
> On 28/10/13 5:17 AM, "Gaurav Aradhye"  wrote:
>
> >Hi,
> >
> >My username is gauravaradhye.
> >Can anyone grant me edit permission?
> >
> >I need to update test plan automation columns.
> >
> >
> >Regards,
> >Gaurav
> >
> >
> >On Fri, Oct 18, 2013 at 5:26 PM, Kishan Kavala
> >wrote:
> >
> >> Thanks Hugo.
> >>
> >> > -Original Message-
> >> > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> >> > Trippaers
> >> > Sent: Friday, 18 October 2013 4:39 PM
> >> > To: dev@cloudstack.apache.org
> >> > Subject: Re: Wiki access
> >> >
> >> > Hey Kishan,
> >> >
> >> > I've granted you permissions. There apparently is another Kishan
> >> > with
> >> edit
> >> > permission as well, so i got confused.
> >> >
> >> > Cheers,
> >> >
> >> > Hugo
> >> >
> >> > On 18 okt. 2013, at 12:38, Kishan Kavala 
> >> wrote:
> >> >
> >> > > Hugo,
> >> > > I've checked again. My account doesn't have edit permission.
> >> > >
> >> > >> -Original Message-
> >> > >> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> >>Trippaers
> >> > >> Sent: Wednesday, 16 October 2013 7:59 PM
> >> > >> To: dev@cloudstack.apache.org
> >> > >> Subject: Re: Wiki access
> >> > >>
> >> > >> Kishan,
> >> > >>
> >> > >> look like you have the permissions already on account kishan.
> >> > >> Can
> >>you
> >> check?
> >> > >>
> >> > >> Cheers,
> >> > >>
> >> > >> Hugo
> >> > >>
> >> > >>
> >> > >> On Oct 16, 2013, at 3:45 PM, Kishan Kavala
> >>
> >> > wrote:
> >> > >>
> >> > >>> Please grant me edit access.
> >> > >>> Email: kis...@cloud.com
> >> > >>>
> >> > >>> ~kishan
> >> > >>>
> >> >  -Original Message-
> >> >  From: Radhika Puthiyetath
> >> >  [mailto:radhika.puthiyet...@citrix.com]
> >> >  Sent: Wednesday, 16 October 2013 3:22 PM
> >> >  To: dev@cloudstack.apache.org
> >> >  Subject: RE: Wiki access
> >> > 
> >> >  Hi,
> >> > 
> >> >  I do not have the edit permissions. My username is radhikap.
> >> > 
> >> >  Kindly provide me with the necessary permissions.
> >> > 
> >> >  Thanks
> >> >  -Radhika
> >> > 
> >> >  -Original Message-
> >> >  From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >> >  Sent: Friday, October 04, 2013 3:26 PM
> >> >  To: dev
> >> >  Subject: Re: Wiki access
> >> > 
> >> >  anshulg is in
> >> > 
> >> > 
> >> >  On Fri, Oct 4, 2013 at 11:51 AM, Anshul Gangwar
> >> >  wrote:
> >> > 
> >> > > need edit permissions , username: anshulg
> >> > >
> >> > > Regards,
> >> > > Anshul
> >> > >
> >> > > On Friday 04 October 2013 02:47 PM, Saksham Srivastava wrote:
> >> > >> Please provide me edit permissions, username: saksham
> >> > >>
> >> > >> Regards,
> >> > >> Saksham
> >> > >>
> >> > >> -Original Message-
> >> > >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> >> > >> Sent: Friday, October 04, 2013 10:46 AM
> >> > >> To: dev@cloudstack.apache.org
> >> > >> Subject: Re: Wiki access
> >> > >>
> >> > >> Mike, Tuna, Srinivas, Go, done.
> >> > >>
> >> > >> On 10/3/13 9:12 PM, "Mike Tutkowski"
> >> > >> 
> >> > > wrote:
> >> > >>
> >> > >>> I seem to need edit access, as well.
> >> > >>>
> >> > >>> I'm usually logged in by default, but I believe my username
> >> > >>> is mike-tutkowski (else please try mtutkowski).
> >> > >>>
> >> > >>> Thanks!
> >> > >>>
> >> > >>>
> >> > >>> On Thu, Oct 3, 2013 at 7:07 PM, Go Chiba
> >> > >>> 
> >> > wrote:
> >> > >>>
> >> >  Hi Chip,
> >> > 
> >> >  Please grant me to edit pages. My id is "gochiba".
> >> > 
> >> > 
> >> >  On Thu, Oct 3, 2013 at 6:01 AM, Chip Childers
> >> >   >> > > wrote:
> >> > > Not all committers were easy to find, but those that I
> >> > > did should be
> >> >  all
> >> > > set.
> >> > >
> >> > > So committers / contributors = provide your confluence
> >> > > ID's
> >>if
> >> > > you
> >> >  can't
> >> > > add / edit pages.  PMC folks - help add them please.
> >> > >
> >> > >
> >> > > On Wed, Oct 2, 2013 at 4:48 PM, Chip Childers
> >> >   >> > >> wrote:
> >> > >> There were major issues with Spam on the wiki, so infra
> >> > >> changed the permissions.
> >> > >>
> >> > >> I've just gone and added

Re: [Merge] hyperv branch to master

2013-10-29 Thread David Nalley

Indeed :)
And that answers my question - thanks!



On Tue, Oct 29, 2013 at 2:31 PM, Donal Lafferty
 wrote:
> Hi David,
>
> I can assure you that if we knew of a reason to breakup our plugins into 
> separate repos, it would have been brought up weeks ago.
>
> It is far, far easier to create a Master than to merge with Master :)
>
>
> DL
>
>
>> -Original Message-
>> From: David Nalley [mailto:da...@gnsa.us]
>> Sent: 29 October 2013 17:37
>> To: dev@cloudstack.apache.org
>> Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
>> Subject: Re: [Merge] hyperv branch to master
>>
>> Well - other projects within the ASF are finding a need to 'sign'
>> their convenience binaries, and folks are exploring those options now to find
>> something workable.
>>
>> Why put it off? Creating a repo takes 5 minutes. IF putting it in its own 
>> repo
>> and adjusting our release processes is the right thing to do, I'd rather do 
>> it
>> now than later. If it isn't the right thing to do, then staying put is fine 
>> as well.
>>
>> --David
>>
>> On Tue, Oct 29, 2013 at 1:29 PM, Chiradeep Vittal
>>  wrote:
>> > That could be a decision to put off for later.
>> > The release process deals with single repos for now.
>> > The signing will come up during the build right? How do other OSS C#
>> > projects deal with it?
>> > Perhaps they release binaries in addition to source?
>> >
>> > On 10/29/13 9:35 AM, "David Nalley"  wrote:
>> >
>> >>On Mon, Oct 28, 2013 at 7:41 AM, Devdeep Singh
>> >>
>> >>wrote:
>> >>> Hi,
>> >>>
>> >>> I would like to merge the support for Hyperv to the master branch.
>> >>>Development for this has been done by Donal, Rajesh, Anshul and I on
>> >>>branch [1]. The feature was proposed for merge earlier [3] but unit
>> >>>tests for hyperv agent code were requested [4].
>> >>>
>> >>
>> >>I know this has been discussed several times, but what was the
>> >>decision about making the agent code live in its own repo?
>> >>It's C#, might need to be signed to actually run easily on Windows, etc.
>> >>
>> >>--David
>> >

Re: [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions

2013-10-29 Thread Alex Ough

I created a jira for this feature.

https://issues.apache.org/jira/browse/CLOUDSTACK-4992

But it doesn't allow for me to assign it to myself, so any permission do I
need for this?
If so, can anyone give me this permission?

If there is anything missing, let me know.
Thanks
Alex Ough


On Fri, Oct 18, 2013 at 9:30 AM, Kishan Kavala wrote:

> > -Original Message-
> > From: Alex Ough [mailto:alex.o...@sungard.com]
> > Sent: Thursday, 17 October 2013 11:25 PM
> > To: dev@cloudstack.apache.org; u...@cloudstack.apache.org
> > Subject: Fwd: [DISCUSS] Domain/Account/User Sync Up Among Multiple
> > Regions
> >
> > All,
> >
> > Currently, under the environment of cloudstack with multiple regions,
> each
> > region has its own management server running with a separate database.
> So if
> > we want to support multiple regions and provide one point of entry for a
> > customer, we need to duplicate domain/account/user information of that
> > customer to all of the databases of regions the customer accesses, which
> will
> > cause data discrepancies when users update those data independently in
> each
> > management server.
> >
> > So I'd like to provide a way to sync up the data using the messaging
> system
> > introduced in 4.1.0. Using the events from each management server,
> updates
> > from each region can be propagated to the rest regions and they can be
> > executed accordingly.
> >
> > I hope you guys have a chance to think about this and give some
> feedbacks if
> > interested.
> > Thanks in advance.
> > Alex Ough
>
> [KK] Alex, it was discussed sometime back. Related thread [1]. Sync up
> using messaging system is the right way to go.
>
>
> [1]
> http://www.mail-archive.com/cloudstack-dev@incubator.apache.org/msg20193.html
>
>

Review Request 15050: Add Palo Alto Networks Firewall Integration


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

Review request for cloudstack and Sheng Yang.


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


Repository: cloudstack-git


Description
---

More information in the FS: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration

This patch adds a network plugin which adds support for the Palo Alto Networks 
firewall (their appliance and their VM series firewall).

Features supported are:
- List/Add/Delete Palo Alto service provider
- List/Add/Delete Palo Alto network service offering
- List/Add/Delete Palo Alto network with above service offering
- Add instance to the new network (creates the public IP and private 
gateway/cidr on the PA as well as the source nat rule)
- List/Add/Delete Ingress Firewall rule
- List/Add/Delete Egress Firewall rule
- List/Add/Delete Port Forwarding rule
- List/Add/Delete Static Nat rule
- Supports Palo Alto Networks 'Log Forwarding' profile globally per device 
(additional docs to come)
- Supports Palo Alto Networks 'Security Profile Groups' functionality globally 
per device (additional docs to come)

Knowns limitations:
- Only supports one public IP range in CloudStack.
- Currently not verifying SSL certificates when creating a connection between 
CloudStack and the Palo Alto Networks firewall.
- Currently not tracking usage on Public IPs.


Diffs
-

  api/src/com/cloud/network/Network.java 49f380b 
  
api/src/org/apache/cloudstack/api/command/admin/network/AddNetworkDeviceCmd.java
 4983255 
  
api/src/org/apache/cloudstack/api/command/admin/network/ListNetworkDeviceCmd.java
 0b7836d 
  api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java 
29ce2e3 
  client/WEB-INF/classes/resources/messages.properties c075bf8 
  client/pom.xml fd1f13a 
  client/tomcatconf/commands.properties.in 96e841a 
  client/tomcatconf/nonossComponentContext.xml.in 0502bbc 
  plugins/network-elements/palo-alto/pom.xml PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/commands/AddExternalFirewallCmd.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/commands/AddPaloAltoFirewallCmd.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/commands/ConfigurePaloAltoFirewallCmd.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/commands/DeleteExternalFirewallCmd.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/commands/DeletePaloAltoFirewallCmd.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListExternalFirewallsCmd.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListPaloAltoFirewallNetworksCmd.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/commands/ListPaloAltoFirewallsCmd.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/api/response/PaloAltoFirewallResponse.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/network/element/PaloAltoExternalFirewallElement.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/network/element/PaloAltoFirewallElementService.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/network/resource/PaloAltoResource.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/src/com/cloud/network/utils/HttpClientWrapper.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/test/com/cloud/network/resource/MockablePaloAltoResource.java
 PRE-CREATION 
  
plugins/network-elements/palo-alto/test/com/cloud/network/resource/PaloAltoResourceTest.java
 PRE-CREATION 
  plugins/pom.xml ca41dff 
  server/src/com/cloud/api/ApiResponseHelper.java f4ca112 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 4fda3b1 
  ui/dictionary.jsp 80aab6f 
  ui/scripts/docs.js 3a4f8ca 
  ui/scripts/system.js 0af3952 

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


Testing
---

I have tested all of the functionality listed under 'supported features'.


Thanks,

Will Stevens

Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix



> On Oct. 29, 2013, 6:26 p.m., Marcus Sorensen wrote:
> > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java,
> >  line 164
> > 
> >
> > It is indeed traffic label if one exists. _pifs contains map 
> > "trafficLabel => physical nic", but also contains the general keys 
> > 'private' (for guest traffic type) and 'public' (for public traffic type) 
> > for default values. If you prefer we can change the variable name to 
> > "pifKey" in order to reduce confusion.
> > 
> > If we pull the "_pifs.get(trafficLabel)" out of here, we have to add 
> > several lines or a new method just prior to every point where createVnetBr 
> > is called to see if we can get a nic, then check for physical interface if 
> > no mapping was found to pass it as nic.  I'm ok with doing a new method if 
> > you feel strongly that this needs to be split out. It would be better if it 
> > were within createVnetBr or wrapped createVnetBr so that one doesn't have 
> > to remember to call it every time prior to createVnetBr.
> 
> Yoshikazu Nojima wrote:
> Previous comment is just a comment, not a strong one. Changing the 2nd 
> param name to "pifKey" seems better for me.

Ok, I'll make that change and commit it.


- Marcus


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


On Oct. 29, 2013, 5:51 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15014/
> ---
> 
> (Updated Oct. 29, 2013, 5:51 p.m.)
> 
> 
> Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can 
> host guest traffic type with vxlan isolation, so long as they don't use the 
> same VNI range.
> 
> 2) Guest traffic labels can be physical interface if bridge by given name is 
> not found. Normally we take traffic label name, find the matching bridge, 
> then resolve that to a physical interface. Then we create guest bridges on 
> that interface. Now we can just specify the interface.
> 
> This patch may need some refinement, but I want to get it to the vxlan devs 
> for review.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  286d0f7 
>   scripts/vm/network/vnet/modifyvxlan.sh a3ec71f 
>   server/src/com/cloud/network/NetworkServiceImpl.java cf419f3 
> 
> Diff: https://reviews.apache.org/r/15014/diff/
> 
> 
> Testing
> ---
> 
> I created two physical networks hosting guest traffic, one as a vlan 
> isolation type, the other a vxlan isolation type. The vlan isolation type has 
> traffic label 'cloudbr0', on physical eth0, and the vxlan has traffic label 
> 'eth2' on physical network eth2.
> 
> This patch would still allow multiple guest networks to use vxlan isolation, 
> just not the same VNI numbers. It doesn't enforce this though.
> 
> Here they are running side by side:
> 
> root@devcloud-kvm-u:~# brctl show
> bridge name   bridge id   STP enabled interfaces
> breth0-3905   8000.000c29d82947   no  eth0.3905
>   vnet8
> brvx-1213043  8000.a6e6026f7fbb   no  vnet9
>   vxlan1213043
> brvx-1589169  8000.663d4e875e78   no  vnet10
>   vxlan1589169
> cloud08000.fe00a9fe0069   no  vnet0
>   vnet2
>   vnet3
> cloudbr0  8000.000c29d82947   no  eth0
>   vnet4
>   vnet6
> cloudbr1  8000.000c29d82951   no  eth1
>   vnet1
>   vnet5
>   vnet7
> 
> root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
> 56: vxlan1213043:  mtu 1450 qdisc noqueue 
> master brvx-1213043 state UNKNOWN mode DEFAULT group default
> vxlan id 1213043 group 239.18.130.115 dev eth2 port 32768 61000 ttl 10 
> agein

Re: Review Request 15018: CLOUDSTACK-4908: CPU socket count of host

2013-10-29 Thread ASF Subversion and Git Services


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


Commit bed42deb8835760e98a39902a698c38dbd17b414 in branch refs/heads/master 
from Brian Federle
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bed42de ]

CLOUDSTACK-4908: UI for report CPU sockets

-Adds socket info for hypervisors on infrastructure chart

-Displays # of sockets, and # of hosts

-Currently only dummy data set to 0 for all info


- ASF Subversion and Git Services


On Oct. 29, 2013, 9:29 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15018/
> ---
> 
> (Updated Oct. 29, 2013, 9:29 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-4908
> https://issues.apache.org/jira/browse/CLOUDSTACK-4908
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4908: CPU socket count of host 
> Adding cpu socket count of the host in hostresponse
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/host/Host.java 17b0ba8 
>   api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java 
> 95b9ac3 
>   api/src/org/apache/cloudstack/api/response/HostResponse.java 687687d 
>   core/src/com/cloud/agent/api/StartupRoutingCommand.java d52666b 
>   core/test/org/apache/cloudstack/api/agent/test/CheckOnHostCommandTest.java 
> 1b68276 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/datacenter/entity/api/db/EngineHostVO.java
>  249c2db 
>   engine/schema/src/com/cloud/host/HostVO.java c814b94 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  286d0f7 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  423abe6 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  6c1efe7 
>   server/src/com/cloud/api/query/QueryManagerImpl.java a7d85cf 
>   server/src/com/cloud/api/query/dao/HostJoinDaoImpl.java 97f8bf9 
>   server/src/com/cloud/api/query/vo/HostJoinVO.java fbc59cd 
>   server/src/com/cloud/resource/ResourceManagerImpl.java e9d5193 
>   setup/db/db/schema-421to430.sql 0e78875 
>   vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java 108a3ec 
>   vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHost.java 
> f7288f1 
>   
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHostResourceSummary.java
>  fa11dc3 
> 
> Diff: https://reviews.apache.org/r/15018/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 15001: CLOUDSTACK-4967: Bugfix: Guest network isn't created correctly in rare case when vxlan is used for isolation method

2013-10-29 Thread ASF Subversion and Git Services


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


Commit 4a9f05bda075d03c4a5a015e081c70b3d8b72267 in branch refs/heads/master 
from Marcus Sorensen
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4a9f05b ]

CLOUDSTACK-4967
1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can 
host guest
traffic type with vxlan isolation, so long as they don't use the same VNI range.

2) Guest traffic labels can be physical interface if bridge by given name is 
not found.
Normally we take traffic label name, find the matching bridge, then resolve 
that to a
physical interface. Then we create guest bridges on that interface. Now we can 
just
specify the interface.


- ASF Subversion and Git Services


On Oct. 29, 2013, 12:51 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15001/
> ---
> 
> (Updated Oct. 29, 2013, 12:51 a.m.)
> 
> 
> Review request for cloudstack, Marcus Sorensen and Toshiaki Hatano.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Guest network isn't created correctly when vxlan is used for isolation 
> method, VNI is bigger than 1000, and physical network interface name 
> length is longer than 4.
> This patch fix this issue by raising error when long interface name is 
> specified.
> 
> Issue remained: document that physical interface name length must be shorter 
> than 5.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/BridgeVifDriverTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15001/diff/
> 
> 
> Testing
> ---
> 
> I confirmed it passes the unit tests I add.
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 15014: allow physical devices as guest traffic label, vxlan bridge name fix



> On Oct. 29, 2013, 6:26 p.m., Marcus Sorensen wrote:
> > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java,
> >  line 164
> > 
> >
> > It is indeed traffic label if one exists. _pifs contains map 
> > "trafficLabel => physical nic", but also contains the general keys 
> > 'private' (for guest traffic type) and 'public' (for public traffic type) 
> > for default values. If you prefer we can change the variable name to 
> > "pifKey" in order to reduce confusion.
> > 
> > If we pull the "_pifs.get(trafficLabel)" out of here, we have to add 
> > several lines or a new method just prior to every point where createVnetBr 
> > is called to see if we can get a nic, then check for physical interface if 
> > no mapping was found to pass it as nic.  I'm ok with doing a new method if 
> > you feel strongly that this needs to be split out. It would be better if it 
> > were within createVnetBr or wrapped createVnetBr so that one doesn't have 
> > to remember to call it every time prior to createVnetBr.
> 
> Yoshikazu Nojima wrote:
> Previous comment is just a comment, not a strong one. Changing the 2nd 
> param name to "pifKey" seems better for me.
> 
> Marcus Sorensen wrote:
> Ok, I'll make that change and commit it.

Thanks, Marcus!


- Yoshikazu


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


On Oct. 29, 2013, 5:51 p.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15014/
> ---
> 
> (Updated Oct. 29, 2013, 5:51 p.m.)
> 
> 
> Review request for cloudstack, Toshiaki Hatano and Yoshikazu Nojima.
> 
> 
> Bugs: CLOUDSTACK-4967
> https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1) vxlan will use bridge scheme 'brvx-'. Multiple physical networks can 
> host guest traffic type with vxlan isolation, so long as they don't use the 
> same VNI range.
> 
> 2) Guest traffic labels can be physical interface if bridge by given name is 
> not found. Normally we take traffic label name, find the matching bridge, 
> then resolve that to a physical interface. Then we create guest bridges on 
> that interface. Now we can just specify the interface.
> 
> This patch may need some refinement, but I want to get it to the vxlan devs 
> for review.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>  f945b74 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  286d0f7 
>   scripts/vm/network/vnet/modifyvxlan.sh a3ec71f 
>   server/src/com/cloud/network/NetworkServiceImpl.java cf419f3 
> 
> Diff: https://reviews.apache.org/r/15014/diff/
> 
> 
> Testing
> ---
> 
> I created two physical networks hosting guest traffic, one as a vlan 
> isolation type, the other a vxlan isolation type. The vlan isolation type has 
> traffic label 'cloudbr0', on physical eth0, and the vxlan has traffic label 
> 'eth2' on physical network eth2.
> 
> This patch would still allow multiple guest networks to use vxlan isolation, 
> just not the same VNI numbers. It doesn't enforce this though.
> 
> Here they are running side by side:
> 
> root@devcloud-kvm-u:~# brctl show
> bridge name   bridge id   STP enabled interfaces
> breth0-3905   8000.000c29d82947   no  eth0.3905
>   vnet8
> brvx-1213043  8000.a6e6026f7fbb   no  vnet9
>   vxlan1213043
> brvx-1589169  8000.663d4e875e78   no  vnet10
>   vxlan1589169
> cloud08000.fe00a9fe0069   no  vnet0
>   vnet2
>   vnet3
> cloudbr0  8000.000c29d82947   no  eth0
>   vnet4
>   vnet6
> cloudbr1  8000.000c29d82951   no  eth1
>   vnet1
>   vnet5
>   vnet7
> 
> root@devcloud-kvm-u:~/cloudstack# ip -d link show | grep vxlan
> 56: vxlan1213043:  mtu 1450 qdisc noqueue 
> master brvx-1213043 state UNKNOWN mode DEFAULT group default
> vxlan id 1213043 group 239

Re: Mailing list search

2013-10-29 Thread Noah Slater

Bump.

On 25 October 2013 20:58, Noah Slater  wrote:
> Hi,
>
> Mailing list search on our site still points to the incubator:
>
> http://cloudstack.apache.org/mailing-lists.html
>
> I recall discussing this in the past with someone and was asked to
> hold back, as the Incubator lists still had most of the traffic.
>
> Is it time we switched this over?
>
> Thanks,
>
> --
> Noah Slater
> https://twitter.com/nslater



-- 
Noah Slater
https://twitter.com/nslater

Re: Mailing list search

2013-10-29 Thread Chip Childers

Noah,

The last time I checked, markmail still had all traffic against the incubator 
list names. If that has changed, great. If not, then incubator needs to remain 
the target of the search. 



> On Oct 29, 2013, at 6:13 PM, Noah Slater  wrote:
> 
> Bump.
> 
>> On 25 October 2013 20:58, Noah Slater  wrote:
>> Hi,
>> 
>> Mailing list search on our site still points to the incubator:
>> 
>> http://cloudstack.apache.org/mailing-lists.html
>> 
>> I recall discussing this in the past with someone and was asked to
>> hold back, as the Incubator lists still had most of the traffic.
>> 
>> Is it time we switched this over?
>> 
>> Thanks,
>> 
>> --
>> Noah Slater
>> https://twitter.com/nslater
> 
> 
> 
> -- 
> Noah Slater
> https://twitter.com/nslater

Review Request 15068: Change labels for VLAN to vNet

2013-10-29 Thread Chris Cameron


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

Review request for cloudstack and Toshiaki Hatano.


Repository: cloudstack-git


Description
---

We would like to change the labels for VLAN to vNet to make the term more 
generic for VXLAN and VLAN. This relates to the work being done to add in VXLAN 
support to Cloudstack.


Diffs
-

  client/WEB-INF/classes/resources/messages.properties 3210aca 
  ui/dictionary.jsp 35cba22 
  ui/scripts/network.js 12e5389 
  ui/scripts/system.js 479883c 

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


Testing
---


Thanks,

Chris Cameron

Re: cloudmonkey exit value

2013-10-29 Thread Darren Shepherd

First, I care more about the exit code working. 

I want just the value.  So currently I have

cloudmonkey set color false
cloudmonkey createVM ... | grep ^id | awk -F' = ' '{print $2}'

Darren

> On Oct 27, 2013, at 9:48 PM, Prasanna Santhanam  wrote:
> 
>> On Sun, Oct 27, 2013 at 04:49:35PM -0700, Darren Shepherd wrote:
>> It would be really nice if the API failed if cloudmonkey exited with
>> !=0 exit code.  I've been scripting some stuff with cloud monkey and
>> this makes it difficult.  It would also be nice to somehow specific
>> which field you want printed.  So when I do a create command I can say
>> just echo id value only.  Would make my scripts much easier.
> you can pipe with grep?
> $ cloudmonkey createCommand | grep id
> 
>> Darren
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
>

RE: [VOTE] Accept the donation of RDP client code into Apache CloudStack

2013-10-29 Thread Animesh Chaturvedi



> -Original Message-
> From: Chip Childers [mailto:chip.child...@gmail.com]
> Sent: Thursday, October 24, 2013 6:05 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Accept the donation of RDP client code into Apache
> CloudStack
> 
> 
> 
> > On Oct 24, 2013, at 3:20 PM, Donal Lafferty
>  wrote:
> >
> > It's been a bit over 72 hours, and I would like to now close voting on
> the RDP client code donation.
> >
> > We have an acceptance with the following results:
> >
> > +1
> > Animesh Chaturvedi
> > Devdeep Singh
> > Chiradeep Vittal
> > Ahmad Emneina
> > Rajesh Battala
> > Kelven Yang
> > Chip Childers
> > Clayton Weise
> > John Kinsella
> > Sateesh Chodapuneedi
> > Ryan Shafer
> >
> > +0
> > Wido den Hollander
> > Daan hoogland
> >
> > The next stage is to put in place IP clearance paper work in advance
> before the code can go into a branch of master.  I will contact a PMC
> member to arrange for this paperwork.
> 
> No need to contact any PMC members off list (unless there are legal
> concerns, in which case email to private@cs.a.o, not individuals). I
> just need an ack from secretary@ saying that a properly signed Software
> Grant Agreement has been received by the ASF to move through the
> procedural steps. Citrix has done these before, so they should be known
> to your legal dept.
> 
> Thanks!

[Animesh>] I just emailed the signed SGA to secretary@ and private@

> 
> 
> >
> > Thanks for participating everyone!
> >
> >
> >> -Original Message-
> >> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> >> Sent: 21 October 2013 19:12
> >> To: dev@cloudstack.apache.org
> >> Subject: [VOTE] Accept the donation of RDP client code into Apache
> >> CloudStack
> >>
> >> As stated in a previous thread [1], Citrix is proposing the donation
> >> of source for an RDP client.  After donation, the client would be
> >> integrated with the console system VM in order to provide access to
> Hyper-V based VMs.
> >>
> >> The client's source is in the diff attached to the Review Board
> >> submission https://reviews.apache.org/r/14701/
> >>
> >> [1] http://markmail.org/thread/q6sfqrhosmirm3bg
> >>
> >> I would like to call a vote here, so that we have a formal consensus
> >> on accepting the code into the project.  I suggest that it be
> >> accepted into a branch, and then we work through any technical
> >> concerns / reviews / changes prior to a master branch merge.
> >>
> >> VOTING will be left open for 72 hours.
> >>
> >> This is a technical decision, which means committer and PMC votes are
> >> binding.
> >>
> >>
> >> DL
> >

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

2013-10-29 Thread Darren Shepherd

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

Darren

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

Re: Review Request 15068: Change labels for VLAN to vNet

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

I agree with the spirit of what's being done here, but something about changing 
vlan to vnet just doesn't seem quite right. I guess it just doesn't pass the 
"obviousness" test... if someone is navigating and they see "vNet range(s)" 
they either have to guess that it's ok to put vlan ids in there or look up the 
documentation. People may assume that it refers to vxnet or some other 
isolation method. Ideally we'd change the label based on the network's 
isolation method, but if that's too much work, would it be ok to change it to 
"VLAN/VNI Range", or something along those lines? Most of the other labels are 
longer than that, so it seems like there'd be room. 

- Marcus Sorensen

On Oct. 29, 2013, 11:02 p.m., Chris Cameron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15068/
> ---
> 
> (Updated Oct. 29, 2013, 11:02 p.m.)
> 
> 
> Review request for cloudstack and Toshiaki Hatano.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> We would like to change the labels for VLAN to vNet to make the term more 
> generic for VXLAN and VLAN. This relates to the work being done to add in 
> VXLAN support to Cloudstack.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties 3210aca 
>   ui/dictionary.jsp 35cba22 
>   ui/scripts/network.js 12e5389 
>   ui/scripts/system.js 479883c 
> 
> Diff: https://reviews.apache.org/r/15068/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Chris Cameron
> 
>

ui styling

I'm digging the UI styling changes!  It makes me wish they were all
merged in from a branch as a squashed commit so I could pull them out
and apply them to our local 4.2 build.

Re: Review Request 14459: CLOUDSTACK-2243: Add automation tests for VMs base image update faclity

2013-10-29 Thread Ashutosh Kelkar


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

(Updated Oct. 30, 2013, 4:56 a.m.)


Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.


Changes
---

Review Changes


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


Repository: cloudstack-git


Description
---

Added new test class to test Base Image Updation Facility.


Diffs (updated)
-

  test/integration/component/test_base_image_updation.py PRE-CREATION 
  tools/marvin/marvin/codes.py 3da90d6 
  tools/marvin/marvin/integration/lib/base.py 4f15137 

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


Testing
---

Tested locally on KVM advanced setup:

Log:

==> result.log <==
test_01_deploy_instance_with_is_volatile_offering 
(test_base_image_updation.TestBaseImageUpdate)
Test deploy an instance with service offerings with IsVolatile set. ... ok
test_02_reboot_instance_with_is_volatile_offering 
(test_base_image_updation.TestBaseImageUpdate)
Test rebooting instances created with isVolatile service offerings ...
==> client.log <==
2013-10-09 20:22:30,659 - DEBUG - 
test_02_reboot_instance_with_is_volatile_offering 
(test_base_image_updation.TestBaseImageUpdate) - Checking root
th isVolatile=True
2013-10-09 20:22:30,695 - DEBUG - 
test_02_reboot_instance_with_is_volatile_offering 
(test_base_image_updation.TestBaseImageUpdate) - Checking root
th isVolatile=False

==> result.log <==
ok
test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate)
Test restoring a vm with different template than the one it was created with ...
==> client.log <==
2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate) - Registered a template of fo
ith ID: 5a9190a9-8a59-487f-b90f-4a76a0f509a0
2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate) - Waiting for download of tem
: 5a9190a9-8a59-487f-b90f-4a76a0f509a0
2013-10-09 20:38:25,367 - DEBUG - test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM
le=True
2013-10-09 20:38:25,386 - DEBUG - test_03_restore_vm_with_new_template 
(test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM
le=False
2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Creating recurring snapshot po
 disk on vm created with IsVolatile=True
2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Snapshot Policy - Type : HOURL
inute : 53
2013-10-09 20:38:30,982 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Sleeping for 25 minutes till t
snapshoted

==> result.log <==
ok
test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) ...
==> client.log <==
2013-10-09 21:11:51,780 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Checking whether root disk of
atile=True was destroyed
2013-10-09 21:11:51,827 - DEBUG - test_04_reoccuring_snapshot_rules 
(test_base_image_updation.TestBaseImageUpdate) - Checking whether snapshot rule
isVolatile=True was destroyed

==> result.log <==
ok

--
Ran 4 tests in 3534.241s

OK


Thanks,

Ashutosh Kelkar

Re: Review Request 14459: CLOUDSTACK-2243: Add automation tests for VMs base image update faclity

2013-10-29 Thread Ashutosh Kelkar



> On Oct. 28, 2013, 7:02 a.m., Santhosh Edukulla wrote:
> > test/integration/component/test_base_image_updation.py, line 375
> > 
> >
> > Whats the use of this check? We are proceeding anyways even if its not  
> > a list.

We are skipping the test if we don't get the host list


> On Oct. 28, 2013, 7:02 a.m., Santhosh Edukulla wrote:
> > test/integration/component/test_base_image_updation.py, line 577
> > 
> >
> > Again, sleeping for 60 seconds, but decreasing timeout only by one 
> > second.

Timeout is the number of times we are allowing the loop to execute. When 
timeout is exhausted, we break out of the loop and test case fails raising 
exception


- Ashutosh


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


On Oct. 30, 2013, 4:56 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14459/
> ---
> 
> (Updated Oct. 30, 2013, 4:56 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-2243
> https://issues.apache.org/jira/browse/CLOUDSTACK-2243
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added new test class to test Base Image Updation Facility.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_base_image_updation.py PRE-CREATION 
>   tools/marvin/marvin/codes.py 3da90d6 
>   tools/marvin/marvin/integration/lib/base.py 4f15137 
> 
> Diff: https://reviews.apache.org/r/14459/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM advanced setup:
> 
> Log:
> 
> ==> result.log <==
> test_01_deploy_instance_with_is_volatile_offering 
> (test_base_image_updation.TestBaseImageUpdate)
> Test deploy an instance with service offerings with IsVolatile set. ... ok
> test_02_reboot_instance_with_is_volatile_offering 
> (test_base_image_updation.TestBaseImageUpdate)
> Test rebooting instances created with isVolatile service offerings ...
> ==> client.log <==
> 2013-10-09 20:22:30,659 - DEBUG - 
> test_02_reboot_instance_with_is_volatile_offering 
> (test_base_image_updation.TestBaseImageUpdate) - Checking root
> th isVolatile=True
> 2013-10-09 20:22:30,695 - DEBUG - 
> test_02_reboot_instance_with_is_volatile_offering 
> (test_base_image_updation.TestBaseImageUpdate) - Checking root
> th isVolatile=False
> 
> ==> result.log <==
> ok
> test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate)
> Test restoring a vm with different template than the one it was created with 
> ...
> ==> client.log <==
> 2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate) - Registered a template of fo
> ith ID: 5a9190a9-8a59-487f-b90f-4a76a0f509a0
> 2013-10-09 20:22:32,373 - DEBUG - test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate) - Waiting for download of tem
> : 5a9190a9-8a59-487f-b90f-4a76a0f509a0
> 2013-10-09 20:38:25,367 - DEBUG - test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM
> le=True
> 2013-10-09 20:38:25,386 - DEBUG - test_03_restore_vm_with_new_template 
> (test_base_image_updation.TestBaseImageUpdate) - Checking template id of VM
> le=False
> 2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Creating recurring snapshot 
> po
>  disk on vm created with IsVolatile=True
> 2013-10-09 20:38:30,541 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Snapshot Policy - Type : 
> HOURL
> inute : 53
> 2013-10-09 20:38:30,982 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Sleeping for 25 minutes till 
> t
> snapshoted
> 
> ==> result.log <==
> ok
> test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) ...
> ==> client.log <==
> 2013-10-09 21:11:51,780 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Checking whether root disk of
> atile=True was destroyed
> 2013-10-09 21:11:51,827 - DEBUG - test_04_reoccuring_snapshot_rules 
> (test_base_image_updation.TestBaseImageUpdate) - Checking whether snapshot 
> rule
> isVolatile=True was destroyed
> 
> ==> result.log <==
> ok
> 
> --
> Ran 4 tests in 3534.241s
> 
> OK
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: ui styling

2013-10-29 Thread Frankie Onuonga

I also wish this was the case.
I am still trying to get in touch with the team to assist them with this.
Hope someone gets back to me.

I think I can commit a week to get this done.

thanks

On Wed, Oct 30, 2013 at 4:35 AM, Marcus Sorensen wrote:

> I'm digging the UI styling changes!  It makes me wish they were all
> merged in from a branch as a squashed commit so I could pull them out
> and apply them to our local 4.2 build.
>

-- 
Skype: Frankie Onuonga
twitter: Frankie.onuonga
irc #freenode: Frankie.onuonga

Re: Wiki access

2013-10-29 Thread Prasanna Santhanam

permissions granted : gaurav, nitin, damoder, willstevens

On Tue, Oct 29, 2013 at 04:29:08PM -0400, Will Stevens wrote:
> I also need access.
> un: wstevens
> email: wstev...@cloudops.com
> 
> 
> On Tue, Oct 29, 2013 at 5:02 AM, Damoder Reddy 
> wrote:
> 
> > Please grant me edit access..
> > Email : damoder.re...@citrix.com
> > Username: Damoder.reddy
> >
> > -Original Message-
> > From: Nitin Mehta [mailto:nitin.me...@citrix.com]
> > Sent: Tuesday, 29 October 2013 7:18 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: Wiki access
> >
> > Please grant me edit access.
> > Email - nitin.me...@citrix.com
> >
> > On 28/10/13 5:17 AM, "Gaurav Aradhye"  wrote:
> >
> > >Hi,
> > >
> > >My username is gauravaradhye.
> > >Can anyone grant me edit permission?
> > >
> > >I need to update test plan automation columns.
> > >
> > >
> > >Regards,
> > >Gaurav
> > >
> > >
> > >On Fri, Oct 18, 2013 at 5:26 PM, Kishan Kavala
> > >wrote:
> > >
> > >> Thanks Hugo.
> > >>
> > >> > -Original Message-
> > >> > From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> > >> > Trippaers
> > >> > Sent: Friday, 18 October 2013 4:39 PM
> > >> > To: dev@cloudstack.apache.org
> > >> > Subject: Re: Wiki access
> > >> >
> > >> > Hey Kishan,
> > >> >
> > >> > I've granted you permissions. There apparently is another Kishan
> > >> > with
> > >> edit
> > >> > permission as well, so i got confused.
> > >> >
> > >> > Cheers,
> > >> >
> > >> > Hugo
> > >> >
> > >> > On 18 okt. 2013, at 12:38, Kishan Kavala 
> > >> wrote:
> > >> >
> > >> > > Hugo,
> > >> > > I've checked again. My account doesn't have edit permission.
> > >> > >
> > >> > >> -Original Message-
> > >> > >> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo
> > >>Trippaers
> > >> > >> Sent: Wednesday, 16 October 2013 7:59 PM
> > >> > >> To: dev@cloudstack.apache.org
> > >> > >> Subject: Re: Wiki access
> > >> > >>
> > >> > >> Kishan,
> > >> > >>
> > >> > >> look like you have the permissions already on account kishan.
> > >> > >> Can
> > >>you
> > >> check?
> > >> > >>
> > >> > >> Cheers,
> > >> > >>
> > >> > >> Hugo
> > >> > >>
> > >> > >>
> > >> > >> On Oct 16, 2013, at 3:45 PM, Kishan Kavala
> > >>
> > >> > wrote:
> > >> > >>
> > >> > >>> Please grant me edit access.
> > >> > >>> Email: kis...@cloud.com
> > >> > >>>
> > >> > >>> ~kishan
> > >> > >>>
> > >> >  -Original Message-
> > >> >  From: Radhika Puthiyetath
> > >> >  [mailto:radhika.puthiyet...@citrix.com]
> > >> >  Sent: Wednesday, 16 October 2013 3:22 PM
> > >> >  To: dev@cloudstack.apache.org
> > >> >  Subject: RE: Wiki access
> > >> > 
> > >> >  Hi,
> > >> > 
> > >> >  I do not have the edit permissions. My username is radhikap.
> > >> > 
> > >> >  Kindly provide me with the necessary permissions.
> > >> > 
> > >> >  Thanks
> > >> >  -Radhika
> > >> > 
> > >> >  -Original Message-
> > >> >  From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> > >> >  Sent: Friday, October 04, 2013 3:26 PM
> > >> >  To: dev
> > >> >  Subject: Re: Wiki access
> > >> > 
> > >> >  anshulg is in
> > >> > 
> > >> > 
> > >> >  On Fri, Oct 4, 2013 at 11:51 AM, Anshul Gangwar
> > >> >  wrote:
> > >> > 
> > >> > > need edit permissions , username: anshulg
> > >> > >
> > >> > > Regards,
> > >> > > Anshul
> > >> > >
> > >> > > On Friday 04 October 2013 02:47 PM, Saksham Srivastava wrote:
> > >> > >> Please provide me edit permissions, username: saksham
> > >> > >>
> > >> > >> Regards,
> > >> > >> Saksham
> > >> > >>
> > >> > >> -Original Message-
> > >> > >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> > >> > >> Sent: Friday, October 04, 2013 10:46 AM
> > >> > >> To: dev@cloudstack.apache.org
> > >> > >> Subject: Re: Wiki access
> > >> > >>
> > >> > >> Mike, Tuna, Srinivas, Go, done.
> > >> > >>
> > >> > >> On 10/3/13 9:12 PM, "Mike Tutkowski"
> > >> > >> 
> > >> > > wrote:
> > >> > >>
> > >> > >>> I seem to need edit access, as well.
> > >> > >>>
> > >> > >>> I'm usually logged in by default, but I believe my username
> > >> > >>> is mike-tutkowski (else please try mtutkowski).
> > >> > >>>
> > >> > >>> Thanks!
> > >> > >>>
> > >> > >>>
> > >> > >>> On Thu, Oct 3, 2013 at 7:07 PM, Go Chiba
> > >> > >>> 
> > >> > wrote:
> > >> > >>>
> > >> >  Hi Chip,
> > >> > 
> > >> >  Please grant me to edit pages. My id is "gochiba".
> > >> > 
> > >> > 
> > >> >  On Thu, Oct 3, 2013 at 6:01 AM, Chip Childers
> > >> >   > >> > > wrote:
> > >> > > Not all committers were easy to find, but those that I
> > >> > > did should be
> > >> >  all
> > >> > > set.
> > >> > >
> > >> > > So committers / contributors = provide your confluen

Re: [Cloudmonkey] assignVirtualMachine API causes index out of range error

2013-10-29 Thread Rohit Yadav

On Mon, Oct 28, 2013 at 1:52 PM, Sebastien Goasguen wrote:

> I think the error is in the java code of AssignVirtualMachine:
> api/src/org/apache/cloudstack/api/command/admin/vm/AssignVMCmd.java:
>
> @APICommand(name = "assignVirtualMachine", description="Change ownership
> of a VM from one account to another. This API is available for Basic zones
> with security groups and Advanced zones with guest networks. A root
> administrator can reassign a VM from any account to any other account in
> any domain. A domain administrator can reassign a VM to any account in the
> same domain.", responseObject=UserVmResponse.class, since="3.0.0")
> public class AssignVMCmd extends BaseCmd  {
> public static final Logger s_logger =
> Logger.getLogger(AssignVMCmd.class.getName());
>
>private static final String s_name = "moveuservmresponse";
>
>
> Shouldn't the string be "assignvirtualmachineresponse" ?
>

Thanks Ryan for the output, Sebastien is right the response string of
AssignVMCmd
should be fixed. Please open a bug ticket, patch contributions are most
welcome :)

Regards.


>
> On Oct 27, 2013, at 11:02 PM, Ryan Lei  wrote:
>
> > Here's the assignVirtualMachine response json from log:
> >
> > 2013-10-25 17:02:54,107 - cloudmonkey.py:83 - [DEBUG] Loaded config
> fields:
> > ['cache_file=/root/.cloudmonkey/cache',
> > 'log_file=/root/.cloudmonkey/log', 'asyncblock=true',
> > 'paramcompletion=false', 'history_file=/root/.cloudmonkey/history',
> > 'color=true', 'prompt=> ', 'display=table',
> >
> 'secretkey=wOV6_F8BZXxXV0zfX_DLVscCtbGrZgV3h8AcWfQLIa-OBCddLJimXTIQaM9hFH5ggItwwIFcivjJ77zn7LjWCQ',
> >
> 'apikey=KbvOOFTETTNL8RbmSmA0d-zOw8BxRW1msmKTVj_2T8b42KrpMb5DoVwNrc2aKRonFFTZ7W6GsSeL2hvReek4WA',
> > 'path=/client/api', 'host=localhost', 'protocol=http', 'port=8080',
> > 'timeout=3600']
> >
> > 2013-10-25 17:03:19,839 - requester.py:45 - [DEBUG]  START
> > Request 
> > 2013-10-25 17:03:19,840 - requester.py:45 - [DEBUG] Requesting
> > command=assignVirtualMachine, args={'account': 'domain1-user2',
> > 'domainid': 'cfc19b03-0858-4f39-9058-e0b67685bc2f',
> > 'virtualmachineid': '939f1c53-91e8-47a1-92d1-9ec9c2c1802c'}
> > 2013-10-25 17:03:19,841 - requester.py:45 - [DEBUG] Request sent:
> >
> http://localhost:8080/client/api?account=domain1-user2&apiKey=KbvOOFTETTNL8RbmSmA0d-zOw8BxRW1msmKTVj_2T8b42KrpMb5DoVwNrc2aKRonFFTZ7W6GsSeL2hvReek4WA&command=assignVirtualMachine&domainid=cfc19b03-0858-4f39-9058-e0b67685bc2f&response=json&virtualmachineid=939f1c53-91e8-47a1-92d1-9ec9c2c1802c&signature=gcqky6emSpV08QHZuavLZFS6Pcg%3D
> >
> > 2013-10-25 17:03:20,107 - requester.py:45 - [DEBUG] Response received:
> > { "virtualmachine" :  { "virtualmachine" :
> >
> {"id":"939f1c53-91e8-47a1-92d1-9ec9c2c1802c","name":"domain1-admin","displayname":"domain1-admin","account":"domain1-user2","domainid":"cfc19b03-0858-4f39-9058-e0b67685bc2f","domain":"domain1","created":"2013-10-25T15:15:03+0800","state":"Stopped","haenable":false,"zoneid":"6e0b2791-513e-49be-bbd8-62c2597640ef","zonename":"Zone-Xen","templateid":"855b7915-9739-4ad7-945e-8b8514040198","templatename":"CentOS-6.4-x86_64
> > (scalable)","templatedisplaytext":"CentOS-6.4-x86_64
> >
> (scalable)","passwordenabled":false,"serviceofferingid":"32f7668c-5edd-4152-b927-c7b744281dc2","serviceofferingname":"Small
> >
> Instance","cpunumber":1,"cpuspeed":500,"memory":512,"cpuused":"0%","networkkbsread":0,"networkkbswrite":1,"diskkbsread":0,"diskkbswrite":0,"diskioread":0,"diskiowrite":0,"guestosid":"f70b6aaa-37da-11e3-9cb9-46ca9f9b4d97","rootdeviceid":0,"rootdevicetype":"ROOT","securitygroup":[],"nic":[{"id":"2f2a6ff3-ab11-4127-8991-2813a9a1c3ba","networkid":"aad53b98-3a6c-4cd3-a1e3-cbb84834d8c1","networkname":"domain1-user2-network","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.204","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:17:61:00:01"}],"hypervisor":"XenServer","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":true}
> > }  }
> > 2013-10-25 17:03:20,108 - requester.py:45 - [DEBUG]  END
> > Request 
> >
> >
> > I'm using Cloudmonkey from git (corresponding to 5.0.0), and I have tried
> > using root admin and domain admin to call this API. Both turned out to
> > succeed but crash Cloudmonkey.
> >
> >
> ---
> > Yu-Heng (Ryan) Lei, Associate Researcher
> > Chunghwa Telecom Laboratories / Cloud Computing Laboratory
> > ryan...@cht.com.tw<
> https://email.cht.com.tw/owa/redir.aspx?C=-wE1FEC3G0SWYpVkiWo8SsDdf3ZqO9AIuAPTzRnFYCUi-z4YljtI_hyVKkNHfn9F1Bn-vUWJnQ4.&URL=mailto%3aryanlei%40cht.com.tw
> >
> > or
> > ryanlei750...@gmail.com
> >
> >
> >
> > On Fri, Oct 25, 2013 at 7:02 PM, Rohit Yadav 
> wrote:
> >
> >> Hi Ryan,
> >>
> >> Will check this next week, the issue is clearly with response which
> lacks a
> >> key with name 'response' in it, it could be a case issue as well. Can
> you
> >> share wit

Re: Review Request 14058: Including tests for VPC VM Lifecycle on Tagged hosts


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


patch failed to apply on 4.2 

 git apply vmvpc.patch 
error: patch failed: test/integration/component/test_vpc_vm_life_cycle.py:182
error: test/integration/component/test_vpc_vm_life_cycle.py: patch does not 
apply


- SrikanteswaraRao Talluri


On Oct. 16, 2013, 2:09 p.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14058/
> ---
> 
> (Updated Oct. 16, 2013, 2:09 p.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, venkata swamy babu  
> budumuru, and Sheng Yang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added 10 tests for VPC VM liftcycle on tagged hosts
> 
> New class added  : TestVMLifeCycleDiffHosts
> 
> def test_01_deploy_instance_in_network(self):
> def test_02_stop_instance_in_network(self):
> def test_03_start_instance_in_network(self):
> def test_04_reboot_instance_in_network(self):
> def test_05_destroy_instance_in_network(self):
> def test_06_recover_instance_in_network(self):
> def test_07_migrate_instance_in_network(self):
> def test_08_user_data(self):
> def test_09_meta_data(self):
> def   test_10_expunge_instance_in_network(self):
> 
> This set of tests requires a multi host tagged setup (3 hosts - 2 hosts with 
> tag 'host1' and  1 host with tag 'host2')
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_vpc_vm_life_cycle.py 9844c1f 
>   tools/marvin/marvin/integration/lib/base.py 0d52224 
> 
> Diff: https://reviews.apache.org/r/14058/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM advanced setup.
> 
> Log:
> 
> test_01_deploy_instance_in_network 
> (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test deploy an instance in VPC networks ... ok
> test_02_stop_instance_in_network 
> (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test stop an instance in VPC networks ... ok
> test_03_start_instance_in_network 
> (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test start an instance in VPC networks ... ok
> test_04_reboot_instance_in_network 
> (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test reboot an instance in VPC networks ... ok
> test_05_destroy_instance_in_network 
> (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test destroy an instance in VPC networks ... ok
> test_06_migrate_instance_in_network 
> (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test migrate an instance in VPC networks ... ok
> test_07_user_data (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test user data in virtual machines ... ok
> test_08_meta_data (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test meta data in virtual machines ... ok
> test_09_expunge_instance_in_network 
> (test_vpc_vm_life_cycle.TestVMLifeCycleDiffHosts)
> Test expunge an instance in VPC networks ... ok
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: [Cloudmonkey] assignVirtualMachine API causes index out of range error

2013-10-29 Thread Ryan Lei

Ticket created:
https://issues.apache.org/jira/browse/CLOUDSTACK-4998

---
Yu-Heng (Ryan) Lei, Associate Researcher
Chunghwa Telecom Laboratories / Cloud Computing Laboratory
ryan...@cht.com.tw
or
ryanlei750...@gmail.com



On Wed, Oct 30, 2013 at 2:04 PM, Rohit Yadav  wrote:

> On Mon, Oct 28, 2013 at 1:52 PM, Sebastien Goasguen  >wrote:
>
> > I think the error is in the java code of AssignVirtualMachine:
> > api/src/org/apache/cloudstack/api/command/admin/vm/AssignVMCmd.java:
> >
> > @APICommand(name = "assignVirtualMachine", description="Change ownership
> > of a VM from one account to another. This API is available for Basic
> zones
> > with security groups and Advanced zones with guest networks. A root
> > administrator can reassign a VM from any account to any other account in
> > any domain. A domain administrator can reassign a VM to any account in
> the
> > same domain.", responseObject=UserVmResponse.class, since="3.0.0")
> > public class AssignVMCmd extends BaseCmd  {
> > public static final Logger s_logger =
> > Logger.getLogger(AssignVMCmd.class.getName());
> >
> >private static final String s_name = "moveuservmresponse";
> >
> >
> > Shouldn't the string be "assignvirtualmachineresponse" ?
> >
>
> Thanks Ryan for the output, Sebastien is right the response string of
> AssignVMCmd
> should be fixed. Please open a bug ticket, patch contributions are most
> welcome :)
>
> Regards.
>
>
> >
> > On Oct 27, 2013, at 11:02 PM, Ryan Lei  wrote:
> >
> > > Here's the assignVirtualMachine response json from log:
> > >
> > > 2013-10-25 17:02:54,107 - cloudmonkey.py:83 - [DEBUG] Loaded config
> > fields:
> > > ['cache_file=/root/.cloudmonkey/cache',
> > > 'log_file=/root/.cloudmonkey/log', 'asyncblock=true',
> > > 'paramcompletion=false', 'history_file=/root/.cloudmonkey/history',
> > > 'color=true', 'prompt=> ', 'display=table',
> > >
> >
> 'secretkey=wOV6_F8BZXxXV0zfX_DLVscCtbGrZgV3h8AcWfQLIa-OBCddLJimXTIQaM9hFH5ggItwwIFcivjJ77zn7LjWCQ',
> > >
> >
> 'apikey=KbvOOFTETTNL8RbmSmA0d-zOw8BxRW1msmKTVj_2T8b42KrpMb5DoVwNrc2aKRonFFTZ7W6GsSeL2hvReek4WA',
> > > 'path=/client/api', 'host=localhost', 'protocol=http', 'port=8080',
> > > 'timeout=3600']
> > >
> > > 2013-10-25 17:03:19,839 - requester.py:45 - [DEBUG]  START
> > > Request 
> > > 2013-10-25 17:03:19,840 - requester.py:45 - [DEBUG] Requesting
> > > command=assignVirtualMachine, args={'account': 'domain1-user2',
> > > 'domainid': 'cfc19b03-0858-4f39-9058-e0b67685bc2f',
> > > 'virtualmachineid': '939f1c53-91e8-47a1-92d1-9ec9c2c1802c'}
> > > 2013-10-25 17:03:19,841 - requester.py:45 - [DEBUG] Request sent:
> > >
> >
> http://localhost:8080/client/api?account=domain1-user2&apiKey=KbvOOFTETTNL8RbmSmA0d-zOw8BxRW1msmKTVj_2T8b42KrpMb5DoVwNrc2aKRonFFTZ7W6GsSeL2hvReek4WA&command=assignVirtualMachine&domainid=cfc19b03-0858-4f39-9058-e0b67685bc2f&response=json&virtualmachineid=939f1c53-91e8-47a1-92d1-9ec9c2c1802c&signature=gcqky6emSpV08QHZuavLZFS6Pcg%3D
> > >
> > > 2013-10-25 17:03:20,107 - requester.py:45 - [DEBUG] Response received:
> > > { "virtualmachine" :  { "virtualmachine" :
> > >
> >
> {"id":"939f1c53-91e8-47a1-92d1-9ec9c2c1802c","name":"domain1-admin","displayname":"domain1-admin","account":"domain1-user2","domainid":"cfc19b03-0858-4f39-9058-e0b67685bc2f","domain":"domain1","created":"2013-10-25T15:15:03+0800","state":"Stopped","haenable":false,"zoneid":"6e0b2791-513e-49be-bbd8-62c2597640ef","zonename":"Zone-Xen","templateid":"855b7915-9739-4ad7-945e-8b8514040198","templatename":"CentOS-6.4-x86_64
> > > (scalable)","templatedisplaytext":"CentOS-6.4-x86_64
> > >
> >
> (scalable)","passwordenabled":false,"serviceofferingid":"32f7668c-5edd-4152-b927-c7b744281dc2","serviceofferingname":"Small
> > >
> >
> Instance","cpunumber":1,"cpuspeed":500,"memory":512,"cpuused":"0%","networkkbsread":0,"networkkbswrite":1,"diskkbsread":0,"diskkbswrite":0,"diskioread":0,"diskiowrite":0,"guestosid":"f70b6aaa-37da-11e3-9cb9-46ca9f9b4d97","rootdeviceid":0,"rootdevicetype":"ROOT","securitygroup":[],"nic":[{"id":"2f2a6ff3-ab11-4127-8991-2813a9a1c3ba","networkid":"aad53b98-3a6c-4cd3-a1e3-cbb84834d8c1","networkname":"domain1-user2-network","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.204","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:17:61:00:01"}],"hypervisor":"XenServer","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":true}
> > > }  }
> > > 2013-10-25 17:03:20,108 - requester.py:45 - [DEBUG]  END
> > > Request 
> > >
> > >
> > > I'm using Cloudmonkey from git (corresponding to 5.0.0), and I have
> tried
> > > using root admin and domain admin to call this API. Both turned out to
> > > succeed but crash Cloudmonkey.
> > >
> > >
> >
>

Re: Review Request 14593: CLOUDSTACK-1833: Automation - Adding scale virtual machine test cases