RE: [DISCUSS] Breaking out Marvin from CloudStack

2013-10-06 Thread Animesh Chaturvedi


> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Friday, October 04, 2013 1:53 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Breaking out Marvin from CloudStack
> 
> 
> Fair warning - some of this is a straw man argument to explore the
> situation, and a little bit of ranting at the end.
> 
> On Fri, Oct 04, 2013 at 05:57:58PM +0530, Prasanna Santhanam wrote:
> > I'll summarize and address the concerns raised so far.
> >
> > Marvin has been in this repo for a long time for us to start writing
> > tests. The only tests I've seen coming are from a specific set of
> > people focussed on QA efforts.
> 
> I agree - and that's a problem.  New features should *ALL* have tests
> before they merge into master.  I think that assuming that the only test
> writers are a group of folks that write the tests today is actually a
> larger problem.

> 
> > I want to reduce the impediment for
> > people who are writing tests *today*. Those looking to get started in
> > the near future won't have any new learning to do, just that their
> > code goes in an alternate repo that is pointed to right
> > infrastructure.
> >
> > Automated testing also works in a push-to-production style very often.
> > Testers need to run their tests on a deployed environment(s) quickly
> > to be able to ensure it is valid and passes. By making them go through
> > reviewboard each time for each test we massively slow down the
> > process. (tons of fixes to tests are on rb today, not just new tests).
> > We don't know if they run until they run on the environment.
> 
> I want to be clear about this part - a different repo doesn't change the
> need for someone to be a committer to commit.
> 
[Animesh>] Test code contribution is similar to code contribution and the issue 
is not reviewboard but folks not responding to reviews. We need to address them 
as community. If we have to get new committers we should bring them forward.

> There's a thread on private@ that you should weigh in on here.  If we
> have more people that should be committers, then let's get *that* done.
> 
> >
> > Reason for tests and framework to go together is simple.  If I go look
> > at the jclouds repository today I find tests for rackspace cloud,
> > openstack cloud, cloudstack cloud, euca clouds in the jclouds
> > repository and not in the respective provider/project repository. A
> > newcomer to the marvin repository will be someone interested in
> > writing tests and he will also thus be able to find tests in the
> > marvin repository.
> >
> > This also allows for more heterogenous testing of cloudstack. No one
> > needs to be tied down to a framework / tool to write integration
> > tests. If python is not your forte, use Chip's ruby client, or perhaps
> > in the near future Chiradeep's stackmate to write your test, or even
> > jclouds.
> 
> But that's actually true today, right?  I mean if I wanted to write an
> integration test using some other method, I'd do that...  but would it
> be useful for others?  Probably not!  That's because the way that we do
> testing of this type is via Marvin.  The Citrix infra wouldn't be setup
> for whatever other framework I used, and the community as a whole would
> get less benefit than if I was consistent.
> 
[Animesh>] I agree having consistent tooling shortens the learning cycle for 
new contributors
> >
> > Now the question of supporting older version of marvin against newer
> > versions of cloudstack. Marvin now fully auto-generates itself (see
> > the design in the proposal) based on endpoint. So you have the marvin
> > version that will work with your endpoint only. As for being backwards
> > compatible (also addressed in the design doc) - no old tests are
> > broken, they will still run perfectly fine.
> >
> 
> That's marvin, not the tests, right?  If I add a new feature for 4.3,
> should that test appear in a 4.2 run?  Aren't we aiming for (I know
> we're not there) a situation where *all* tests pass before we release?
> IMO not versioning the tests (not the Marvin framework) with the target
> of the tests is confusing.
> 
[Animesh>] IMO "Things that change together, should live together", separate 
repo for tests does not sit well


> > The infrastructure (currently) only looks at the changes in the test
> > directory before performing a run. It doesn't care whether server/ was
> > changed or plugins/x/y/z was changed. That's because the tests are
> > unrelated to what is in the rest of the repository. In fact you can't
> > even run them without a deployed cloud. So I don't see why idle code
> > should lie in the repo.
> >
> > Integration tests are essential, they will keep coming as long as
> > Citrix QA is invested in the effort, but they need to come faster into
> > the repos and that will be addressed by the separation IMO.
> 
> How?
[Animesh>] Like Chip, I don't see breaking tests into separate repo will 
increase their velocity.

