RE: [ANNOUNCE] Saksham Srivastava as committer
Congrats Saksham. Thanks, RamG -Original Message- From: Ahmad Emneina [mailto:aemne...@gmail.com] Sent: 03 June 2014 11:06 To: dev@cloudstack.apache.org Subject: Re: [ANNOUNCE] Saksham Srivastava as committer Great work Saksham! Congratulations. On Mon, Jun 2, 2014 at 10:29 PM, Rajesh Battala rajesh.batt...@citrix.com wrote: Hearty Congratulations Saksham! -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: [DISCUSS] vpc gateway networks are guestnetworks
valid questions. i will answer in line shortly and expand later (on the wiki) On Tue, Jun 3, 2014 at 12:51 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Hi Daan, Thanks for the visual. It helps, but the use case outlined seems possible with a single VPC? The organisation at Schuberg Philis choose for heavy use of vpcs. The request for extra inter-vpc traffic possibilities is a consequence. Assuming that for some reason (please educate us) it is not possible to use a single VPC, it appears to me that we are inventing a new network type (“InterVPC”). This 'type' already exists. the private gateway functionality automatically creates it and will also delete it when the gw is removed. Who “owns” this network? Who creates it, updates it, deletes it, can read it? it is created when first attached to a private gateway and will be deleted when the last private gw is removed from it. Is it instantiated from a network offering? yes, a system offering, but it should be possible to use other offerings. If so, what is the restriction on this network offering? TBD Can it have an LB for instance? No unless. we will have to look at redundant routers for vpcs. that would invalidate one of the use cases for this network. Can multiple tenants attach to a single “intervpc” network? related to IAM. I have not decided on this. It would be nice functionality but also complicates security. First version? No. I will keep an open mind to it because I don't want to design something that blocks it. Can we extend the private gateway feature to this intervpc use case? The network part is actually quite simple. there are cidrs but only a single endpoint. We have to add an endpoint per cidr. The present cidr can be removed or defined to be the default. From: Daan Hoogland daan.hoogl...@gmail.com Date: Monday, June 2, 2014 at 3:42 AM To: Chiradeep Vittal chiradeep.vit...@citrix.com Cc: Alena Prokharchyk alena.prokharc...@citrix.com, Sheng Yang sheng.y...@citrix.com, Alex Huang alex.hu...@citrix.com, dev@cloudstack.apache.org dev@cloudstack.apache.org, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com Subject: Re: [DISCUSS] vpc gateway networks are guestnetworks H, Please, have a look at the example picture in https://cwiki.apache.org/confluence/display/CLOUDSTACK/inter+vpc+network It depicts a mix of the use cases I described earlier and gives an overview of the possibilities required. regards, Daan On Tue, May 27, 2014 at 10:15 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Absolutely, will be next week I am afraid. On Tue, May 27, 2014 at 7:04 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: Hi Daan, Sounds interesting! Could I beg you to post some images / figures and more text so that I can understand better? Thanks — Chiradeep From: Daan Hoogland daan.hoogl...@gmail.com Date: Monday, May 26, 2014 at 3:39 AM To: Chiradeep Vittal chiradeep.vit...@citrix.com Cc: Alena Prokharchyk alena.prokharc...@citrix.com, Sheng Yang sheng.y...@citrix.com, Alex Huang alex.hu...@citrix.com, dev@cloudstack.apache.org dev@cloudstack.apache.org, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com Subject: Re: [DISCUSS] vpc gateway networks are guestnetworks Chiradeep, I read the vpc-peering option again and it seems not to give us enough. We want a superset of this feature where more then two vpc can be connected to the same intervpc network. Use cases are - have a single monitor and other management devices for several applications in different vpcs - have a promotion mechanism across test/acceptance/prod/postprod environments - (as long as we don't have redundant vpc routers) have a management environment connected to two vpc's to manage fail-over/dr scenario's using all peer to peer connections for this can get rather mashy. What do you think? Daan On Fri, May 23, 2014 at 10:56 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: As you can see it isn’t trivial. I guess you refer to the overlapping cidrs. I am afraid that some responsibility here will have to lay with the domain admin(s). If we limit inter vpc networks to one domain we can enforce the ip ranges not to overlap. the routing problem is tackled by a next hop field near the cidr. I am sure I am missing some other non trivial challenges. On Fri, May 23, 2014 at 7:23 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I guess the ‘proper’ way to have done this would be to have a ‘createPrivateGateway’ API that is independent of the vpc and a attachPrivateGateway that attaches it to the vpc. Re: next hop, I’d like to see an FS for this feature. It seems to me that it is very similar to VPC peering (http://goo.gl/Y7tNkM). As you can see it isn’t trivial. From: Daan Hoogland daan.hoogl...@gmail.com Date: Friday, May 23, 2014 at 2:06 AM To: Chiradeep Vittal chiradeep.vit...@citrix.com, Alena Prokharchyk alena.prokharc...@citrix.com, Sheng Yang
RE: [ANNOUNCE] Amogh Vasekar as committer
Congrats Amogh :-) -Original Message- From: Nitin Mehta [mailto:nitin.me...@citrix.com] Sent: 02 June 2014 23:47 To: dev@cloudstack.apache.org Subject: Re: [ANNOUNCE] Amogh Vasekar as committer Great news. Congrats Amogh !!! On 02/06/14 11:14 AM, John Kinsella j...@stratosec.co wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Amogh Vasekar to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Amogh! -John, on behalf of the CloudStack PMC
Re: VPC's VR missing public NIC eth1
one clarification, I was not suggesting changing vlan://x back to x, just the case where x==untagged. I had a little analog discussion with Hugo and he convinced me that untagged has no special meaning in SDN cases, maybe for vxlan. So the problem I saw is at least smaller then in my mind. I have committed the db change to update 4.3.0 to 4.4.0. It will need heavy testing. And I didn't extensively look into other tables that need such a change. networks is the likely candidate but there may be others. On Mon, Jun 2, 2014 at 6:38 PM, Marcus shadow...@gmail.com wrote: Just to recap... I was trying to review the issue in my head and thought it might be useful to write it down. in 4.3 we got the BroadcastDomainType enum introduced, and many parts of the code were changed to use that when dealing with the vlan id. This code, among other things, returns a vlan id in URI format, describing both the technology used to provide the virtual lan, along with the id. Along the way this seems to have caused the value itself to be stored as a URI (still not sure where, by whom, or if it was intentional). That was fine and seemed to work after some fixing, until there was an upgrade done where the existing database value was NOT in URI format. We had a few places where the code was never changed to use BroadcastDomainType to 'normalize' the info from the database (e.g. the IpAssocVpcCommand the mgmt server constructs), so upgrades are broken. Most places in the code as it is now are working with a live value of 'vlan://x', regardless of whether the database has 'vlan://x' or just 'x', thanks to this code it returns the same 'vlan://' for either stored value. For these places it shouldn't matter if we fix the old databases to store 'vlan://x' or the 4.3 installs to go back to 'x'. However, there are a few places that are broken, like this IpAssocVpcCommand the mgmt server creates and CLOUDSTACK-5505. If we switch the db value back, we have to identify all of the outstanding ones and fix them. In addition, new code since then may have perhaps assumed that the db value is 'vlan://', and might have bothered to pass through the interpolation, so they may break as well. If we had full coverage on the test suite it would be easy to change the value back in the DB of a 4.3 or 4.4 install and see what breaks. If we don't switch the value back, and instead update old databases to the current way, it fixes the immediate issue but we end up with code doing the same thing in two different ways. Some places will be using the raw db value and other places will be asking for it to be normalized, and both will have the same result, which is kind of messy and prone to causing issues down the road if something changes again to separate these two. On Mon, Jun 2, 2014 at 10:01 AM, Marcus shadow...@gmail.com wrote: I'm not sure the KVM code needs to be changed, you're asking it to deal with an inconsistency from the mgmt server. Don't you find it odd that one Command from the mgmt server provides broadcastUri=vlan://untagged and another provides broadcastUri=untagged? I'm not sure I understand why changing 'untagged' into a URI format changes its meaning, but it seems like that doesn't make any sense to you, so perhaps we can break that out into a separate column so that we can still capture the info, if needed. If we don't like URI format for the vlan id, that's fine, but we need to do changes to the 4.3 installs and fix 4.4. As mentioned, I remember there being a decent amount of work to handle the vlan:// when it was introduced, and that will need to be done again to change it back. I'm not against that, but I'm not going to be the one doing that work, either :-) On Mon, Jun 2, 2014 at 3:47 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: I don't think this should be solved this way afterall. 'untagged' actually means no vlan, so it should not be prepended with 'vlan://'. I think the kvm code should be fixed for this not the generic code. On Fri, May 30, 2014 at 10:59 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: On Fri, May 30, 2014 at 10:51 PM, Marcus shadow...@gmail.com wrote: Looks good to me, aside from he debug statement. Ah, the first line was not in my line of sight. -- Daan -- Daan -- Daan
Re: [ANNOUNCE] Amogh Vasekar as committer
have fun Amogh (and bring us joy) On Tue, Jun 3, 2014 at 8:19 AM, Suresh Sadhu suresh.sa...@citrix.com wrote: Congrats Amogh :-) -Original Message- From: Nitin Mehta [mailto:nitin.me...@citrix.com] Sent: 02 June 2014 23:47 To: dev@cloudstack.apache.org Subject: Re: [ANNOUNCE] Amogh Vasekar as committer Great news. Congrats Amogh !!! On 02/06/14 11:14 AM, John Kinsella j...@stratosec.co wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Amogh Vasekar to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Amogh! -John, on behalf of the CloudStack PMC -- Daan
Re: New Defects reported by Coverity Scan for cloudstack
These are the approximate number of defects reported by coverity from the generated code. /awsapi/src/com/amazon/ec2 - around 4300 /awsapi/src/com/amazon/s3 - around 350 total defects - around 6500 ~Rajani On 02-Jun-2014, at 4:57 pm, Rajani Karuturi rajani.karut...@citrix.com wrote: Hi Hugo, awsapi-generated-code is excluded for the project but I still see issues reported in them. For example for file src/com/amazon/ec2/DeleteTagsResponseType.java Can you check the file exclude pattern? I think .* is missing (awsapi/src/com/amazon/.*) Fixing this might give us a better report as I see lot of them listed in these files. ~Rajani On 29-Nov-2013, at 9:28 pm, Hugo Trippaers trip...@gmail.com wrote: FYI Sent from my iPhone Begin forwarded message: From: scan-ad...@coverity.com Date: 29 november 2013 14:39:56 CET Subject: New Defects reported by Coverity Scan for cloudstack Hi, Please find the latest report on new defect(s) introduced to cloudstack found with Coverity Scan. Defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1116269: Nesting level does not match indentation (NESTING_INDENT_MISMATCH) /awsapi/src/com/cloud/bridge/service/controller/s3/ServiceProvider.java: 124 in com.cloud.bridge.service.controller.s3.ServiceProvider.getManagementHostId()() ** CID 1133706: Dereference after null check (FORWARD_NULL) /server/src/com/cloud/vm/UserVmManagerImpl.java: 2803 in com.cloud.vm.UserVmManagerImpl$3.doInTransaction(com.cloud.utils.db.TransactionStatus)() ** CID 1133705: Resource leak on an exceptional path (RESOURCE_LEAK) /server/src/com/cloud/server/ConfigurationServerImpl.java: 638 in com.cloud.server.ConfigurationServerImpl.updateSSLKeystore()() ** CID 1133704: SS: Unread field should be static (FB.SS_SHOULD_BE_STATIC) /server/src/com/cloud/uuididentity/UUIDManagerImpl.java: 43 in () ** CID 1133703: Dm: Dubious method used (FB.DM_DEFAULT_ENCODING) /plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LdapImportUsersCmd.java: 197 in org.apache.cloudstack.api.command.LdapImportUsersCmd.generatePassword()() ** CID 1133702: DLS: Dead local store (FB.DLS_DEAD_LOCAL_STORE) /plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/model/VirtualMachineModel.java: 119 in org.apache.cloudstack.network.contrail.model.VirtualMachineModel.buildServiceInstance(org.apache.cloudstack.network.contrail.model.ModelController, java.lang.String)() To view the defects in Coverity Scan visit, http://scan.coverity.com To unsubscribe from the email notification for new defects, http://scan5.coverity.com/cgi-bin/unsubscribe.py
Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- Review request for cloudstack, Abhinandan Prateek and daan Hoogland. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java da71d44 Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
Re: [ACS4.4] [Issue] Unable to create a autoscalevmprofile
Thanks Daan.
On Fri, May 30, 2014 at 1:59 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
Long accountId =
_accountService.finalyzeAccountId(accountName, domainId, projectId,
true);
_accountService didn't get initialized/injected!?! The spring stuff
should have taken care of that.
I think the problem is in the test initialization not in the base code.
On Fri, May 30, 2014 at 7:58 AM, Meghna Kale meghna.k...@sungardas.com
wrote:
Hi Daan,
I'm testing on 4.4-forward-iam branch.
Thanks
Meghna.
On Thu, May 29, 2014 at 6:56 PM, Daan Hoogland daan.hoogl...@gmail.com
wrote:
Megha,
in my current 4.4 line 411 of DeployVMCmd reads
if (accountId == null) {
hence it doesn't refer a pointer at that line.
which version are you using to get this:
java.lang.NullPointerException
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:411)
On Thu, May 29, 2014 at 12:53 PM, Meghna Kale
meghna.k...@sungardas.com
wrote:
Hi All,
I was trying to create a autoscalevmprofile with a sample data for a
test
case. Can anyone help me to know is there anything I'm missing in the
input
parameters ?
I get a nullpointer error is it due to the missing deployParams
parameter ?
I'm running this test on simulator.
self.account_1A = Account.create(
self.apiclient,
self.services[account1A],
admin=False,
domainid=self.domain_1.id
)
self.userapiclient_1A =
self.testClient.getUserApiClient(self.user_1A.username,
self.domain_1.name)
self.service_offering = ServiceOffering.create(
self.apiclient,
self.services[service_offering][small]
)
self.zone = get_zone(self.apiclient,
testClient.getZoneForTests())
list_users = User.list(
self.apiclient,
listall=self.services[listall],
account=self.account_1A.name,
domainid=self.domain_1.id
)
self.template = get_template(self.apiclient, self.zone.id,
self.services[ostype])
counterparam = { snmpcommunity: public, snmpport: 161}
autoscalevm_profile_1A = Autoscale.createAutoscaleVmProfile(
self.userapiclient_1A,
serviceofferingid=self.service_offering.id,
zoneid=
self.zone.id,
templateid=
self.template.id,
autoscaleuserid=list_users[0].id,
destroyvmgraceperiod='100',
counterparam=counterparam
)
I get this error in the logs :
ERROR [c.c.a.ApiServer] (25349580@qtp-22625812-44:ctx-76e14380
ctx-e717232f
ctx-7cea9dc0) unhandled exception executing api command:
[Ljava.lang.String;@17c7c4d
java.lang.NullPointerException
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:411)
at
com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:227)
at
com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:221)
at
com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:93)
at
com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
at
com.cloud.network.as.AutoScaleManagerImpl.createAutoScaleVmProfile(AutoScaleManagerImpl.java:373)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/#review44603 --- Ship it! master: commit 2424d9a9e0f1189044303a98c40e60033808f0b2 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com 4.4-forward: commit 67d92726cb4b0b195804fb8a3e3c76f9a2341b39 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com - Hugo Trippaers On June 3, 2014, 7:07 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 7:07 a.m.) Review request for cloudstack, Abhinandan Prateek and daan Hoogland. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java da71d44 Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
On June 3, 2014, 7:20 a.m., Hugo Trippaers wrote: master: commit 2424d9a9e0f1189044303a98c40e60033808f0b2 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com 4.4-forward: commit 67d92726cb4b0b195804fb8a3e3c76f9a2341b39 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com Cherry-picked to release branch - Hugo --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/#review44603 --- On June 3, 2014, 7:07 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 7:07 a.m.) Review request for cloudstack, Abhinandan Prateek and daan Hoogland. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java da71d44 Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
RE: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
Not able to mark it inside the review, so making a note here. The below statement ( preparestatement creation) is called inside the while loop multiple times, but was closed only once in finally. This may still result in leak. pstmtCidr = conn.prepareStatement(networkAclItemCidrSql); 1. Either use the existing logic only, but move pstmtCidr.close(); inside the inner for loop. 2. Or a way to create prpearestatement out of while loop and execute multiple sql statements, provided preparestatement creation is successful and execute them in batch. Thanks! Santhosh From: Hugo Trippaers [nore...@reviews.apache.org] on behalf of Hugo Trippaers [htrippa...@schubergphilis.com] Sent: Tuesday, June 03, 2014 3:22 AM To: daan Hoogland; Abhinandan Prateek Cc: Rajani Karuturi; Hugo Trippaers; cloudstack Subject: Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity On June 3, 2014, 7:20 a.m., Hugo Trippaers wrote: master: commit 2424d9a9e0f1189044303a98c40e60033808f0b2 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com 4.4-forward: commit 67d92726cb4b0b195804fb8a3e3c76f9a2341b39 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com Cherry-picked to release branch - Hugo --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/#review44603 --- On June 3, 2014, 7:07 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 7:07 a.m.) Review request for cloudstack, Abhinandan Prateek and daan Hoogland. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java da71d44 Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
Re: [ACS44] Cherry pick CLOUDSTACK-6599
strong point, I added both commits. Are there tests to the old code as well? this is a lot of untested code like this. On Mon, Jun 2, 2014 at 7:50 PM, Nitin Mehta nitin.me...@citrix.com wrote: Daan - Thanks for your comment. The java upgrade code has never been data migration code only. I have always seen complex DDL logic being handled by java upgrade code because we can write complex logic and catch exceptions gracefully. As you see from the links below - add column if it doesn't exist logic is not trivial and hence its been added in java upgrade path. I have infact borrowed the logic from upgrade410-420 java code. Therefore, you can't figure out the schema through the schema sql files. Thanks, -Nitin On 31/05/14 2:19 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: now your are changing schema in java code! please don't do that. Those are for data migration. If we start 5.0 we want to be able read the sql to find the actual schema. http://stackoverflow.com/questions/972922/add-column-to-mysql-table-if-it- does-not-exist http://stackoverflow.com/questions/14381895/mysql-add-column-if-not-exist On Sat, May 31, 2014 at 2:05 AM, Nitin Mehta nitin.me...@citrix.com wrote: Please cherry-pick be765ce8680564b743a73dd360c590c0e495c204 as well as part of this bug. One more thing to add, majority of code is for the functionality which I found missing in 4.4 and found some bugs which I termed as improvements over previous design. Thanks, -Nitin On 30/05/14 3:06 PM, Nitin Mehta nitin.me...@citrix.com wrote: Daan - Here improvements are actually bug fixes that should be fixed. Thanks, -Nitin On 30/05/14 1:47 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: That's a lot of improvements without tests, Nitin. On Fri, May 30, 2014 at 8:14 PM, Nitin Mehta nitin.me...@citrix.com wrote: Hello Daan, Can you please cherry-pick the following commit from 4.4-forward to 4.4 ? commit 48ea9e0b5e87fee067b711890cd5a5d7c9079bf1 CLOUDSTACK-6599: 1. Adding the missing Template/Volume URLs expiration functionality 2. Improvement - While deleting the volume during expiration use rm -rf as vmware now contains directoy 3. Improvement - Use standard Answer so that the error gets logged in case deletion of expiration link didnt work fine. 4. Improvement - In case of domain change, expire the old urls Thanks, -Nitin -- Daan -- Daan -- Daan
RE: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
Good find Santhosh. I missed the outer loop while doing the review. Cheers, Hugo -Original Message- From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] Sent: Tuesday, June 03, 2014 9:35 AM To: dev@cloudstack.apache.org; Hugo Trippaers; daan Hoogland; Abhinandan Prateek Cc: Rajani Karuturi Subject: RE: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Not able to mark it inside the review, so making a note here. The below statement ( preparestatement creation) is called inside the while loop multiple times, but was closed only once in finally. This may still result in leak. pstmtCidr = conn.prepareStatement(networkAclItemCidrSql); 1. Either use the existing logic only, but move pstmtCidr.close(); inside the inner for loop. 2. Or a way to create prpearestatement out of while loop and execute multiple sql statements, provided preparestatement creation is successful and execute them in batch. Thanks! Santhosh From: Hugo Trippaers [nore...@reviews.apache.org] on behalf of Hugo Trippaers [htrippa...@schubergphilis.com] Sent: Tuesday, June 03, 2014 3:22 AM To: daan Hoogland; Abhinandan Prateek Cc: Rajani Karuturi; Hugo Trippaers; cloudstack Subject: Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity On June 3, 2014, 7:20 a.m., Hugo Trippaers wrote: master: commit 2424d9a9e0f1189044303a98c40e60033808f0b2 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com 4.4-forward: commit 67d92726cb4b0b195804fb8a3e3c76f9a2341b39 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com Cherry-picked to release branch - Hugo --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/#review44603 --- On June 3, 2014, 7:07 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 7:07 a.m.) Review request for cloudstack, Abhinandan Prateek and daan Hoogland. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java da71d44 Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
RE: [ANNOUNCE] Amogh Vasekar as committer
Congratulations Amogh! Regards, Likitha -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Monday, June 2, 2014 11:44 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Amogh Vasekar as committer The Project Management Committee (PMC) for Apache CloudStack has asked Amogh Vasekar to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Amogh! -John, on behalf of the CloudStack PMC
Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 8:41 a.m.) Review request for cloudstack, Abhinandan Prateek and daan Hoogland. Changes --- uploaded another patch to fix the issue raised by Santhosh in the review comment Not able to mark it inside the review, so making a note here. The below statement ( preparestatement creation) is called inside the while loop multiple times, but was closed only once in finally. This may still result in leak. pstmtCidr = conn.prepareStatement(networkAclItemCidrSql); 1. Either use the existing logic only, but move pstmtCidr.close(); inside the inner for loop. 2. Or a way to create prpearestatement out of while loop and execute multiple sql statements, provided preparestatement creation is successful and execute them in batch. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs (updated) - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java 7fe285f Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
Good find Santhosh. I uploaded another patch on review board to fix this. ~Rajani On 03-Jun-2014, at 1:41 pm, Hugo Trippaers htrippa...@schubergphilis.com wrote: Good find Santhosh. I missed the outer loop while doing the review. Cheers, Hugo -Original Message- From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] Sent: Tuesday, June 03, 2014 9:35 AM To: dev@cloudstack.apache.org; Hugo Trippaers; daan Hoogland; Abhinandan Prateek Cc: Rajani Karuturi Subject: RE: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Not able to mark it inside the review, so making a note here. The below statement ( preparestatement creation) is called inside the while loop multiple times, but was closed only once in finally. This may still result in leak. pstmtCidr = conn.prepareStatement(networkAclItemCidrSql); 1. Either use the existing logic only, but move pstmtCidr.close(); inside the inner for loop. 2. Or a way to create prpearestatement out of while loop and execute multiple sql statements, provided preparestatement creation is successful and execute them in batch. Thanks! Santhosh From: Hugo Trippaers [nore...@reviews.apache.org] on behalf of Hugo Trippaers [htrippa...@schubergphilis.com] Sent: Tuesday, June 03, 2014 3:22 AM To: daan Hoogland; Abhinandan Prateek Cc: Rajani Karuturi; Hugo Trippaers; cloudstack Subject: Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity On June 3, 2014, 7:20 a.m., Hugo Trippaers wrote: master: commit 2424d9a9e0f1189044303a98c40e60033808f0b2 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com 4.4-forward: commit 67d92726cb4b0b195804fb8a3e3c76f9a2341b39 Author: Rajani Karuturi rajanikarut...@gmail.com Date: Tue Jun 3 12:31:20 2014 +0530 Fixed ResouceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com Cherry-picked to release branch - Hugo --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/#review44603 --- On June 3, 2014, 7:07 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 7:07 a.m.) Review request for cloudstack, Abhinandan Prateek and daan Hoogland. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java da71d44 Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
Regarding Blocker bug CLOUDSTACK-6603
Hi, This bug https://issues.apache.org/jira/browse/CLOUDSTACK-6603 [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4] got introduced by the feature of Autoscaling without netscaler A new column last_interval got added to autoscale_vmgroups table by this commit (dc151115be3e922933ea26ab1507eb6469a91e11). Schema of autoscale_vmgroups table got changed in wrong version of schema file cause the upgrade failed. Instead of adding schema change to the upgrade path file it was added to setup/db/db/schema-40to410.sql file. It should be added to schema43to44 upgrade path. Because of this issues, upgrade from 4.3 to 4.4 and 4.3 to 4.4 will fail. @Tuna, can you please have a look at your commit and fix it. @Daan, if this issue CLOUDSTACK-6603 is not fixed, upgrades from 4.2 to 4.4 and 4.3 to 4.4 will fail. As 4.4 feature freeze had happened long back, Am not sure whether we can change db schema now in 4.4 branch Thanks Rajesh Battala
Unable to upload SSL certificate
Hi, I am trying to upload an SSL certificate to Cloudstack using uploadSslCert API since 4.3 version does not have UI support for the same. And I am getting following exception: Invalid Certificate format. Expected X509 certificate The certificate, private key and certificate-chain are URL encoded and sent to the Cloudstack using a GET on 8096 port. On debugging, it was found that some characters were missing from certificate after it was decoded from the URL which is the cause of the exception. I am unable to figure out the reason, so can you please throw some light on why are some characters missing after decoding the certificate from the URL? Thank you, Sujaya
Review Request 22194: Fixed Resource leak reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/ --- Review request for cloudstack and Koushik Das. Repository: cloudstack-git Description --- Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting pstmt in pstmt = conn.prepareStatement(INSERT INTO `cloud`.`ldap_configuration`(hostname, port) VALUES(?,?)) leaks the resource that pstmt refers to. Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 Diff: https://reviews.apache.org/r/22194/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22194: Fixed Resource leak reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/#review44605 --- engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java https://reviews.apache.org/r/22194/#comment79024 This pstmt is not yet closed. - Santhosh Edukulla On June 3, 2014, 9:17 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/ --- (Updated June 3, 2014, 9:17 a.m.) Review request for cloudstack and Koushik Das. Repository: cloudstack-git Description --- Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting pstmt in pstmt = conn.prepareStatement(INSERT INTO `cloud`.`ldap_configuration`(hostname, port) VALUES(?,?)) leaks the resource that pstmt refers to. Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 Diff: https://reviews.apache.org/r/22194/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22194: Fixed Resource leak reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/ --- (Updated June 3, 2014, 9:31 a.m.) Review request for cloudstack and Koushik Das. Repository: cloudstack-git Description --- Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting pstmt in pstmt = conn.prepareStatement(INSERT INTO `cloud`.`ldap_configuration`(hostname, port) VALUES(?,?)) leaks the resource that pstmt refers to. Diffs (updated) - engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 Diff: https://reviews.apache.org/r/22194/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22194: Fixed Resource leak reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/#review44606 --- engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java https://reviews.apache.org/r/22194/#comment79025 Here, it is creating multiple statements but close again is happening outside of for loop. This will still result in leak. engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java https://reviews.apache.org/r/22194/#comment79026 Related to previous comment, either move prepared statement out of forloop and retain close here. engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java https://reviews.apache.org/r/22194/#comment79027 Once you close set it back to null. Otherwise in finally it may still refer to dangling pointer. - Santhosh Edukulla On June 3, 2014, 9:31 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/ --- (Updated June 3, 2014, 9:31 a.m.) Review request for cloudstack and Koushik Das. Repository: cloudstack-git Description --- Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting pstmt in pstmt = conn.prepareStatement(INSERT INTO `cloud`.`ldap_configuration`(hostname, port) VALUES(?,?)) leaks the resource that pstmt refers to. Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 Diff: https://reviews.apache.org/r/22194/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22194: Fixed Resource leak reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/#review44608 --- engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java https://reviews.apache.org/r/22194/#comment79029 from the javadoc Calling the method close on a Statement object that is already closed has no effect. so, this will not be an issue - Rajani Karuturi On June 3, 2014, 9:31 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/ --- (Updated June 3, 2014, 9:31 a.m.) Review request for cloudstack and Koushik Das. Repository: cloudstack-git Description --- Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting pstmt in pstmt = conn.prepareStatement(INSERT INTO `cloud`.`ldap_configuration`(hostname, port) VALUES(?,?)) leaks the resource that pstmt refers to. Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 Diff: https://reviews.apache.org/r/22194/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22194: Fixed Resource leak reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/ --- (Updated June 3, 2014, 10:42 a.m.) Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Santhosh Edukulla. Repository: cloudstack-git Description --- Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting pstmt in pstmt = conn.prepareStatement(INSERT INTO `cloud`.`ldap_configuration`(hostname, port) VALUES(?,?)) leaks the resource that pstmt refers to. Diffs (updated) - engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 Diff: https://reviews.apache.org/r/22194/diff/ Testing --- Thanks, Rajani Karuturi
Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22197/ --- Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla. Bugs: CLOUDSTACK-6776 https://issues.apache.org/jira/browse/CLOUDSTACK-6776 Repository: cloudstack-git Description --- The test case fails whenever hard coded values overlap with already configured VLAN in the physical network. Removed hard code VLAN ids and used the common function to get unused VLAN ids from the physical network dynamically. Diffs - test/integration/smoke/test_non_contigiousvlan.py 90235ec Diff: https://reviews.apache.org/r/22197/diff/ Testing --- Yes. Log: Test to update a physical network and extend its vlan ... === TestName: test_extendPhysicalNetworkVlan | Status : SUCCESS === ok -- Ran 1 test in 15.328s OK ~ ~ Thanks, Ashutosh Kelkar
Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 11:02 a.m.) Review request for cloudstack, Abhinandan Prateek, daan Hoogland, and Santhosh Edukulla. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java 7fe285f Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
Re: [ANNOUNCE] Amogh Vasekar as committer
On 02.06.2014 19:14, John Kinsella wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Amogh Vasekar to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Amogh! -John, on behalf of the CloudStack PMC Congratulations, Amogh! :) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/#review44610 --- Ship it! Ship It! - Santhosh Edukulla On June 3, 2014, 11:02 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 11:02 a.m.) Review request for cloudstack, Abhinandan Prateek, daan Hoogland, and Santhosh Edukulla. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java 7fe285f Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22194: Fixed Resource leak reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/#review44611 --- Ship it! Ship It! - Santhosh Edukulla On June 3, 2014, 10:42 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/ --- (Updated June 3, 2014, 10:42 a.m.) Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Santhosh Edukulla. Repository: cloudstack-git Description --- Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting pstmt in pstmt = conn.prepareStatement(INSERT INTO `cloud`.`ldap_configuration`(hostname, port) VALUES(?,?)) leaks the resource that pstmt refers to. Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 Diff: https://reviews.apache.org/r/22194/diff/ Testing --- Thanks, Rajani Karuturi
Re: Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22197/#review44612 --- test/integration/smoke/test_non_contigiousvlan.py https://reviews.apache.org/r/22197/#comment79031 Is it ok to move to test data? test/integration/smoke/test_non_contigiousvlan.py https://reviews.apache.org/r/22197/#comment79034 We assigned self.vlan to Services()... and again list unpacking is using self.vlan, so self.vlan was overwritten, please check. test/integration/smoke/test_non_contigiousvlan.py https://reviews.apache.org/r/22197/#comment79032 It should be is None comparison. test/integration/smoke/test_non_contigiousvlan.py https://reviews.apache.org/r/22197/#comment79033 Do we want to fail in setup or raise exception? As such its a setup which is having issue not the test case.. - Santhosh Edukulla On June 3, 2014, 10:57 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22197/ --- (Updated June 3, 2014, 10:57 a.m.) Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla. Bugs: CLOUDSTACK-6776 https://issues.apache.org/jira/browse/CLOUDSTACK-6776 Repository: cloudstack-git Description --- The test case fails whenever hard coded values overlap with already configured VLAN in the physical network. Removed hard code VLAN ids and used the common function to get unused VLAN ids from the physical network dynamically. Diffs - test/integration/smoke/test_non_contigiousvlan.py 90235ec Diff: https://reviews.apache.org/r/22197/diff/ Testing --- Yes. Log: Test to update a physical network and extend its vlan ... === TestName: test_extendPhysicalNetworkVlan | Status : SUCCESS === ok -- Ran 1 test in 15.328s OK ~ ~ Thanks, Ashutosh Kelkar
Re: Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py
On June 3, 2014, 11:22 a.m., Santhosh Edukulla wrote: test/integration/smoke/test_non_contigiousvlan.py, line 29 https://reviews.apache.org/r/22197/diff/1/?file=602789#file602789line29 Is it ok to move to test data? Removed services dictionary as it is no longer used - Ashutosh --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22197/#review44612 --- On June 3, 2014, 11:45 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22197/ --- (Updated June 3, 2014, 11:45 a.m.) Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla. Bugs: CLOUDSTACK-6776 https://issues.apache.org/jira/browse/CLOUDSTACK-6776 Repository: cloudstack-git Description --- The test case fails whenever hard coded values overlap with already configured VLAN in the physical network. Removed hard code VLAN ids and used the common function to get unused VLAN ids from the physical network dynamically. Diffs - test/integration/smoke/test_non_contigiousvlan.py 90235ec Diff: https://reviews.apache.org/r/22197/diff/ Testing --- Yes. Log: Test to update a physical network and extend its vlan ... === TestName: test_extendPhysicalNetworkVlan | Status : SUCCESS === ok -- Ran 1 test in 15.328s OK ~ ~ Thanks, Ashutosh Kelkar
Re: Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22197/ --- (Updated June 3, 2014, 11:45 a.m.) Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla. Changes --- Review changes. Bugs: CLOUDSTACK-6776 https://issues.apache.org/jira/browse/CLOUDSTACK-6776 Repository: cloudstack-git Description --- The test case fails whenever hard coded values overlap with already configured VLAN in the physical network. Removed hard code VLAN ids and used the common function to get unused VLAN ids from the physical network dynamically. Diffs (updated) - test/integration/smoke/test_non_contigiousvlan.py 90235ec Diff: https://reviews.apache.org/r/22197/diff/ Testing --- Yes. Log: Test to update a physical network and extend its vlan ... === TestName: test_extendPhysicalNetworkVlan | Status : SUCCESS === ok -- Ran 1 test in 15.328s OK ~ ~ Thanks, Ashutosh Kelkar
Re: Regarding Blocker bug CLOUDSTACK-6603
if a schema change fixes a bug, yes we can On Tue, Jun 3, 2014 at 10:58 AM, Rajesh Battala rajesh.batt...@citrix.com wrote: Hi, This bug https://issues.apache.org/jira/browse/CLOUDSTACK-6603 [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4] got introduced by the feature of “Autoscaling without netscaler” A new column “last_interval” got added to autoscale_vmgroups table by this commit (dc151115be3e922933ea26ab1507eb6469a91e11). Schema of autoscale_vmgroups table got changed in wrong version of schema file cause the upgrade failed. Instead of adding schema change to the upgrade path file it was added to setup/db/db/schema-40to410.sql file. It should be added to schema43to44 upgrade path. Because of this issues, upgrade from 4.3 to 4.4 and 4.3 to 4.4 will fail. @Tuna, can you please have a look at your commit and fix it. @Daan, if this issue CLOUDSTACK-6603 is not fixed, upgrades from 4.2 to 4.4 and 4.3 to 4.4 will fail. As 4.4 feature freeze had happened long back, Am not sure whether we can change db schema now in 4.4 branch Thanks Rajesh Battala -- Daan
Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?
Hi Min, With reference to the wiki doc, I had a query. In case of a customized role with deny permissions how will the listAll, isrecursive ..etc. input parameters values will be ? For example, there are two accounts and they belong to a group with Allow all permissions. If I have to remove some permissions for only account 1 but keep them for account 2 is it possible? Thanks Meghna. On Thu, May 22, 2014 at 10:22 PM, Min Chen min.c...@citrix.com wrote: Added API issues we found through IAM feature in the wiki page created by Demetrius: https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes Thanks -min On 5/14/14 9:34 AM, Min Chen min.c...@citrix.com wrote: Thanks Daan. Yes, I saw that there is another thread about putting an API request for 5.0 api. Once we are done with this disabling, we will put the issues we have found with current API in that wiki page to take into consideration when we design the new API. -min On 5/14/14 12:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Min, I think everybody knows I am all for less features per release. I don't think you are making a bad call, per se. I do think we should consider if we can come up with a total picture of what 5.x would require af the api, though. Can you add to the discussion what it is that is keeping you from implementing. And what requirements you have for the 5.0 api so we can start devising the architectural guidelines for the new api. more and more calls for a 5.0 are coming up lately so let's move forward. (changing title) On Wed, May 14, 2014 at 1:53 AM, Min Chen min.c...@citrix.com wrote: Hi All, In the past several weeks, QA has done some testing on IAM feature and found several backward-compatibility issues. Even though Prachi and I have tried our best to fix bugs to maintain backward compatibility, we realized that in order to support true IAM model documented in our FS https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Identi t y+and+Access+Management+%28IAM%29+Plugin, we will have to make several API changes that will require us to increment CloudStack major version. Therefore we think that IAM feature is not ready for ACS 4.4 release, and we would like to propose to disable it in 4.4 branch and re-enable it later when community decides to go for 5.x. Thanks -min -- Daan
Re: Review Request 22194: Fixed Resource leak reported by coverity
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/#review44615 --- Ship it! master - 793462e5fa40dc73ce30658fe6a27e4284ed9cdb 4.4-forward - d511847cfedad5478d1b4087c8f97be2c5bf3cc8 - Koushik Das On June 3, 2014, 10:42 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22194/ --- (Updated June 3, 2014, 10:42 a.m.) Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Santhosh Edukulla. Repository: cloudstack-git Description --- Fixed Resource leak (RESOURCE_LEAK) 11. overwrite_var: Overwriting pstmt in pstmt = conn.prepareStatement(INSERT INTO `cloud`.`ldap_configuration`(hostname, port) VALUES(?,?)) leaks the resource that pstmt refers to. Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 Diff: https://reviews.apache.org/r/22194/diff/ Testing --- Thanks, Rajani Karuturi
[ACS4.4] [Issue] Unable to create a resource tag on ISO and Template resource
Hi All,
I was trying to create a resource tag on ISO and Template with a sample
data for a test
case. Can anyone help me toknow is there anything I'm missing in the input
parameters ?
For both resources, I get a db exception Out of range value for column
'domain_id' at row 1 where the domainid gets value as -1.
I'm running this test on simulator.
*1] For ISO: *
*a) ISO in json*
iso1A: {
displaytext: Dummy ISO,
name: Dummy ISO,
url: http://people.apache.org/~tsp/dummy.iso;,
zoneid: 9ecf9d8b-cf18-4322-a641-a1c0aced5857,
# Source URL where ISO is located
isextractable: True,
isfeatured: True,
ispublic: False,
ostype: 'CentOS 5.3 (64-bit)',
mode: 'HTTP_DOWNLOAD',
# Used in Extract template, value must be HTTP_DOWNLOAD
},
*b)* C*reating an iso with its tag*
self.account_1A = Account.create(
self.apiclient,
self.services[account1A],
admin=False,
domainid=self.domain_1.id
)
self.userapiclient_1A =
self.testClient.getUserApiClient(self.user_1A.username,
self.domain_1.name)
self.iso1A = Iso.create(
self.apiclient,
self.services[iso],
account=self.account_1A.name,
domainid=self.account_1A.domainid
)
self.debug(ISO created with ID: %s % self.iso1A.id)
self.debug(Creating a tag for the ISO1A)
self.resource_tag_1A = Tag.create(
self.apiclient,
resourceIds=self.iso1A.id,
resourceType='iso',
tags={'OS': 'CentOS'}
)
*2] For Template : *
*a) Template in json*
template1A: {
displaytext: Cent OS Template,
name: Cent OS Template,
ostype: 'CentOS 5.3 (64-bit)',
templatefilter: 'self',
},
*b ) Create template with tag. *
try:
self.debug(Stopping the virtual machine: %s %
self.virtual_machine_1A.name)
#Stop virtual machine
self.virtual_machine_1A.stop(self.apiclient)
except Exception as e:
self.fail(Failed to stop VM: %s % e)
timeout = self.services[timeout]
while True:
list_volume = Volume.list(
self.apiclient,
virtualmachineid=self.virtual_machine_1A.id,
type='ROOT',
listall=True
)
if isinstance(list_volume, list):
break
elif timeout == 0:
raise Exception(List volumes failed.)
time.sleep(5)
timeout = timeout - 1
self.volumeT = list_volume[0]
self.template1A = Template.create(
self.apiclient,
self.services[template1A],
self.volumeT.id
)
self.debug(Created the template1A(%s). Now restarting the
userVm: %s % (self.template1A.name, self.virtual_machine_1A.name))
self.virtual_machine_1A.start(self.apiclient)
self.debug(Creating a tag for the template1A)
self.resource_tag_1A = Tag.create(
self.apiclient,
resourceIds=self.template1A.id,
resourceType='Template',
tags={'OS': 'CentOS'}
)
Thanks and Regards,
--
*Namita Chaudhari* ● Engineer - Product Development ● SunGard Availability
Services, India. ● 2nd Floor, Wing 4, Cluster D, MIDC Kharadi Knowledge
Park, Pune - 411 014 ● Email: namita.chaudh...@sungardas.com
namita.chaudh...@sungard.com ● www.sungardas.in
[image: Description: cid:image019.png@01CF48EC.6617C7F0] [image:
Description: cid:image020.png@01CF48EC.6617C7F0] [image: Description:
cid:image021.png@01CF48EC.6617C7F0] [image: Description:
cid:image022.png@01CF48EC.6617C7F0] [image: Description:
cid:image023.png@01CF48EC.6617C7F0] [image: Description:
cid:image024.png@01CF48EC.6617C7F0]
Re: Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22197/#review44616 --- test/integration/smoke/test_non_contigiousvlan.py https://reviews.apache.org/r/22197/#comment79036 It seems we are not reading test data. Can we check that? test/integration/smoke/test_non_contigiousvlan.py https://reviews.apache.org/r/22197/#comment79037 As well, can we run these changes once and see no issues if its possible? - Santhosh Edukulla On June 3, 2014, 11:45 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22197/ --- (Updated June 3, 2014, 11:45 a.m.) Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla. Bugs: CLOUDSTACK-6776 https://issues.apache.org/jira/browse/CLOUDSTACK-6776 Repository: cloudstack-git Description --- The test case fails whenever hard coded values overlap with already configured VLAN in the physical network. Removed hard code VLAN ids and used the common function to get unused VLAN ids from the physical network dynamically. Diffs - test/integration/smoke/test_non_contigiousvlan.py 90235ec Diff: https://reviews.apache.org/r/22197/diff/ Testing --- Yes. Log: Test to update a physical network and extend its vlan ... === TestName: test_extendPhysicalNetworkVlan | Status : SUCCESS === ok -- Ran 1 test in 15.328s OK ~ ~ Thanks, Ashutosh Kelkar
RE: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template resource
Namita,
1. Just to separate this issue as simulator vs test code, can we just check
from UI whether the objective of creating tags for simulator is possible there?
If yes, then we can look in to test code.
2. As well, are these new tests or existing tests?
Thanks!
Santhosh
From: Namita Chaudhari [namita.chaudh...@sungardas.com]
Sent: Tuesday, June 03, 2014 8:27 AM
To: dev@cloudstack.apache.org
Subject: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template
resource
Hi All,
I was trying to create a resource tag on ISO and Template with a sample data
for a test
case. Can anyone help me toknow is there anything I'm missing in the input
parameters ?
For both resources, I get a db exception Out of range value for column
'domain_id' at row 1 where the domainid gets value as -1.
I'm running this test on simulator.
1] For ISO:
a) ISO in json
iso1A: {
displaytext: Dummy ISO,
name: Dummy ISO,
url: http://people.apache.org/~tsp/dummy.iso;,
zoneid: 9ecf9d8b-cf18-4322-a641-a1c0aced5857,
# Source URL where ISO is located
isextractable: True,
isfeatured: True,
ispublic: False,
ostype: 'CentOS 5.3 (64-bit)',
mode: 'HTTP_DOWNLOAD',
# Used in Extract template, value must be HTTP_DOWNLOAD
},
b) Creating an iso with its tag
self.account_1A = Account.create(
self.apiclient,
self.services[account1A],
admin=False,
domainid=self.domain_1.idhttp://self.domain_1.id/
)
self.userapiclient_1A =
self.testClient.getUserApiClient(self.user_1A.username,
self.domain_1.namehttp://self.domain_1.name/)
self.iso1A = Iso.create(
self.apiclient,
self.services[iso],
account=self.account_1A.namehttp://self.account_1A.name,
domainid=self.account_1A.domainid
)
self.debug(ISO created with ID: %s %
self.iso1A.idhttp://self.iso1A.id)
self.debug(Creating a tag for the ISO1A)
self.resource_tag_1A = Tag.create(
self.apiclient,
resourceIds=self.iso1A.idhttp://self.iso1A.id,
resourceType='iso',
tags={'OS': 'CentOS'}
)
2] For Template :
a) Template in json
template1A: {
displaytext: Cent OS Template,
name: Cent OS Template,
ostype: 'CentOS 5.3 (64-bit)',
templatefilter: 'self',
},
b ) Create template with tag.
try:
self.debug(Stopping the virtual machine: %s %
self.virtual_machine_1A.namehttp://self.virtual_machine_1A.name)
#Stop virtual machine
self.virtual_machine_1A.stop(self.apiclient)
except Exception as e:
self.fail(Failed to stop VM: %s % e)
timeout = self.services[timeout]
while True:
list_volume = Volume.list(
self.apiclient,
virtualmachineid=self.virtual_machine_1A.idhttp://self.virtual_machine_1A.id,
type='ROOT',
listall=True
)
if isinstance(list_volume, list):
break
elif timeout == 0:
raise Exception(List volumes failed.)
time.sleep(5)
timeout = timeout - 1
self.volumeT = list_volume[0]
self.template1A = Template.create(
self.apiclient,
self.services[template1A],
self.volumeT.idhttp://self.volumeT.id
)
self.debug(Created the template1A(%s). Now restarting the userVm: %s
% (self.template1A.namehttp://self.template1A.name,
self.virtual_machine_1A.namehttp://self.virtual_machine_1A.name))
self.virtual_machine_1A.start(self.apiclient)
self.debug(Creating a tag for the template1A)
self.resource_tag_1A = Tag.create(
self.apiclient,
resourceIds=self.template1A.idhttp://self.template1A.id,
resourceType='Template',
tags={'OS': 'CentOS'}
)
Thanks and Regards,
--
Namita Chaudhari ● Engineer - Product Development ● SunGard Availability
Services, India. ● 2nd Floor, Wing 4, Cluster D, MIDC Kharadi Knowledge Park,
Pune - 411 014 ● Email:
namita.chaudh...@sungardas.commailto:namita.chaudh...@sungard.com ●
Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template resource
Hi Santhosh,
These are new test cases. On simulator and in same test case, I have
created tags on various resources like volume, project, snapshot etc and
they work perfectly fine.
I face this issue only for ISO and Template resource tag creation.
Thanks,
Namita
On Tue, Jun 3, 2014 at 6:16 PM, Santhosh Edukulla
santhosh.eduku...@citrix.com wrote:
Namita,
1. Just to separate this issue as simulator vs test code, can we just
check from UI whether the objective of creating tags for simulator is
possible there? If yes, then we can look in to test code.
2. As well, are these new tests or existing tests?
Thanks!
Santhosh
From: Namita Chaudhari [namita.chaudh...@sungardas.com]
Sent: Tuesday, June 03, 2014 8:27 AM
To: dev@cloudstack.apache.org
Subject: [ACS4.4] [Issue] Unable to create a resource tag on ISO and
Template resource
Hi All,
I was trying to create a resource tag on ISO and Template with a sample
data for a test
case. Can anyone help me toknow is there anything I'm missing in the input
parameters ?
For both resources, I get a db exception Out of range value for column
'domain_id' at row 1 where the domainid gets value as -1.
I'm running this test on simulator.
1] For ISO:
a) ISO in json
iso1A: {
displaytext: Dummy ISO,
name: Dummy ISO,
url: http://people.apache.org/~tsp/dummy.iso;,
zoneid: 9ecf9d8b-cf18-4322-a641-a1c0aced5857,
# Source URL where ISO is located
isextractable: True,
isfeatured: True,
ispublic: False,
ostype: 'CentOS 5.3 (64-bit)',
mode: 'HTTP_DOWNLOAD',
# Used in Extract template, value must be HTTP_DOWNLOAD
},
b) Creating an iso with its tag
self.account_1A = Account.create(
self.apiclient,
self.services[account1A],
admin=False,
domainid=self.domain_1.id
http://self.domain_1.id/
)
self.userapiclient_1A =
self.testClient.getUserApiClient(self.user_1A.username,
self.domain_1.namehttp://self.domain_1.name/)
self.iso1A = Iso.create(
self.apiclient,
self.services[iso],
account=self.account_1A.name
http://self.account_1A.name,
domainid=self.account_1A.domainid
)
self.debug(ISO created with ID: %s % self.iso1A.id
http://self.iso1A.id)
self.debug(Creating a tag for the ISO1A)
self.resource_tag_1A = Tag.create(
self.apiclient,
resourceIds=self.iso1A.idhttp://self.iso1A.id,
resourceType='iso',
tags={'OS': 'CentOS'}
)
2] For Template :
a) Template in json
template1A: {
displaytext: Cent OS Template,
name: Cent OS Template,
ostype: 'CentOS 5.3 (64-bit)',
templatefilter: 'self',
},
b ) Create template with tag.
try:
self.debug(Stopping the virtual machine: %s %
self.virtual_machine_1A.namehttp://self.virtual_machine_1A.name)
#Stop virtual machine
self.virtual_machine_1A.stop(self.apiclient)
except Exception as e:
self.fail(Failed to stop VM: %s % e)
timeout = self.services[timeout]
while True:
list_volume = Volume.list(
self.apiclient,
virtualmachineid=
self.virtual_machine_1A.idhttp://self.virtual_machine_1A.id,
type='ROOT',
listall=True
)
if isinstance(list_volume, list):
break
elif timeout == 0:
raise Exception(List volumes failed.)
time.sleep(5)
timeout = timeout - 1
self.volumeT = list_volume[0]
self.template1A = Template.create(
self.apiclient,
self.services[template1A],
self.volumeT.idhttp://self.volumeT.id
)
self.debug(Created the template1A(%s). Now restarting the userVm:
%s % (self.template1A.namehttp://self.template1A.name,
self.virtual_machine_1A.namehttp://self.virtual_machine_1A.name))
self.virtual_machine_1A.start(self.apiclient)
self.debug(Creating a tag for the template1A)
self.resource_tag_1A = Tag.create(
self.apiclient,
RE: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template resource
Two things:
1. Is this feature of tagging iso or template available\supported in CS? What
API we are using for it?
2. If this is supported feature, can you manually do it from UI on simulator
and check if its working there?
Thanks!
Santhosh
From: Namita Chaudhari [namita.chaudh...@sungardas.com]
Sent: Tuesday, June 03, 2014 8:51 AM
To: dev@cloudstack.apache.org
Subject: Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and
Template resource
Hi Santhosh,
These are new test cases. On simulator and in same test case, I have created
tags on various resources like volume, project, snapshot etc and they work
perfectly fine.
I face this issue only for ISO and Template resource tag creation.
Thanks,
Namita
On Tue, Jun 3, 2014 at 6:16 PM, Santhosh Edukulla
santhosh.eduku...@citrix.commailto:santhosh.eduku...@citrix.com wrote:
Namita,
1. Just to separate this issue as simulator vs test code, can we just check
from UI whether the objective of creating tags for simulator is possible there?
If yes, then we can look in to test code.
2. As well, are these new tests or existing tests?
Thanks!
Santhosh
From: Namita Chaudhari
[namita.chaudh...@sungardas.commailto:namita.chaudh...@sungardas.com]
Sent: Tuesday, June 03, 2014 8:27 AM
To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org
Subject: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template
resource
Hi All,
I was trying to create a resource tag on ISO and Template with a sample data
for a test
case. Can anyone help me toknow is there anything I'm missing in the input
parameters ?
For both resources, I get a db exception Out of range value for column
'domain_id' at row 1 where the domainid gets value as -1.
I'm running this test on simulator.
1] For ISO:
a) ISO in json
iso1A: {
displaytext: Dummy ISO,
name: Dummy ISO,
url: http://people.apache.org/~tsp/dummy.iso;,
zoneid: 9ecf9d8b-cf18-4322-a641-a1c0aced5857,
# Source URL where ISO is located
isextractable: True,
isfeatured: True,
ispublic: False,
ostype: 'CentOS 5.3 (64-bit)',
mode: 'HTTP_DOWNLOAD',
# Used in Extract template, value must be HTTP_DOWNLOAD
},
b) Creating an iso with its tag
self.account_1A = Account.create(
self.apiclient,
self.services[account1A],
admin=False,
domainid=self.domain_1.idhttp://self.domain_1.idhttp://self.domain_1.id/
)
self.userapiclient_1A =
self.testClient.getUserApiClient(self.user_1A.username,
self.domain_1.namehttp://self.domain_1.namehttp://self.domain_1.name/)
self.iso1A = Iso.create(
self.apiclient,
self.services[iso],
account=self.account_1A.namehttp://self.account_1A.namehttp://self.account_1A.name,
domainid=self.account_1A.domainid
)
self.debug(ISO created with ID: %s %
self.iso1A.idhttp://self.iso1A.idhttp://self.iso1A.id)
self.debug(Creating a tag for the ISO1A)
self.resource_tag_1A = Tag.create(
self.apiclient,
resourceIds=self.iso1A.idhttp://self.iso1A.idhttp://self.iso1A.id,
resourceType='iso',
tags={'OS': 'CentOS'}
)
2] For Template :
a) Template in json
template1A: {
displaytext: Cent OS Template,
name: Cent OS Template,
ostype: 'CentOS 5.3 (64-bit)',
templatefilter: 'self',
},
b ) Create template with tag.
try:
self.debug(Stopping the virtual machine: %s %
self.virtual_machine_1A.namehttp://self.virtual_machine_1A.namehttp://self.virtual_machine_1A.name)
#Stop virtual machine
self.virtual_machine_1A.stop(self.apiclient)
except Exception as e:
self.fail(Failed to stop VM: %s % e)
timeout = self.services[timeout]
while True:
list_volume = Volume.list(
self.apiclient,
virtualmachineid=self.virtual_machine_1A.idhttp://self.virtual_machine_1A.idhttp://self.virtual_machine_1A.id,
type='ROOT',
listall=True
)
if isinstance(list_volume, list):
break
elif timeout == 0:
raise Exception(List volumes failed.)
time.sleep(5)
timeout = timeout - 1
self.volumeT =
Spectacular networking fail with KVM Adv zone - can someone address this bug?
Hello, Any dev experienced with the KVM networking available to have a look at this bug? https://issues.apache.org/jira/browse/CLOUDSTACK-6464 Seems like it's widespread and with no resolution in sight. I have not experienced it in my 4.3 deployments, wonder if it'll come back to bite me after production has started properly. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
RE: Regarding Blocker bug CLOUDSTACK-6603
Tuna, Can you please move your schema changes appropriately? Thanks Rajesh Battala -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, June 3, 2014 5:26 PM To: Rajesh Battala Cc: dev@cloudstack.apache.org; ng.t...@gmail.com Subject: Re: Regarding Blocker bug CLOUDSTACK-6603 if a schema change fixes a bug, yes we can On Tue, Jun 3, 2014 at 10:58 AM, Rajesh Battala rajesh.batt...@citrix.com wrote: Hi, This bug https://issues.apache.org/jira/browse/CLOUDSTACK-6603 [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4] got introduced by the feature of “Autoscaling without netscaler” A new column “last_interval” got added to autoscale_vmgroups table by this commit (dc151115be3e922933ea26ab1507eb6469a91e11). Schema of autoscale_vmgroups table got changed in wrong version of schema file cause the upgrade failed. Instead of adding schema change to the upgrade path file it was added to setup/db/db/schema-40to410.sql file. It should be added to schema43to44 upgrade path. Because of this issues, upgrade from 4.3 to 4.4 and 4.3 to 4.4 will fail. @Tuna, can you please have a look at your commit and fix it. @Daan, if this issue CLOUDSTACK-6603 is not fixed, upgrades from 4.2 to 4.4 and 4.3 to 4.4 will fail. As 4.4 feature freeze had happened long back, Am not sure whether we can change db schema now in 4.4 branch Thanks Rajesh Battala -- Daan
Re: Spectacular networking fail with KVM Adv zone - can someone address this bug?
I think a fresh 4.3 install with vlan isolation is pretty well tested, but there have been issues with upgrades, and apparently basic/no isolation networks. I'm taking a shot in the dark to try to help, and I'll see if I can reproduce, but the symptoms seem rather complex and varied. If I can reproduce it, I can fix it. On Tue, Jun 3, 2014 at 8:44 AM, Nux! n...@li.nux.ro wrote: Hello, Any dev experienced with the KVM networking available to have a look at this bug? https://issues.apache.org/jira/browse/CLOUDSTACK-6464 Seems like it's widespread and with no resolution in sight. I have not experienced it in my 4.3 deployments, wonder if it'll come back to bite me after production has started properly. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Cpu, cpu speed and memory in usage records
Hi, Is it normal if CloudStack does not return usage details (cpu cores, cpu speed and memory) in the usage records? Since the introduction of dynamic compute offerings, these details are recorded in table cloud_usage.usage_vm_instance, but they are not in table cloud_usage.cloud_usage, and they aren't returned by the listUsageRecords API command. So, what was the purpose of these details in cloud_usage (CLOUDSTACK-4737, CLOUDSTACK-5515, CLOUDSTACK-6466)? It seems they're saved in database but never read. Am I wrong? Thanks, -- Olivier Lemasle Software Engineer *Apalia*™ Mobile: +33-611-69-12-11 *http://www.apalia.net http://www.apalia.net olivier.lema...@apalia.netolivier.lema...@apalia.net olivier.lema...@apalia.net*
UI Development
I am trying to get a grasp on how the UI is generated for CloudStack. Are there any good documented resources for the UI? For example, say I wanted to add another column to the table of storage devices, is there any documentation that would help me figure this out?
RE: [Proposal] Integrating Apache Stratos with Apache CloudStack.
Hi Chris Tuna, Are any of your designs available to read? I'm interested in Stratos and how it could be integrated with CloudStack. I'd be interested to see what you are working to achieve. Alex Hitchins | 07788 423 969 | 01892 523 587 -Original Message- From: chris snow [mailto:chsnow...@gmail.com] Sent: 08 April 2014 20:57 To: dev@cloudstack.apache.org Subject: Re: [Proposal] Integrating Apache Stratos with Apache CloudStack. Hi Tuna, In terms of design for cloudstack integration, Nirmal has provided some useful information here [1]. However, my integration efforts have stalled a little while I am trying to resolve an issue creating a Ubuntu instance in a Xen host inside virtualbox. Jason Daly has also been working on the Cloudstack integration using his company's Cloudstack infrastructure. My expectation is that Jason will get integration finished before I manage to, in which case I will be continue my focus on providing Stratos+Cloudstack vagrant environments. The first goal for me is for a user to be able to try Cloudstack and Stratos using Vagrant with minimal manual setup. The second goal is for a developer to use vagrant to setup a Stratos development environment - again with minimal effort. Cheers, Chris --- [1] http://mail-archives.apache.org/mod_mbox/incubator-stratos-dev/201404.mbox/b rowser On Tue, Apr 8, 2014 at 8:41 PM, Nguyen Anh Tu t...@apache.org wrote: Dear guys, It's not really a full proposal right now, I just wanna bump a thread to discuss about working on integrating Stratos to CloudStack. Chris Snow and I are working on the design process. Keep update soon! Chris, could you keep update on this thread? Thanks, --Tuna -- Check out my professional profile and connect with me on LinkedIn. http://lnkd.in/cw5k69
Re: Spectacular networking fail with KVM Adv zone - can someone address this bug?
On 03.06.2014 16:20, Marcus wrote: I think a fresh 4.3 install with vlan isolation is pretty well tested, but there have been issues with upgrades, and apparently basic/no isolation networks. I'm taking a shot in the dark to try to help, and I'll see if I can reproduce, but the symptoms seem rather complex and varied. If I can reproduce it, I can fix it. Thanks Marcus! I have 2 deployments, both fresh 4.3, one Adv and one Adv+SG, neither exhibit this problem, so indeed it does look like an upgrade issue. It looks like someone attempted a fix, but without too much success https://reviews.apache.org/r/21908/ .. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?
As mentioned in our FS doc in wiki, In phase I, all the permissions attached to any policy are by default explicit 'Allow' permissions. As of now 'Deny' permissions cannot be added. For your use cases, you can have two options: 1. Assign the two accounts into 2 different groups, and attach different policy for the group. 2. Directly attach an Allow policy to account 2 instead of assigning both accounts into the Allow All group. Thanks -min On 6/3/14 5:03 AM, Meghna Kale meghna.k...@sungardas.com wrote: Hi Min, With reference to the wiki doc, I had a query. In case of a customized role with deny permissions how will the listAll, isrecursive ..etc. input parameters values will be ? For example, there are two accounts and they belong to a group with Allow all permissions. If I have to remove some permissions for only account 1 but keep them for account 2 is it possible? Thanks Meghna. On Thu, May 22, 2014 at 10:22 PM, Min Chen min.c...@citrix.com wrote: Added API issues we found through IAM feature in the wiki page created by Demetrius: https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes Thanks -min On 5/14/14 9:34 AM, Min Chen min.c...@citrix.com wrote: Thanks Daan. Yes, I saw that there is another thread about putting an API request for 5.0 api. Once we are done with this disabling, we will put the issues we have found with current API in that wiki page to take into consideration when we design the new API. -min On 5/14/14 12:12 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Min, I think everybody knows I am all for less features per release. I don't think you are making a bad call, per se. I do think we should consider if we can come up with a total picture of what 5.x would require af the api, though. Can you add to the discussion what it is that is keeping you from implementing. And what requirements you have for the 5.0 api so we can start devising the architectural guidelines for the new api. more and more calls for a 5.0 are coming up lately so let's move forward. (changing title) On Wed, May 14, 2014 at 1:53 AM, Min Chen min.c...@citrix.com wrote: Hi All, In the past several weeks, QA has done some testing on IAM feature and found several backward-compatibility issues. Even though Prachi and I have tried our best to fix bugs to maintain backward compatibility, we realized that in order to support true IAM model documented in our FS https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Identi t y+and+Access+Management+%28IAM%29+Plugin, we will have to make several API changes that will require us to increment CloudStack major version. Therefore we think that IAM feature is not ready for ACS 4.4 release, and we would like to propose to disable it in 4.4 branch and re-enable it later when community decides to go for 5.x. Thanks -min -- Daan
Re: [ANNOUNCE] Amogh Vasekar as committer
Thanks a ton everyone! :-) Regards, Amogh On 6/3/14 4:06 AM, Nux! n...@li.nux.ro wrote: On 02.06.2014 19:14, John Kinsella wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Amogh Vasekar to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Amogh! -John, on behalf of the CloudStack PMC Congratulations, Amogh! :) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: Review Request 21908: Fix for CLOUDSTACK-6464
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21908/#review44634 --- Actually, this would be fixed by changing the upgraded db to have vlan:// in the vlan_id table, as fresh installs do. This bug exists because the IpAssocCommand crafted by the management server sends the ips broadcastUri in a different format from the network/nic setups. We're actually discussing how to fix that right now, and whether it makes sense to update the db during upgrade to match what 4.3+ does currently, or change 4.3+ back. - Marcus Sorensen On May 26, 2014, 12:25 p.m., Anders Lannerbäck wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21908/ --- (Updated May 26, 2014, 12:25 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- Fix for CLOUDSTACK-6464. This patch is against 4.3-branch. The original code adds broadcastUri on the format vlan://100, but later looks for HashMap keys without the vlan:// bit. This causes new interfaces be created with duplicate MACs and the routers become unusable. Diffs - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 36382e3 Diff: https://reviews.apache.org/r/21908/diff/ Testing --- Used to repair our production Cloudstack instance. Thanks, Anders Lannerbäck
Re: Spectacular networking fail with KVM Adv zone - can someone address this bug?
Good catch. This patch works around the main problem that the mgmt server is passing broadcastUri in one way (e.g. vlan://100 in his example) for one Command and broadcastUri in another way (just '100') for a different Command. It doesn't affect fresh 4.3 installs because the way new values are stored in the DB make the code always pass 'vlan://100'. Daan and I are still discussing how to fix these. On Tue, Jun 3, 2014 at 10:21 AM, Nux! n...@li.nux.ro wrote: On 03.06.2014 16:20, Marcus wrote: I think a fresh 4.3 install with vlan isolation is pretty well tested, but there have been issues with upgrades, and apparently basic/no isolation networks. I'm taking a shot in the dark to try to help, and I'll see if I can reproduce, but the symptoms seem rather complex and varied. If I can reproduce it, I can fix it. Thanks Marcus! I have 2 deployments, both fresh 4.3, one Adv and one Adv+SG, neither exhibit this problem, so indeed it does look like an upgrade issue. It looks like someone attempted a fix, but without too much success https://reviews.apache.org/r/21908/ .. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: Review Request 21908: Fix for CLOUDSTACK-6464
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21908/#review44635 --- I would vote to reject this patch, by the way, on the terms that it just works around the inconsistency in the data being passed. I'm glad that you were able to find and use it as an interim solution, though. - Marcus Sorensen On May 26, 2014, 12:25 p.m., Anders Lannerbäck wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21908/ --- (Updated May 26, 2014, 12:25 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- Fix for CLOUDSTACK-6464. This patch is against 4.3-branch. The original code adds broadcastUri on the format vlan://100, but later looks for HashMap keys without the vlan:// bit. This causes new interfaces be created with duplicate MACs and the routers become unusable. Diffs - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 36382e3 Diff: https://reviews.apache.org/r/21908/diff/ Testing --- Used to repair our production Cloudstack instance. Thanks, Anders Lannerbäck
Re: VPC's VR missing public NIC eth1
Ok, thanks. It seems there are other cases where the Command being passed from the mgmt server has inconsistent broadcastUri as well, this should blanket fix them. In the meantime there's a growing group of 4.3 upgraders who are getting pitchforks out over at CLOUDSTACK-6464, so we may want to have something in 4.3.1 too. On Tue, Jun 3, 2014 at 12:30 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: one clarification, I was not suggesting changing vlan://x back to x, just the case where x==untagged. I had a little analog discussion with Hugo and he convinced me that untagged has no special meaning in SDN cases, maybe for vxlan. So the problem I saw is at least smaller then in my mind. I have committed the db change to update 4.3.0 to 4.4.0. It will need heavy testing. And I didn't extensively look into other tables that need such a change. networks is the likely candidate but there may be others. On Mon, Jun 2, 2014 at 6:38 PM, Marcus shadow...@gmail.com wrote: Just to recap... I was trying to review the issue in my head and thought it might be useful to write it down. in 4.3 we got the BroadcastDomainType enum introduced, and many parts of the code were changed to use that when dealing with the vlan id. This code, among other things, returns a vlan id in URI format, describing both the technology used to provide the virtual lan, along with the id. Along the way this seems to have caused the value itself to be stored as a URI (still not sure where, by whom, or if it was intentional). That was fine and seemed to work after some fixing, until there was an upgrade done where the existing database value was NOT in URI format. We had a few places where the code was never changed to use BroadcastDomainType to 'normalize' the info from the database (e.g. the IpAssocVpcCommand the mgmt server constructs), so upgrades are broken. Most places in the code as it is now are working with a live value of 'vlan://x', regardless of whether the database has 'vlan://x' or just 'x', thanks to this code it returns the same 'vlan://' for either stored value. For these places it shouldn't matter if we fix the old databases to store 'vlan://x' or the 4.3 installs to go back to 'x'. However, there are a few places that are broken, like this IpAssocVpcCommand the mgmt server creates and CLOUDSTACK-5505. If we switch the db value back, we have to identify all of the outstanding ones and fix them. In addition, new code since then may have perhaps assumed that the db value is 'vlan://', and might have bothered to pass through the interpolation, so they may break as well. If we had full coverage on the test suite it would be easy to change the value back in the DB of a 4.3 or 4.4 install and see what breaks. If we don't switch the value back, and instead update old databases to the current way, it fixes the immediate issue but we end up with code doing the same thing in two different ways. Some places will be using the raw db value and other places will be asking for it to be normalized, and both will have the same result, which is kind of messy and prone to causing issues down the road if something changes again to separate these two. On Mon, Jun 2, 2014 at 10:01 AM, Marcus shadow...@gmail.com wrote: I'm not sure the KVM code needs to be changed, you're asking it to deal with an inconsistency from the mgmt server. Don't you find it odd that one Command from the mgmt server provides broadcastUri=vlan://untagged and another provides broadcastUri=untagged? I'm not sure I understand why changing 'untagged' into a URI format changes its meaning, but it seems like that doesn't make any sense to you, so perhaps we can break that out into a separate column so that we can still capture the info, if needed. If we don't like URI format for the vlan id, that's fine, but we need to do changes to the 4.3 installs and fix 4.4. As mentioned, I remember there being a decent amount of work to handle the vlan:// when it was introduced, and that will need to be done again to change it back. I'm not against that, but I'm not going to be the one doing that work, either :-) On Mon, Jun 2, 2014 at 3:47 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: I don't think this should be solved this way afterall. 'untagged' actually means no vlan, so it should not be prepended with 'vlan://'. I think the kvm code should be fixed for this not the generic code. On Fri, May 30, 2014 at 10:59 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: On Fri, May 30, 2014 at 10:51 PM, Marcus shadow...@gmail.com wrote: Looks good to me, aside from he debug statement. Ah, the first line was not in my line of sight. -- Daan -- Daan -- Daan
RE: UI Development
Hi Matt, There are ui controls in /ui/scripts/ui/widgets that generate the actual controls/page based on JSON definitions at /ui/scripts. AFAIK there is no complete UI documentation, but you can take a look here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+widget+samples To add a column to the UI you need to extend a JSON object where the columns in question are defined. If you search in the *.js files in /ui/scripts directory for listView and then you go any listView's fields: definition you will find examples. You can add the field/column there. If the dataProvider of the listView is already getting this column as part of the current API response (eg. debug it with FireBug or see the API), you are done. If not then the dataProvider needs to be changed as well. What is the new column that you plan to add? I would recommend discussing this on the list first. Gabor -Original Message- From: Matt Spurlin [mailto:matt.spur...@appcore.com] Sent: 03 June 2014 17:13 To: dev@cloudstack.apache.org Subject: UI Development I am trying to get a grasp on how the UI is generated for CloudStack. Are there any good documented resources for the UI? For example, say I wanted to add another column to the table of storage devices, is there any documentation that would help me figure this out?
[DISCUSS] NetConf client Library for Brocade Network Plugin implemenatation...
Hi, The Brocade Network plugin uses NetConf Java client library, NetConf4j https://github.com/dana-i2cat/netconf4j for its implementation. It is available under LGPL license. Is it ok to use this library with CloudStack or are there any other recommendations that have been used earlier for other plugins? Thanks Regards, Ritu S.
Re: [Proposal] Integrating Apache Stratos with Apache CloudStack.
On Tue, Jun 3, 2014 at 11:15 PM, Alex Hitchins a...@alexhitchins.com wrote: Are any of your designs available to read? I'm interested in Stratos and how it could be integrated with CloudStack. I'd be interested to see what you are working to achieve. Alex, Unfortunately I'm not follow it anymore. Jason (from Citrix) is working on. He's also a committer if I remember exactly... --Tuna
Re: [ACS44] Cherry pick CLOUDSTACK-6599
Thanks Daan. Regarding test cases, I will check and get back. Just that we don¹t loose this it in mails I have created a bug for 4.4, for adding test cases if they don¹t already exist. -Nitin On 03/06/14 1:08 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: strong point, I added both commits. Are there tests to the old code as well? this is a lot of untested code like this. On Mon, Jun 2, 2014 at 7:50 PM, Nitin Mehta nitin.me...@citrix.com wrote: Daan - Thanks for your comment. The java upgrade code has never been data migration code only. I have always seen complex DDL logic being handled by java upgrade code because we can write complex logic and catch exceptions gracefully. As you see from the links below - add column if it doesn't exist logic is not trivial and hence its been added in java upgrade path. I have infact borrowed the logic from upgrade410-420 java code. Therefore, you can't figure out the schema through the schema sql files. Thanks, -Nitin On 31/05/14 2:19 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: now your are changing schema in java code! please don't do that. Those are for data migration. If we start 5.0 we want to be able read the sql to find the actual schema. http://stackoverflow.com/questions/972922/add-column-to-mysql-table-if-i t- does-not-exist http://stackoverflow.com/questions/14381895/mysql-add-column-if-not-exis t On Sat, May 31, 2014 at 2:05 AM, Nitin Mehta nitin.me...@citrix.com wrote: Please cherry-pick be765ce8680564b743a73dd360c590c0e495c204 as well as part of this bug. One more thing to add, majority of code is for the functionality which I found missing in 4.4 and found some bugs which I termed as improvements over previous design. Thanks, -Nitin On 30/05/14 3:06 PM, Nitin Mehta nitin.me...@citrix.com wrote: Daan - Here improvements are actually bug fixes that should be fixed. Thanks, -Nitin On 30/05/14 1:47 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: That's a lot of improvements without tests, Nitin. On Fri, May 30, 2014 at 8:14 PM, Nitin Mehta nitin.me...@citrix.com wrote: Hello Daan, Can you please cherry-pick the following commit from 4.4-forward to 4.4 ? commit 48ea9e0b5e87fee067b711890cd5a5d7c9079bf1 CLOUDSTACK-6599: 1. Adding the missing Template/Volume URLs expiration functionality 2. Improvement - While deleting the volume during expiration use rm -rf as vmware now contains directoy 3. Improvement - Use standard Answer so that the error gets logged in case deletion of expiration link didnt work fine. 4. Improvement - In case of domain change, expire the old urls Thanks, -Nitin -- Daan -- Daan -- Daan
[ACS44] Cherry pick 73330167228d14ea8494c9c1893627b6936626a7
Hi Daan, Can you please cherry-pick the following commit ? commit 73330167228d14ea8494c9c1893627b6936626a7 CLOUDSTACK-6824: In case there is a failure to delete the soft link of a download url, dont bail out since there can be cases such as destroy ssvm where the soft links do not exist any more. Thanks, -Nitin
RE: VPC's VR missing public NIC eth1
I checked in a commit: 5e80e5d33d9a295b91cdba9377f52d9d963d802a, which will fix some of the mess of vlan id. -Original Message- From: Marcus [mailto:shadow...@gmail.com] Sent: Tuesday, June 03, 2014 9:57 AM To: Daan Hoogland Cc: dev Subject: Re: VPC's VR missing public NIC eth1 Ok, thanks. It seems there are other cases where the Command being passed from the mgmt server has inconsistent broadcastUri as well, this should blanket fix them. In the meantime there's a growing group of 4.3 upgraders who are getting pitchforks out over at CLOUDSTACK-6464, so we may want to have something in 4.3.1 too. On Tue, Jun 3, 2014 at 12:30 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: one clarification, I was not suggesting changing vlan://x back to x, just the case where x==untagged. I had a little analog discussion with Hugo and he convinced me that untagged has no special meaning in SDN cases, maybe for vxlan. So the problem I saw is at least smaller then in my mind. I have committed the db change to update 4.3.0 to 4.4.0. It will need heavy testing. And I didn't extensively look into other tables that need such a change. networks is the likely candidate but there may be others. On Mon, Jun 2, 2014 at 6:38 PM, Marcus shadow...@gmail.com wrote: Just to recap... I was trying to review the issue in my head and thought it might be useful to write it down. in 4.3 we got the BroadcastDomainType enum introduced, and many parts of the code were changed to use that when dealing with the vlan id. This code, among other things, returns a vlan id in URI format, describing both the technology used to provide the virtual lan, along with the id. Along the way this seems to have caused the value itself to be stored as a URI (still not sure where, by whom, or if it was intentional). That was fine and seemed to work after some fixing, until there was an upgrade done where the existing database value was NOT in URI format. We had a few places where the code was never changed to use BroadcastDomainType to 'normalize' the info from the database (e.g. the IpAssocVpcCommand the mgmt server constructs), so upgrades are broken. Most places in the code as it is now are working with a live value of 'vlan://x', regardless of whether the database has 'vlan://x' or just 'x', thanks to this code it returns the same 'vlan://' for either stored value. For these places it shouldn't matter if we fix the old databases to store 'vlan://x' or the 4.3 installs to go back to 'x'. However, there are a few places that are broken, like this IpAssocVpcCommand the mgmt server creates and CLOUDSTACK-5505. If we switch the db value back, we have to identify all of the outstanding ones and fix them. In addition, new code since then may have perhaps assumed that the db value is 'vlan://', and might have bothered to pass through the interpolation, so they may break as well. If we had full coverage on the test suite it would be easy to change the value back in the DB of a 4.3 or 4.4 install and see what breaks. If we don't switch the value back, and instead update old databases to the current way, it fixes the immediate issue but we end up with code doing the same thing in two different ways. Some places will be using the raw db value and other places will be asking for it to be normalized, and both will have the same result, which is kind of messy and prone to causing issues down the road if something changes again to separate these two. On Mon, Jun 2, 2014 at 10:01 AM, Marcus shadow...@gmail.com wrote: I'm not sure the KVM code needs to be changed, you're asking it to deal with an inconsistency from the mgmt server. Don't you find it odd that one Command from the mgmt server provides broadcastUri=vlan://untagged and another provides broadcastUri=untagged? I'm not sure I understand why changing 'untagged' into a URI format changes its meaning, but it seems like that doesn't make any sense to you, so perhaps we can break that out into a separate column so that we can still capture the info, if needed. If we don't like URI format for the vlan id, that's fine, but we need to do changes to the 4.3 installs and fix 4.4. As mentioned, I remember there being a decent amount of work to handle the vlan:// when it was introduced, and that will need to be done again to change it back. I'm not against that, but I'm not going to be the one doing that work, either :-) On Mon, Jun 2, 2014 at 3:47 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: I don't think this should be solved this way afterall. 'untagged' actually means no vlan, so it should not be prepended with 'vlan://'. I think the kvm code should be fixed for this
[ACS44] cherry pick 5e80e5d33d9a295b91cdba9377f52d9d963d802a
If Vpc public network with snat enabled, mgt server will send down vlan-id instead of vlan://vlan-id in ipassoccommand, which will cause issue on the hypervisor resource to program VR.
Marvin Question
Hi,
I've been playing around with Marvin lately.
I got it to build a CS cloud with one zone, one pod, one cluster, and two
hosts in it just fine.
I've been trying to run another script to create a Compute Offering, but
get the following error (below).
Perhaps I'm missing some piece of Marvin configuration?
Thanks!
Exception Occurred Under __initLogging :'list' object has no attribute
'LogFolderPath'
Traceback (most recent call last):
File /usr/local/bin/nosetests, line 8, in module
load_entry_point('nose==1.3.3', 'console_scripts', 'nosetests')()
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py, line
121, in __init__
**extra_args)
File
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/main.py,
line 95, in __init__
self.runTests()
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py, line
207, in runTests
result = self.testRunner.run(self.test)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py, line
62, in run
test(result)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py,
line 176, in __call__
return self.run(*arg, **kw)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py,
line 223, in run
test(orig)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py,
line 176, in __call__
return self.run(*arg, **kw)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py,
line 223, in run
test(orig)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/case.py, line
45, in __call__
return self.run(*arg, **kwarg)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/case.py, line
138, in run
result.addError(self, err)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/proxy.py,
line 124, in addError
plugin_handled = plugins.handleError(self.test, err)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/plugins/manager.py,
line 99, in __call__
return self.call(*arg, **kw)
File
/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/plugins/manager.py,
line 167, in simple
result = meth(*arg, **kw)
File
/Library/Python/2.7/site-packages/Marvin-0.1.0-py2.7.egg/marvin/marvinPlugin.py,
line 155, in handleError
self.tcRunLogger.fatal(%s: %s: %s %
AttributeError: 'NoneType' object has no attribute 'fatal'
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
http://solidfire.com/solution/overview/?video=play*™*
Re: Spectacular networking fail with KVM Adv zone - can someone address this bug?
H Marcus, saw your comment on the patch. I refused it as well and commented 'use BroadcastDomainType to do this' . I think Nux can use the dB update as well. On 3 Jun 2014 18:46, Marcus shadow...@gmail.com wrote: Good catch. This patch works around the main problem that the mgmt server is passing broadcastUri in one way (e.g. vlan://100 in his example) for one Command and broadcastUri in another way (just '100') for a different Command. It doesn't affect fresh 4.3 installs because the way new values are stored in the DB make the code always pass 'vlan://100'. Daan and I are still discussing how to fix these. On Tue, Jun 3, 2014 at 10:21 AM, Nux! n...@li.nux.ro wrote: On 03.06.2014 16:20, Marcus wrote: I think a fresh 4.3 install with vlan isolation is pretty well tested, but there have been issues with upgrades, and apparently basic/no isolation networks. I'm taking a shot in the dark to try to help, and I'll see if I can reproduce, but the symptoms seem rather complex and varied. If I can reproduce it, I can fix it. Thanks Marcus! I have 2 deployments, both fresh 4.3, one Adv and one Adv+SG, neither exhibit this problem, so indeed it does look like an upgrade issue. It looks like someone attempted a fix, but without too much success https://reviews.apache.org/r/21908/ .. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
[GSOC2014] Progress Update - week two
Hi Guys, Just a quick update on progress for last week. *[ec2stack]* Since the last progress email I've completed support of tag actions. There is now support for listing / creating / deleting Cloudstack tags through ec2stack. I wrote the required tests and updated the documentation accordingly. I was working in a branch called 'tag_support', this has been merged into master since my last email. ec2stack github repo - https://github.com/BroganD1993/ec2stack *[gstack]* Since my last update I've completed work on basic GCE GA support for gstack. Anything that was supported in the original release of gstack, using the GCE v15beta API should now work with the GCE GA API. The documentation on GitHub was updated with new setup instructions for users. After completing the GCE GA support work I made a new release on pypi which is available for download here: https://pypi.python.org/pypi/gstack/0.1.0 https://pypi.python.org/pypi/gstack/0.1.0 I began writing tests for the project, which is progressing nicely. I have most of the major functionality tested, there's still a bit of work left to do. The test support branch was merged into master earlier today. gstack project repo - https://github.com/NOPping/gstack My next step is to finish the unittesting for gstack and then move on to refactoring, restructuring cleaning of the code base. Thanks, Darren
Re: Review Request 21908: Fix for CLOUDSTACK-6464
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21908/#review44664 --- Commit 15385948dcdf4c69136e99bf3c602f95fd018f39 in cloudstack's branch refs/heads/4.3-forward from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1538594 ] CLOUDSTACK-6464: if guest network type is vlan://untagged, and traffic label is used, kvm agent needs to honor traffic label - ASF Subversion and Git Services On May 26, 2014, 12:25 p.m., Anders Lannerbäck wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21908/ --- (Updated May 26, 2014, 12:25 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- Fix for CLOUDSTACK-6464. This patch is against 4.3-branch. The original code adds broadcastUri on the format vlan://100, but later looks for HashMap keys without the vlan:// bit. This causes new interfaces be created with duplicate MACs and the routers become unusable. Diffs - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 36382e3 Diff: https://reviews.apache.org/r/21908/diff/ Testing --- Used to repair our production Cloudstack instance. Thanks, Anders Lannerbäck
Re: Review Request 21908: Fix for CLOUDSTACK-6464
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21908/#review44665 --- Commit dfb59cd6cc0292a88cb619e53f34cdb713879ffd in cloudstack's branch refs/heads/4.4-forward from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dfb59cd ] CLOUDSTACK-6464: if guest network type is vlan://untagged, and traffic label is used, kvm agent needs to honor traffic label - ASF Subversion and Git Services On May 26, 2014, 12:25 p.m., Anders Lannerbäck wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21908/ --- (Updated May 26, 2014, 12:25 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- Fix for CLOUDSTACK-6464. This patch is against 4.3-branch. The original code adds broadcastUri on the format vlan://100, but later looks for HashMap keys without the vlan:// bit. This causes new interfaces be created with duplicate MACs and the routers become unusable. Diffs - plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java 36382e3 Diff: https://reviews.apache.org/r/21908/diff/ Testing --- Used to repair our production Cloudstack instance. Thanks, Anders Lannerbäck
[ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd
CLOUDSTACK-6464: The root cause is that, in 3.0.x, if guest network is vlan://untagged, then kvm agent will use whatever value in private.network.device, while in 4.x, kvm agent will use guest.network.device. So if both value are not the same in the agent.properties, then kvm agent will use incorrect bridge to create vif. The fix will be, kvm agent code needs to honor traffic type passed down from mgt server in startcommand, in case of vlan://untagged.
Re: [GSOC2014] Progress Update - week two
Great job Darren, and thanks for the update. See inline -Sebastien On 3 Jun 2014, at 22:25, Darren Brogan brogan...@darrenbrogan.ie wrote: Hi Guys, Just a quick update on progress for last week. *[ec2stack]* Since the last progress email I've completed support of tag actions. There is now support for listing / creating / deleting Cloudstack tags through ec2stack. I wrote the required tests and updated the documentation accordingly. I was working in a branch called 'tag_support', this has been merged into master since my last email. A quick howto on how to add new api would be nice. ec2stack github repo - https://github.com/BroganD1993/ec2stack Dif you upload a new version to pypi ? *[gstack]* Since my last update I've completed work on basic GCE GA support for gstack. Anything that was supported in the original release of gstack, using the GCE v15beta API should now work with the GCE GA API. The documentation on GitHub was updated with new setup instructions for users. After completing the GCE GA support work I made a new release on pypi which is available for download here: https://pypi.python.org/pypi/gstack/0.1.0 https://pypi.python.org/pypi/gstack/0.1.0 I dont recall if we had the same version number or not. Probably good to increment it so we can upggrade via pip I began writing tests for the project, which is progressing nicely. I have most of the major functionality tested, there's still a bit of work left to do. The test support branch was merged into master earlier today. gstack project repo - https://github.com/NOPping/gstack My next step is to finish the unittesting for gstack and then move on to refactoring, restructuring cleaning of the code base. Sounds like a plan Thanks, Darren
RE: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd
Need to cherry pick it into 4.3.1 also. -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Tuesday, June 03, 2014 1:37 PM To: dev@cloudstack.apache.org Subject: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd CLOUDSTACK-6464: The root cause is that, in 3.0.x, if guest network is vlan://untagged, then kvm agent will use whatever value in private.network.device, while in 4.x, kvm agent will use guest.network.device. So if both value are not the same in the agent.properties, then kvm agent will use incorrect bridge to create vif. The fix will be, kvm agent code needs to honor traffic type passed down from mgt server in startcommand, in case of vlan://untagged.
Re: UI Development
Adding a column was just an example I was trying to figure out as it seemed like it should be straight forward if I can find where the columns are referenced. Ideally I would like to add an option for intermediate certificates when adding an SSL Cert under infrastructure. It appears I just need to add it to fields in physicalResources.js and add an entry in dictionary.jsp. This did not seem to work for me. Any advice on what I could be missing? On Tue, Jun 3, 2014 at 12:13 PM, Gabor Apati-Nagy gabor.apati-n...@citrix.com wrote: Hi Matt, There are ui controls in /ui/scripts/ui/widgets that generate the actual controls/page based on JSON definitions at /ui/scripts. AFAIK there is no complete UI documentation, but you can take a look here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+widget+samples To add a column to the UI you need to extend a JSON object where the columns in question are defined. If you search in the *.js files in /ui/scripts directory for listView and then you go any listView's fields: definition you will find examples. You can add the field/column there. If the dataProvider of the listView is already getting this column as part of the current API response (eg. debug it with FireBug or see the API), you are done. If not then the dataProvider needs to be changed as well. What is the new column that you plan to add? I would recommend discussing this on the list first. Gabor -Original Message- From: Matt Spurlin [mailto:matt.spur...@appcore.com] Sent: 03 June 2014 17:13 To: dev@cloudstack.apache.org Subject: UI Development I am trying to get a grasp on how the UI is generated for CloudStack. Are there any good documented resources for the UI? For example, say I wanted to add another column to the table of storage devices, is there any documentation that would help me figure this out?
Re: Spectacular networking fail with KVM Adv zone - can someone address this bug?
Edison applied it for some reason, I guess it won't hurt anything. On Tue, Jun 3, 2014 at 2:10 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: H Marcus, saw your comment on the patch. I refused it as well and commented 'use BroadcastDomainType to do this' . I think Nux can use the dB update as well. On 3 Jun 2014 18:46, Marcus shadow...@gmail.com wrote: Good catch. This patch works around the main problem that the mgmt server is passing broadcastUri in one way (e.g. vlan://100 in his example) for one Command and broadcastUri in another way (just '100') for a different Command. It doesn't affect fresh 4.3 installs because the way new values are stored in the DB make the code always pass 'vlan://100'. Daan and I are still discussing how to fix these. On Tue, Jun 3, 2014 at 10:21 AM, Nux! n...@li.nux.ro wrote: On 03.06.2014 16:20, Marcus wrote: I think a fresh 4.3 install with vlan isolation is pretty well tested, but there have been issues with upgrades, and apparently basic/no isolation networks. I'm taking a shot in the dark to try to help, and I'll see if I can reproduce, but the symptoms seem rather complex and varied. If I can reproduce it, I can fix it. Thanks Marcus! I have 2 deployments, both fresh 4.3, one Adv and one Adv+SG, neither exhibit this problem, so indeed it does look like an upgrade issue. It looks like someone attempted a fix, but without too much success https://reviews.apache.org/r/21908/ .. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: VPC's VR missing public NIC eth1
Hmm.. ok. I guess we can apply the bandaid patch as well On Tue, Jun 3, 2014 at 12:16 PM, Edison Su edison...@citrix.com wrote: I checked in a commit: 5e80e5d33d9a295b91cdba9377f52d9d963d802a, which will fix some of the mess of vlan id. -Original Message- From: Marcus [mailto:shadow...@gmail.com] Sent: Tuesday, June 03, 2014 9:57 AM To: Daan Hoogland Cc: dev Subject: Re: VPC's VR missing public NIC eth1 Ok, thanks. It seems there are other cases where the Command being passed from the mgmt server has inconsistent broadcastUri as well, this should blanket fix them. In the meantime there's a growing group of 4.3 upgraders who are getting pitchforks out over at CLOUDSTACK-6464, so we may want to have something in 4.3.1 too. On Tue, Jun 3, 2014 at 12:30 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: one clarification, I was not suggesting changing vlan://x back to x, just the case where x==untagged. I had a little analog discussion with Hugo and he convinced me that untagged has no special meaning in SDN cases, maybe for vxlan. So the problem I saw is at least smaller then in my mind. I have committed the db change to update 4.3.0 to 4.4.0. It will need heavy testing. And I didn't extensively look into other tables that need such a change. networks is the likely candidate but there may be others. On Mon, Jun 2, 2014 at 6:38 PM, Marcus shadow...@gmail.com wrote: Just to recap... I was trying to review the issue in my head and thought it might be useful to write it down. in 4.3 we got the BroadcastDomainType enum introduced, and many parts of the code were changed to use that when dealing with the vlan id. This code, among other things, returns a vlan id in URI format, describing both the technology used to provide the virtual lan, along with the id. Along the way this seems to have caused the value itself to be stored as a URI (still not sure where, by whom, or if it was intentional). That was fine and seemed to work after some fixing, until there was an upgrade done where the existing database value was NOT in URI format. We had a few places where the code was never changed to use BroadcastDomainType to 'normalize' the info from the database (e.g. the IpAssocVpcCommand the mgmt server constructs), so upgrades are broken. Most places in the code as it is now are working with a live value of 'vlan://x', regardless of whether the database has 'vlan://x' or just 'x', thanks to this code it returns the same 'vlan://' for either stored value. For these places it shouldn't matter if we fix the old databases to store 'vlan://x' or the 4.3 installs to go back to 'x'. However, there are a few places that are broken, like this IpAssocVpcCommand the mgmt server creates and CLOUDSTACK-5505. If we switch the db value back, we have to identify all of the outstanding ones and fix them. In addition, new code since then may have perhaps assumed that the db value is 'vlan://', and might have bothered to pass through the interpolation, so they may break as well. If we had full coverage on the test suite it would be easy to change the value back in the DB of a 4.3 or 4.4 install and see what breaks. If we don't switch the value back, and instead update old databases to the current way, it fixes the immediate issue but we end up with code doing the same thing in two different ways. Some places will be using the raw db value and other places will be asking for it to be normalized, and both will have the same result, which is kind of messy and prone to causing issues down the road if something changes again to separate these two. On Mon, Jun 2, 2014 at 10:01 AM, Marcus shadow...@gmail.com wrote: I'm not sure the KVM code needs to be changed, you're asking it to deal with an inconsistency from the mgmt server. Don't you find it odd that one Command from the mgmt server provides broadcastUri=vlan://untagged and another provides broadcastUri=untagged? I'm not sure I understand why changing 'untagged' into a URI format changes its meaning, but it seems like that doesn't make any sense to you, so perhaps we can break that out into a separate column so that we can still capture the info, if needed. If we don't like URI format for the vlan id, that's fine, but we need to do changes to the 4.3 installs and fix 4.4. As mentioned, I remember there being a decent amount of work to handle the vlan:// when it was introduced, and that will need to be done again to change it back. I'm not against that, but I'm not going to be the one doing that work, either :-) On Mon, Jun 2,
Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd
I don't think that's the root cause, but it shouldn't hurt. The root cause seems to be that we're telling the agent that the broadcastUri for the vlan is 'vlan://100' (as reported by Anders), but the IpAssocCmd passes broadcast URI as just '100'. This is a bit messy to workaround the mgmt server inconsistency in the agent, but it won't hurt. Fixing the inconsistency would be better, and Daan has applied a patch that should blanket fix that during the 4.4 upgrade. On Tue, Jun 3, 2014 at 2:44 PM, Edison Su edison...@citrix.com wrote: Need to cherry pick it into 4.3.1 also. -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Tuesday, June 03, 2014 1:37 PM To: dev@cloudstack.apache.org Subject: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd CLOUDSTACK-6464: The root cause is that, in 3.0.x, if guest network is vlan://untagged, then kvm agent will use whatever value in private.network.device, while in 4.x, kvm agent will use guest.network.device. So if both value are not the same in the agent.properties, then kvm agent will use incorrect bridge to create vif. The fix will be, kvm agent code needs to honor traffic type passed down from mgt server in startcommand, in case of vlan://untagged.
Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd
Your commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a actually does the fix mgmt server side and makes this patch irrelevant, as we are now passing a proper vlan:// in this command. However, Daan's fix will make the data in the db consistent for upgraders and fresh installers, which will fix this and all other bugs like it. On Tue, Jun 3, 2014 at 3:26 PM, Marcus shadow...@gmail.com wrote: I don't think that's the root cause, but it shouldn't hurt. The root cause seems to be that we're telling the agent that the broadcastUri for the vlan is 'vlan://100' (as reported by Anders), but the IpAssocCmd passes broadcast URI as just '100'. This is a bit messy to workaround the mgmt server inconsistency in the agent, but it won't hurt. Fixing the inconsistency would be better, and Daan has applied a patch that should blanket fix that during the 4.4 upgrade. On Tue, Jun 3, 2014 at 2:44 PM, Edison Su edison...@citrix.com wrote: Need to cherry pick it into 4.3.1 also. -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Tuesday, June 03, 2014 1:37 PM To: dev@cloudstack.apache.org Subject: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd CLOUDSTACK-6464: The root cause is that, in 3.0.x, if guest network is vlan://untagged, then kvm agent will use whatever value in private.network.device, while in 4.x, kvm agent will use guest.network.device. So if both value are not the same in the agent.properties, then kvm agent will use incorrect bridge to create vif. The fix will be, kvm agent code needs to honor traffic type passed down from mgt server in startcommand, in case of vlan://untagged.
Re: [GSOC2014] Progress Update - week two
Dif you upload a new version to pypi ? Not yet, this will be done very shortly though. I dont recall if we had the same version number or not. Probably good to increment it so we can upggrade via pip Yup, the versions numbers are different, upgrade should work fine. 0.0.1 = initial gcloud release 0.0.2 = rename from gcloud to gstack 0.0.3 = extract configuration file out of project folder 0.1.0 = Add support for GCE GA I'll add a HISTORY.rst file to the repo to keep track of release changes. Darren On Tue, Jun 3, 2014 at 9:41 PM, Sebastien Goasguen run...@gmail.com wrote: Great job Darren, and thanks for the update. See inline -Sebastien On 3 Jun 2014, at 22:25, Darren Brogan brogan...@darrenbrogan.ie wrote: Hi Guys, Just a quick update on progress for last week. *[ec2stack]* Since the last progress email I've completed support of tag actions. There is now support for listing / creating / deleting Cloudstack tags through ec2stack. I wrote the required tests and updated the documentation accordingly. I was working in a branch called 'tag_support', this has been merged into master since my last email. A quick howto on how to add new api would be nice. ec2stack github repo - https://github.com/BroganD1993/ec2stack Dif you upload a new version to pypi ? *[gstack]* Since my last update I've completed work on basic GCE GA support for gstack. Anything that was supported in the original release of gstack, using the GCE v15beta API should now work with the GCE GA API. The documentation on GitHub was updated with new setup instructions for users. After completing the GCE GA support work I made a new release on pypi which is available for download here: https://pypi.python.org/pypi/gstack/0.1.0 https://pypi.python.org/pypi/gstack/0.1.0 I dont recall if we had the same version number or not. Probably good to increment it so we can upggrade via pip I began writing tests for the project, which is progressing nicely. I have most of the major functionality tested, there's still a bit of work left to do. The test support branch was merged into master earlier today. gstack project repo - https://github.com/NOPping/gstack My next step is to finish the unittesting for gstack and then move on to refactoring, restructuring cleaning of the code base. Sounds like a plan Thanks, Darren
Re: Spectacular networking fail with KVM Adv zone - can someone address this bug?
On 03.06.2014 22:23, Marcus wrote: Edison applied it for some reason, I guess it won't hurt anything. That's fantastisch, thanks guys. Wonder how this was not caught sooner. Anyway, good job! Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: [DISCUSS] NetConf client Library for Brocade Network Plugin implemenatation...
On Tue, Jun 3, 2014 at 1:48 PM, Ritu Sabharwal rsabh...@brocade.com wrote: Hi, The Brocade Network plugin uses NetConf Java client library, NetConf4j https://github.com/dana-i2cat/netconf4j for its implementation. It is available under LGPL license. Is it ok to use this library with CloudStack or are there any other recommendations that have been used earlier for other plugins? Ritu: Ideally you'd use something with the Apache License or the BSD/MIT Licenses. If you must use something with the L/GPL license you should understand a few things: 1. We can't carry that (or any) dependency in our source tree. All should be available via the Maven central repo. (yes, we have one problem plugin now, Juniper's Contrail - had I seen that it required manually downloading a file I would have vetoed it's inclusion) 2. We will not be able to enable your plugin in the default build. This may not be a huge deal, we still have quite a few things in our non-default build, but just a heads up that it will need to build only with the noredist profile. --David
Re: [DISCUSS] Increasing VM IOPS by separating golden image in high IOPS partition in Xen Server ?
Hi Mike,
You are right, performance will be decreased over time because writes IOPS
will always end up on slower storage pool.
In our case, we are using CloudStack integrated in VDI solution to provived
pooled VM type[1]. So may be my approach can bring better UX for user with
lower bootime ...
A short change in design are followings
- VM will be deployed with golden primary storage if primary storage is
marked golden and this VM template is also marked as golden.
- Choosing the best deploy destionation for both golden primary storage and
normal root volume primary storage. Chosen host can also access both
storage pools.
- New Xen Server plug-in for modifying VHD parent id.
Is there some place for me to submit my design and code. Can I write a new
proposal in CS wiki ?
[1]:
http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-choose-scheme-type-rho.html
On Mon, Jun 2, 2014 at 9:04 PM, Mike Tutkowski mike.tutkow...@solidfire.com
wrote:
It is an interesting idea. If the constraints you face at your company can
be corrected somewhat by implementing this, then you should go for it.
It sounds like writes will be placed on the slower storage pool. This means
as you update OS components, those updates will be placed on the slower
storage pool. As such, your performance is likely to somewhat decrease over
time (as more and more writes end up on the slower storage pool).
That may be OK for your use case(s), though.
You'll have to update the storage-pool orchestration logic to take this new
scheme into account.
Also, we'll have to figure out how this ties into storage tagging (if at
all).
I'd be happy to review your design and code.
On Mon, Jun 2, 2014 at 1:54 AM, Hieu LE hieul...@gmail.com wrote:
Thanks Mike and Punith for quick reply.
Both solutions you gave here are absolutely correct. But as I mentioned
in
the first email, I want another better solution for current
infrastructure
at my company.
Creating a high IOPS primary storage using storage tags is good but it
will
be very waste of disk capacity. For example, if I only have 1TB SSD and
deploy 100 VM from a 100GB template.
So I think about a solution where a high IOPS primary storage can only
store golden image (master image), and a child image of this VM will be
stored in another normal (NFS, ISCSI...) storage. In this case, with 1TB
SSD Primary Storage I can store as much golden image as I need.
I have also tested it with 256 GB SSD mounted on Xen Server 6.2.0 with
2TB
local storage 1RPM, 6TB NFS share storage with 1GB network. The IOPS
of
VMs which have golden image (master image) in SSD and child image in NFS
increate more than 30-40% compare with VMs which have both golden image
and
child image in NFS. The boot time of each VM is also decrease. ('cause
golden image in SSD only reduced READ IOPS).
Do you think this approach OK ?
On Mon, Jun 2, 2014 at 12:50 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
Thanks, Punith - this is similar to what I was going to say.
Any time a set of CloudStack volumes share IOPS from a common pool, you
cannot guarantee IOPS to a given CloudStack volume at a given time.
Your choices at present are:
1) Use managed storage (where you can create a 1:1 mapping between a
CloudStack volume and a volume on a storage system that has QoS). As
Punith
mentioned, this requires that you purchase storage from a vendor who
provides guaranteed QoS on a volume-by-volume bases AND has this
integrated
into CloudStack.
2) Create primary storage in CloudStack that is not managed, but has a
high
number of IOPS (ex. using SSDs). You can then storage tag this primary
storage and create Compute and Disk Offerings that use this storage tag
to
make sure their volumes end up on this storage pool (primary storage).
This
will still not guarantee IOPS on a CloudStack volume-by-volume basis,
but
it will at least place the CloudStack volumes that need a better chance
of
getting higher IOPS on a storage pool that could provide the necessary
IOPS. A big downside here is that you want to watch how many CloudStack
volumes get deployed on this primary storage because you'll need to
essentially over-provision IOPS in this primary storage to increase the
probability that each and every CloudStack volume that uses this
primary
storage gets the necessary IOPS (and isn't as likely to suffer from the
Noisy Neighbor Effect). You should be able to tell CloudStack to only
use,
say, 80% (or whatever) of the storage you're providing to it (so as to
increase your effective IOPS per GB ratio). This over-provisioning of
IOPS
to control Noisy Neighbors is avoided in option 1. In that situation,
you
only provision the IOPS and capacity you actually need. It is a much
more
sophisticated approach.
Thanks,
Mike
On Sun, Jun 1, 2014 at 11:36
Re: [DISCUSS] Increasing VM IOPS by separating golden image in high IOPS partition in Xen Server ?
Hi,
Yes, please feel free to add a new Wiki page for your design.
Here is a link to applicable design info:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design
Also, feel free to ask more questions and have me review your design.
Thanks!
Mike
On Tue, Jun 3, 2014 at 7:29 PM, Hieu LE hieul...@gmail.com wrote:
Hi Mike,
You are right, performance will be decreased over time because writes IOPS
will always end up on slower storage pool.
In our case, we are using CloudStack integrated in VDI solution to provived
pooled VM type[1]. So may be my approach can bring better UX for user with
lower bootime ...
A short change in design are followings
- VM will be deployed with golden primary storage if primary storage is
marked golden and this VM template is also marked as golden.
- Choosing the best deploy destionation for both golden primary storage and
normal root volume primary storage. Chosen host can also access both
storage pools.
- New Xen Server plug-in for modifying VHD parent id.
Is there some place for me to submit my design and code. Can I write a new
proposal in CS wiki ?
[1]:
http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-choose-scheme-type-rho.html
On Mon, Jun 2, 2014 at 9:04 PM, Mike Tutkowski
mike.tutkow...@solidfire.com
wrote:
It is an interesting idea. If the constraints you face at your company
can
be corrected somewhat by implementing this, then you should go for it.
It sounds like writes will be placed on the slower storage pool. This
means
as you update OS components, those updates will be placed on the slower
storage pool. As such, your performance is likely to somewhat decrease
over
time (as more and more writes end up on the slower storage pool).
That may be OK for your use case(s), though.
You'll have to update the storage-pool orchestration logic to take this
new
scheme into account.
Also, we'll have to figure out how this ties into storage tagging (if at
all).
I'd be happy to review your design and code.
On Mon, Jun 2, 2014 at 1:54 AM, Hieu LE hieul...@gmail.com wrote:
Thanks Mike and Punith for quick reply.
Both solutions you gave here are absolutely correct. But as I mentioned
in
the first email, I want another better solution for current
infrastructure
at my company.
Creating a high IOPS primary storage using storage tags is good but it
will
be very waste of disk capacity. For example, if I only have 1TB SSD and
deploy 100 VM from a 100GB template.
So I think about a solution where a high IOPS primary storage can only
store golden image (master image), and a child image of this VM will be
stored in another normal (NFS, ISCSI...) storage. In this case, with
1TB
SSD Primary Storage I can store as much golden image as I need.
I have also tested it with 256 GB SSD mounted on Xen Server 6.2.0 with
2TB
local storage 1RPM, 6TB NFS share storage with 1GB network. The
IOPS
of
VMs which have golden image (master image) in SSD and child image in
NFS
increate more than 30-40% compare with VMs which have both golden image
and
child image in NFS. The boot time of each VM is also decrease. ('cause
golden image in SSD only reduced READ IOPS).
Do you think this approach OK ?
On Mon, Jun 2, 2014 at 12:50 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
Thanks, Punith - this is similar to what I was going to say.
Any time a set of CloudStack volumes share IOPS from a common pool,
you
cannot guarantee IOPS to a given CloudStack volume at a given time.
Your choices at present are:
1) Use managed storage (where you can create a 1:1 mapping between a
CloudStack volume and a volume on a storage system that has QoS). As
Punith
mentioned, this requires that you purchase storage from a vendor who
provides guaranteed QoS on a volume-by-volume bases AND has this
integrated
into CloudStack.
2) Create primary storage in CloudStack that is not managed, but has
a
high
number of IOPS (ex. using SSDs). You can then storage tag this
primary
storage and create Compute and Disk Offerings that use this storage
tag
to
make sure their volumes end up on this storage pool (primary
storage).
This
will still not guarantee IOPS on a CloudStack volume-by-volume basis,
but
it will at least place the CloudStack volumes that need a better
chance
of
getting higher IOPS on a storage pool that could provide the
necessary
IOPS. A big downside here is that you want to watch how many
CloudStack
volumes get deployed on this primary storage because you'll need to
essentially over-provision IOPS in this primary storage to increase
the
probability that each and every CloudStack volume that uses this
primary
storage gets the necessary IOPS (and isn't as likely to suffer from
the
Noisy Neighbor
Re: [DISCUSS] Increasing VM IOPS by separating golden image in high IOPS partition in Xen Server ?
Hi Mike,
Could you please give edit/create permission on ASF Jira/Wiki confluence ?
I can not add a new Wiki page.
My Jira ID: hieulq
Wiki: hieulq89
Review Board: hieulq
Thanks !
On Wed, Jun 4, 2014 at 9:17 AM, Mike Tutkowski mike.tutkow...@solidfire.com
wrote:
Hi,
Yes, please feel free to add a new Wiki page for your design.
Here is a link to applicable design info:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design
Also, feel free to ask more questions and have me review your design.
Thanks!
Mike
On Tue, Jun 3, 2014 at 7:29 PM, Hieu LE hieul...@gmail.com wrote:
Hi Mike,
You are right, performance will be decreased over time because writes
IOPS
will always end up on slower storage pool.
In our case, we are using CloudStack integrated in VDI solution to
provived
pooled VM type[1]. So may be my approach can bring better UX for user
with
lower bootime ...
A short change in design are followings
- VM will be deployed with golden primary storage if primary storage is
marked golden and this VM template is also marked as golden.
- Choosing the best deploy destionation for both golden primary storage
and
normal root volume primary storage. Chosen host can also access both
storage pools.
- New Xen Server plug-in for modifying VHD parent id.
Is there some place for me to submit my design and code. Can I write a
new
proposal in CS wiki ?
[1]:
http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-choose-scheme-type-rho.html
On Mon, Jun 2, 2014 at 9:04 PM, Mike Tutkowski
mike.tutkow...@solidfire.com
wrote:
It is an interesting idea. If the constraints you face at your company
can
be corrected somewhat by implementing this, then you should go for it.
It sounds like writes will be placed on the slower storage pool. This
means
as you update OS components, those updates will be placed on the slower
storage pool. As such, your performance is likely to somewhat decrease
over
time (as more and more writes end up on the slower storage pool).
That may be OK for your use case(s), though.
You'll have to update the storage-pool orchestration logic to take this
new
scheme into account.
Also, we'll have to figure out how this ties into storage tagging (if
at
all).
I'd be happy to review your design and code.
On Mon, Jun 2, 2014 at 1:54 AM, Hieu LE hieul...@gmail.com wrote:
Thanks Mike and Punith for quick reply.
Both solutions you gave here are absolutely correct. But as I
mentioned
in
the first email, I want another better solution for current
infrastructure
at my company.
Creating a high IOPS primary storage using storage tags is good but
it
will
be very waste of disk capacity. For example, if I only have 1TB SSD
and
deploy 100 VM from a 100GB template.
So I think about a solution where a high IOPS primary storage can
only
store golden image (master image), and a child image of this VM will
be
stored in another normal (NFS, ISCSI...) storage. In this case, with
1TB
SSD Primary Storage I can store as much golden image as I need.
I have also tested it with 256 GB SSD mounted on Xen Server 6.2.0
with
2TB
local storage 1RPM, 6TB NFS share storage with 1GB network. The
IOPS
of
VMs which have golden image (master image) in SSD and child image in
NFS
increate more than 30-40% compare with VMs which have both golden
image
and
child image in NFS. The boot time of each VM is also decrease.
('cause
golden image in SSD only reduced READ IOPS).
Do you think this approach OK ?
On Mon, Jun 2, 2014 at 12:50 PM, Mike Tutkowski
mike.tutkow...@solidfire.com wrote:
Thanks, Punith - this is similar to what I was going to say.
Any time a set of CloudStack volumes share IOPS from a common pool,
you
cannot guarantee IOPS to a given CloudStack volume at a given time.
Your choices at present are:
1) Use managed storage (where you can create a 1:1 mapping between
a
CloudStack volume and a volume on a storage system that has QoS).
As
Punith
mentioned, this requires that you purchase storage from a vendor
who
provides guaranteed QoS on a volume-by-volume bases AND has this
integrated
into CloudStack.
2) Create primary storage in CloudStack that is not managed, but
has
a
high
number of IOPS (ex. using SSDs). You can then storage tag this
primary
storage and create Compute and Disk Offerings that use this storage
tag
to
make sure their volumes end up on this storage pool (primary
storage).
This
will still not guarantee IOPS on a CloudStack volume-by-volume
basis,
but
it will at least place the CloudStack volumes that need a better
chance
of
getting higher IOPS on a storage pool that could provide
Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity
On June 3, 2014, 11:07 a.m., Santhosh Edukulla wrote: Ship It! Hi Hugo, Can you commit the latest patch as well which fixes the issue reported by Santhosh. - Rajani --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/#review44610 --- On June 3, 2014, 11:02 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22193/ --- (Updated June 3, 2014, 11:02 a.m.) Review request for cloudstack, Abhinandan Prateek, daan Hoogland, and Santhosh Edukulla. Repository: cloudstack-git Description --- The issue is reported by coverity scan @ https://scan.coverity.com/projects/943 Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java 7fe285f Diff: https://reviews.apache.org/r/22193/diff/ Testing --- Thanks, Rajani Karuturi