> 
> > Managing
> > the feature s

RE: [DISCUSS] Breaking out Marvin from CloudStack

2013-10-06 Thread Animesh Chaturvedi


> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Saturday, October 05, 2013 3:22 AM
> To: dev
> Subject: Re: [DISCUSS] Breaking out Marvin from CloudStack
> 
> H Chip,
> 
> As a feature-dev driven by a 150-man-strong-cloud-operator-base that is
> not interested in anything but me showing that they can work with what
> they asked for:
> 
> On Fri, Oct 4, 2013 at 10:52 PM, Chip Childers
> wrote:
> ...
> 
> > On Fri, Oct 04, 2013 at 05:57:58PM +0530, Prasanna Santhanam wrote:
> > > I'll summarize and address the concerns raised so far.
> > >
> > > Marvin has been in this repo for a long time for us to start writing
> > > tests. The only tests I've seen coming are from a specific set of
> > > people focussed on QA efforts.
> >
> > I agree - and that's a problem.  New features should *ALL* have tests
> > before they merge into master.  I think that assuming that the only
> > test writers are a group of folks that write the tests today is
> > actually a larger problem.
> >
> 
> Yes and we will need to work down a backlog of scenarios before we ever
> can rely on guys like me doing that. Not because they won't but because
> there is to much to write tests for edging on the new features they
> write. Just because those tests aren't there yet. I think giving Citrix
> QA a repo to work on is fine but I would like to see it merged back at
> some point and a continued possibility to write them in the main tree.
> 
[Animesh>] While I don't agree to a separate repo for tests (marvin framework 
is ok) I do want to call out the proposal is not for giving Citrix QA a repo to 
work on and I don't think Prasanna meant that way. 

> >
> > > I want to reduce the impediment for
> > > people who are writing tests *today*. Those looking to get started
> > > in the near future won't have any new learning to do, just that
> > > their code goes in an alternate repo that is pointed to right
> > > infrastructure.
> >
> @prasanna: education of the developers is also something to consider. I
> know I could contribute more to integration and at Schuberg Philis we
> have some work going on in that direction. It would be nice to see easy
> integration of this with the Citrix work.
> 
> 
> >
> ...
> 
> > >
> > > Reason for tests and framework to go together is simple.
> >
> Guys, why not both. some general tests that will be valid for any ACS
> version can go in the marvin code base. Others that change over time
> should be tied to the version of ACS they apply to.
> 
> Test can be moved from one repo to the other if needed.
> 
> ...
> 
> >
> > That's marvin, not the tests, right?  If I add a new feature for 4.3,
> > should that test appear in a 4.2 run?  Aren't we aiming for (I know
> > we're not there) a situation where *all* tests pass before we release?
> > IMO not versioning the tests (not the Marvin framework) with the
> > target of the tests is confusing.
> >
> That I agree with completely.
> 
> 
> > > The infrastructure (currently) only looks at the changes in the test
> > > directory before performing a run. It doesn't care whether server/
> > > was changed or plugins/x/y/z was changed. That's because the tests
> > > are unrelated to what is in the rest of the repository. In fact you
> > > can't even run them without a deployed cloud. So I don't see why
> > > idle code should lie in the repo.
> >
> You can trigger the building of a cloud when code changes and run the
> tests against that.
> 
> >  >
> > > Integration tests are essential, they will keep coming as long as
> > > Citrix QA is invested in the effort, but they need to come faster
> > > into the repos and that will be addressed by the separation IMO.
> >
> > How?
> >
> > > Managing
> > > the feature submitted to cloudstack against tests submitted to
> > > marvin is not a hard thing to do. We simply mirror the release
> > > branches in marvin and submit tests there. In fact I wonder why we
> > > didn't have this question when docs were separated? It doesn't work
> > > any differently really.
> >
> > Well, it turns out that docs are absolutely not being done before code
> > comes into master.  I dislike this fact, but live with it.
> >
> I don't see why a feature has to be published when it is implemented. So
> I don't agree on the docs. The great advantage of hidden features is
> that you can take them out again more easily when they don't meet the
> promise they made when implemented. So Docs shouldn't be written (or at
> least published) until features are used in real live imho.
> 
> 
> > > What I would like to see provided by CloudStack is the ability to
> > > upgrade all our test environments, staging environments, UATs, what
> > > have you in continuous integration and have tests run on the
> > > upgraded setup. That allows incrementally testing CloudStack the way
> > > users do it. The current design of installing everything from
> > > scratch, redoing the testbed for each automated test run is mostly a
> > > workaround fo

Review Request 14514: MacAddress cleanup and test

2013-10-06 Thread Laszlo Hornyak

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

- main method removed since it was not used by any other code
- commonted-out code removed
- Formatter close added
- commons IOUtils to close resources - somewhat shorter than the try-catch block
- tests added


Diffs
-

  utils/src/com/cloud/utils/net/MacAddress.java 15350c8 
  utils/test/com/cloud/utils/net/MacAddressTest.java PRE-CREATION 

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


Testing
---

tests added


Thanks,

Laszlo Hornyak



Re: [DISCUSS] Breaking out Marvin from CloudStack

2013-10-06 Thread Daan Hoogland
On Sun, Oct 6, 2013 at 8:10 PM, Animesh Chaturvedi <
animesh.chaturv...@citrix.com> wrote:

> > Yes and we will need to work down a backlog of scenarios before we ever
> > can rely on guys like me doing that. Not because they won't but because
> > there is to much to write tests for edging on the new features they
> > write. Just because those tests aren't there yet. I think giving Citrix
> > QA a repo to work on is fine but I would like to see it merged back at
> > some point and a continued possibility to write them in the main tree.
> >
> [Animesh>] While I don't agree to a separate repo for tests (marvin
> framework is ok) I do want to call out the proposal is not for giving
> Citrix QA a repo to work on and I don't think Prasanna meant that way.
>


I have to apologize for the formulations I choose to express my thoughts
with. I did not mean to talk of a department of a certain company donating
human effort for testing to the community. I was talking of the frustration
of the individuals working and how the separate repo would smoothen their
workflow. The new repo is in the apache domain, no question whether the
work in their is done by one person or 100 companies.


Re: [DISCUSS] Components in JIRA and bug assignment

2013-10-06 Thread Daan Hoogland
I have doubts about this thought it would seem productive. It constructs a
small assignment hierarchy in the community which feels fine for any
company project I have worked on in the past.

It feels out of place.
. Are those component maintainers going to have monopoly on assigning
tickets pertaining to 'their' component?
. as a featurist: a ticket will usually pertain to several components. it
can be for instance UI - API - orchestration - provisioning - network -
storage. I would think the person entering the ticket has the
responsibility of finding devs/assigning the work. (dis)agree?

I actually prefer unassigned tickets and a irc meeting like discussion on
them once in a while.

just €0,02
Daan



On Sun, Oct 6, 2013 at 6:08 AM, Rajesh Battala wrote:

> +1 for the proposal.
>
> -Original Message-
> From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
> Sent: Saturday, October 5, 2013 12:42 AM
> To: dev@cloudstack.apache.org; Musayev, Ilya
> Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> Importance: High
>
> On 10/4/13 10:37 AM, "Musayev, Ilya"  wrote:
>
> >> On Fri, Oct 04, 2013 at 05:11:32PM +, Musayev, Ilya wrote:
> >> > Question to JIRA experienced admins, we can preserve "assign to me"
> >> option, and if unassigned goto "component" maintainer?
> >>
> >> Absolutely.  Initial assignment does not equal the actual assignee.
> >> Component-based assignment is just a way to skip the unassigned
> >> phase, but people can reassign to themselves or others.
> >>
> >> -chip
> >
> >Chip, thanks for the answer.
> >
> >So far, I've yet to see someone speaking negatively on this proposal.
> >We do need  better structure - that will also help us being productive.
> >
> >Please kindly respond with +1, 0 or -1
> >
> >If -1, please explain why.
> >
> >Thanks
> >ilya
> >
> >
>
>
> +1
>
> -Alena.
>
>


Re: Review Request 14076: New test added for template copy feature

2013-10-06 Thread Nitin Mehta

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



test/integration/component/test_templates.py


there should be source zone id as well



test/integration/component/test_templates.py


Is this a blocking call ? Have you tested this ? Does it return success



test/integration/component/test_templates.py


Why are these assertions required when we repeat them in the loop ?



test/integration/component/test_templates.py


change the comment



test/integration/component/test_templates.py


Change this comment...this confused me...
Say something like "check template downloaded by polling, then delete it 
finally"



test/integration/component/test_templates.py


timeout is generally is not a count...what is the value typically u will 
keep ? 




test/integration/component/test_templates.py


how long will the sleep will be for ? 


- Nitin Mehta


On Sept. 18, 2013, 2:29 p.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14076/
> ---
> 
> (Updated Sept. 18, 2013, 2:29 p.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, Harikrishna Patnala, and 
> Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added one missing test for test_templates.py from old QA repo to Cloudstack   
>   
> 
> def test_02_copy_template
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_templates.py e4599d4 
> 
> Diff: https://reviews.apache.org/r/14076/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>



[DOC] 4.2.0 Templates

2013-10-06 Thread Marty Sweet
Hi guys,

I created a document for creating Linux documentation for the 4.2.0
release. Checking the documentation it seems that it is not there? Is there
any reason for this?

http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Admin_Guide/working-with-templates.html

https://github.com/apache/cloudstack/commit/922ef76224d4a8534f67f47b97cf664e5c65ecba
https://issues.apache.org/jira/browse/CLOUDSTACK-4329

Thanks,
Marty


Re: Resize data-disk doesn't work after upgrade

2013-10-06 Thread Indra Pramana
Dear Marcus, Kirk and all,

Any further recommendations on how can I troubleshoot on this matter to
pinpoint the cause of the inability to resize the disk, and to find the
solution to the problem?

Looking forward to your reply, thank you.

Cheers.



On Fri, Oct 4, 2013 at 3:30 PM, Indra Pramana  wrote:

> Hi Marcus and Kirk,
>
> Good day to you, and thank you for your email replies.
>
> We are using Ceph RBD primary storage. I can't find any error information
> on agent.log, and I have set the logging to verbose (DEBUG) for all.
>
> Since I am using RBD, am I still able to run the qemu-img info command?
>
> I check the volumes table contain load of information. How do I check
> which record is referring to the virtual disk in question?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
> On Fri, Oct 4, 2013 at 6:58 AM, Kirk Kosinski wrote:
>
>> Yes, if there was a problem it should have been logged in the agent.log.
>>  If it was successful it may or may not be logged depending on the
>> logging level.  While logged on to the hypervisor, check the actual
>> virtual disk with "qemu-img info /mnt/somepath/filename".  The filename
>> can be found in the CloudStack database (the "path" field for the
>> virtual disk in the volumes table).
>>
>> Best regards,
>> Kirk
>>
>> On 10/03/2013 03:47 PM, Marcus Sorensen wrote:
>> > What primary storage are you using? Any errors in agent log?
>> > On Oct 3, 2013 3:16 PM, "Indra Pramana"  wrote:
>> >
>> >> Hi Marcus,
>> >>
>> >> Good day to you, and thank you for your e-mail.
>> >>
>> >> I have tried restarting the VM and even stop and start the VM, but
>> after
>> >> logging in to the VM, I still see the hard drive's size as 20 GB
>> instead of
>> >> 60 GB.
>> >>
>> >> I tried to check /var/log/libvirt/libvirtd.log file on the KVM host
>> where
>> >> the VM is hosted, and can't find any messages related to
>> volBlockResize.
>> >>
>> >> Any other troubleshooting steps you can recommend, i.e. any other area
>> I
>> >> can look into?
>> >>
>> >> Looking forward to your reply, thank you.
>> >>
>> >> Cheers.
>> >>
>> >>
>> >>
>> >> On Fri, Oct 4, 2013 at 4:46 AM, Marcus Sorensen 
>> >> wrote:
>> >>
>> >>> I just tested local storage qcow2 and CLVM resize on 4.2, they both
>> >> worked.
>> >>>
>> >>> Resize works like this:
>> >>>
>> >>> 1. Do sanity checks
>> >>> 2. Send resize command to the agent
>> >>> 3. Resize the disk/lun/file
>> >>> 4. Inform the VM instance that the disk has changed by making a
>> >>> libvirt volBlockResize call (this is not fatal, some guest types can't
>> >>> resize online and need to be restarted)
>> >>> 5. Update the database
>> >>>
>> >>> You can check #3 looking at the disks themselves on storage to see if
>> >>> they've grown. You can check #4 by restarting the VM to see if it
>> >>> picks up the change.
>> >>>
>> >>> It may be that libvirt was unable to inform the VM of the change (for
>> >>> example if you haven't upgraded to a supported version of Ubuntu or
>> >>> CentOS and it has an old libvirt that doesn't support volBlockResize).
>> >>>  The way to know for sure is stop/start the VM if you can.
>> >>>
>> >>> Look at those two things and let us know
>> >>>
>> >>> On Thu, Oct 3, 2013 at 2:33 PM, Indra Pramana  wrote:
>>  Dear all,
>> 
>>  After upgrading to 4.2.0, I tried to resize a data disk of a VM
>> >> instance
>>  from 20 GB to 60 GB, through the Cloudstack GUI. The UI reports that
>> >> the
>>  resize was successful, and that the data disk is now showing 60 GB
>> >>> instead
>>  of 20 GB. However, when I check the actual disk on the VM, it seems
>> >> that
>>  it's still 20 GB.
>> 
>>  Any reason what might have been the cause of the problem? I even
>> tried
>> >> to
>>  re-partition it to see if the size changed, but it wasn't and still
>> at
>> >> 20
>>  GB. Which logs I need to look into?
>> 
>>  Any help on this is greatly appreciated.
>> 
>>  Looking forward to your reply, thank you.
>> 
>>  Cheers.
>> >>>
>> >>
>> >
>>
>
>


Unable to reboot instance: "Unable to find service offering: [NUMBER] corresponding to the vm"

2013-10-06 Thread Indra Pramana
Dear all,

After upgrading to CloudStack 4.2.0, I am not able to reboot a VM instance.
Error message: "Unable to find service offering: [SOME-RANDOM-NUMBER]
corresponding to the vm". This affects all the VM instances that I want to
reboot.

Any idea what could be the cause of the problem? Seems that it cannot find
a certain service offering which corresponds to the VM, anyone can shed a
light on which service offering it is referring to?

Looking forward to your reply, thank you.

Cheers.


Console

2013-10-06 Thread Maurice Lawler

Hello,

Odd question, has anyone experience the pop up console being black and 
hard to see what the mounted ISO is attempting to install? If so, how 
can one correct this issue.


 - M.


RE: [DISCUSS] Components in JIRA and bug assignment

2013-10-06 Thread Animesh Chaturvedi


> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Sunday, October 06, 2013 12:16 PM
> To: dev
> Cc: Musayev, Ilya
> Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> 
> I have doubts about this thought it would seem productive. It constructs
> a small assignment hierarchy in the community which feels fine for any
> company project I have worked on in the past.
> 
> It feels out of place.
> . Are those component maintainers going to have monopoly on assigning
> tickets pertaining to 'their' component?
[Animesh>] There is no monopoly or hierarchy, everyone is equal. When someone 
asks another person to pick up an issue it is a request not an assignment. They 
can always say they can't and unassign with comments
> . as a featurist: a ticket will usually pertain to several components.
> it can be for instance UI - API - orchestration - provisioning - network
> - storage. I would think the person entering the ticket has the
> responsibility of finding devs/assigning the work. (dis)agree?
> 
[Animesh>] That's reasonable for a ticket created by a QA member of the 
community but for tickets coming from users they may not know who should those 
be assigned and we would like to lower the barrier of entry for users reporting 
the defects.

> I actually prefer unassigned tickets and a irc meeting like discussion
> on them once in a while.
> 
> just €0,02
> Daan
> 
> 
> 
> On Sun, Oct 6, 2013 at 6:08 AM, Rajesh Battala
> wrote:
> 
> > +1 for the proposal.
> >
> > -Original Message-
> > From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
> > Sent: Saturday, October 5, 2013 12:42 AM
> > To: dev@cloudstack.apache.org; Musayev, Ilya
> > Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> > Importance: High
> >
> > On 10/4/13 10:37 AM, "Musayev, Ilya"  wrote:
> >
> > >> On Fri, Oct 04, 2013 at 05:11:32PM +, Musayev, Ilya wrote:
> > >> > Question to JIRA experienced admins, we can preserve "assign to
> me"
> > >> option, and if unassigned goto "component" maintainer?
> > >>
> > >> Absolutely.  Initial assignment does not equal the actual assignee.
> > >> Component-based assignment is just a way to skip the unassigned
> > >> phase, but people can reassign to themselves or others.
> > >>
> > >> -chip
> > >
> > >Chip, thanks for the answer.
> > >
> > >So far, I've yet to see someone speaking negatively on this proposal.
> > >We do need  better structure - that will also help us being
> productive.
> > >
> > >Please kindly respond with +1, 0 or -1
> > >
> > >If -1, please explain why.
> > >
> > >Thanks
> > >ilya
> > >
> > >
> >
> >
> > +1
> >
> > -Alena.
> >
> >


Re: Review Request 14335: CLOUDSTACK-4262: Fix TestVPCNetworkGc.test_01_wait_network_gc

2013-10-06 Thread Girish Shilamkar

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

(Updated Oct. 7, 2013, 4:54 a.m.)


Review request for cloudstack, Harikrishna Patnala and venkata swamy babu  
budumuru.


Changes
---

I have added the assert for netacls. But it seems the netacls are not cleared. 
I will file a separate defect for this. Thanks.


Bugs: CLOUDSTACK-4262


Repository: cloudstack-git


Description
---

As per the test plan, after waiting for network gc
LB rules should be cleared. Added that check instead of router
being in stopped state.


Diffs (updated)
-

  test/integration/component/test_vpc_network.py 970a625 

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


Testing
---


Thanks,

Girish Shilamkar



Edit access to Jira

2013-10-06 Thread Damoder Reddy
Hi,

Can you please provide me the edit access to Jira. Following are my user
details:

Username: damoder.reddy
Mail id: damoder.re...@citrix.com

Please do the needful.

Thanks
Damodar


Edit access to Jira

2013-10-06 Thread Damoder Reddy
Hi,

Can you please provide me the edit access to Jira. Following are my user
details:

Username: damoder.reddy
Mail id: damoder.re...@citrix.com

Please do the needful.

Thanks
Damodar


Re: Edit access to Jira

2013-10-06 Thread Prasanna Santhanam
On Mon, Oct 07, 2013 at 05:34:35AM +, Damoder Reddy wrote:
> Hi,
> 
> Can you please provide me the edit access to Jira. Following are my user
> details:
> 
> Username: damoder.reddy
> Mail id: damoder.re...@citrix.com
> 
> Please do the needful.
Make sure you register with the wiki (http://cwiki.apache.org) as well
with the same address so I can provide you with edit access to cwiki.

JIRA permissions have been given for username: damoder.reddy
> 
> Thanks
> Damodar

-- 
Prasanna.,


Powered by BigRock.com