Re: [ACS45][ACS50][PROPOSAL] move forward feature freeze

[Daan Hoogland]

On Wed, Jun 25, 2014 at 11:11 PM, Animesh Chaturvedi
 wrote:
> In response to Brocade I see your response
>
> "feature should be done (in it's branch) by 19th july. merging and fixing 
> issues may take to mid august" that essentially means feature freeze (cutting 
> the branch) by mid august


it means code freeze at mid august., not feature freeze.

-- 
Daan

Re: OpenVM.eu - repository of Cloudstack images and appliances

[Daan Hoogland]

love it Lucian, How will the procedure for submissions look? (I'm
thinking a mail to you with a download link)

On Thu, Jun 26, 2014 at 1:18 AM, David Nalley  wrote:
> This is awesome on Nux's part. I am thrilled to see this come to fruition.
>
> This is not an official CloudStack deployment. There are a number of
> reasons why this needs to be external (for instance, much of what he
> has up for download is GPL-licensed; it's not our software, etc) In
> addition, Infra does well to distribute the software we actually
> produce, we'd politely decline the offer to provide a service like Nux
> has stood up. :)
>
> --David
>
> On Wed, Jun 25, 2014 at 6:36 PM, Sally Khudairi
>  wrote:
>> Cool --thanks, Lucian!
>>
>> Just so I understand, this is a supporting repository and not an "official" 
>> CloudStack project resource, correct?
>>
>> If so, totally fine: please do continue as intended. If not, I suspect this 
>> might need to reside somewhere in the cloudstack.apache.org/* home.
>>
>> I'd love feedback from the community if you're planning to give folks a peek 
>> at tomorrow's meeting!
>>
>> Cheers,
>> Sally
>>
>>
>>>
>>> From: Nux! 
>>>To: market...@cloudstack.apache.org
>>>Cc: dev@cloudstack.apache.org; us...@cloudstack.apache.org
>>>Sent: Wednesday, 25 June 2014, 15:09
>>>Subject: OpenVM.eu - repository of Cloudstack images and appliances
>>>
>>>
>>>Hi,
>>>
>>>I've been intending to do this for a while, but decided it has to happen 
>>>this summer so here goes:
>>>
>>>http://www.openvm.eu - A repository of Cloudstack images and appliances!
>>>
>>>Do not be fooled by it's current façade, it will get better.
>>>It only has one template for now, but I expect this number to increase 
>>>significantly in the coming weeks.
>>>It is just what I managed to do in a very short time at $work today and 
>>>thought it might be worth a mention at tomorrow's European meeting in London.
>>>
>>>I'll add a lot more templates, with a focus on CentOS and Cloudstack, of 
>>>course, as this is where my interests lie at the moment.
>>>In time I will add more OSes and platforms (Openstack and OpenNebula).
>>>
>>>The templates are built on/for KVM, but should be able to boot on a variety 
>>>of hypervisors (I think it will work on Xen/Xenserver, VMware, HyperV), 
>>>although the file format is QCOW2.
>>>I'll have to check my resources to see if I can afford the extra disk space 
>>>and CPU time to offer VHD/RAW files as well.
>>>
>>>All templates are 8 GB in size unless specified otherwise.
>>>
>>>I'll keep the list updated.
>>>
>>>Comments, questions, suggestions etc welcome!
>>>
>>>Lucian
>>>
>>>
>>>
>>>--
>>>Sent from the Delta quadrant using Borg technology!
>>>
>>>Nux!
>>>www.nux.ro
>>>
>>>
>>>



-- 
Daan

Re: OpenVM.eu - repository of Cloudstack images and appliances

[Nux!]

Daan,

Yup, a link will do just fine for now. 
In addition to that I'll require also the kickstart file used to build it. The 
images will have to be rebuilt regularly so we don't ship vulnerable/obsolete 
stuff.

I'll have to write some sort of FAQ on this.


Lucian

- Original Message -
> From: "Daan Hoogland" 
> To: "dev" 
> Cc: "Sally Khudairi" , 
> market...@cloudstack.apache.org, us...@cloudstack.apache.org
> Sent: Thursday, 26 June, 2014 8:05:14 AM
> Subject: Re: OpenVM.eu - repository of Cloudstack images and appliances
> 
> love it Lucian, How will the procedure for submissions look? (I'm
> thinking a mail to you with a download link)

Re: Review Request 22934: CLOUDSTACK-6984: Fixing few issues found durign simulator run

[ASF Subversion and Git Services]

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


Commit 7bc997f4fbaa80ed6335ba3658baaee5c9cb8e48 in cloudstack's branch 
refs/heads/master from Girish Shilamkar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7bc997f ]

CLOUDSTACK-6984: Re-enable the testcase


- ASF Subversion and Git Services


On June 24, 2014, 3:04 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22934/
> ---
> 
> (Updated June 24, 2014, 3:04 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-6984
> https://issues.apache.org/jira/browse/CLOUDSTACK-6984
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing issues found in simulator run.
> 
> 1. test_01_stop_vm failed on simulator because of escape sequences present in 
> the response from simulator
> 2. test_releaseIP failed due to incorrect listing of IP address. The IP 
> address which was was associated was not listed exactly (Listed by passing 
> account id and domain id which listed other IP addresses associated with the 
> account along with desired IP). The IP address which is not used for source 
> nat should get listed instead.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_network.py 0ae777e 
>   test/integration/smoke/test_vm_life_cycle.py 9ab7848 
>   tools/marvin/marvin/lib/base.py c3d98c9 
> 
> Diff: https://reviews.apache.org/r/22934/diff/
> 
> 
> Testing
> ---
> 
> yes.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?

[Meghna Kale]

Hi All,

I have been following the IAM functionality work from quite sometime.
And I am interested in this work and would like to contribute in the API
changes and discussions.
If there are any design documents or any Jira tickets related to these
changes can you please point me to them that will be helpful.

>From looking over the API changes documentation for the IAM feature I was
curious if everything you set out to accomplish that is mentioned
here https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes is
completed ?

Thanks
Meghna.



On Thu, Jun 5, 2014 at 11:03 PM, Prachi Damle 
wrote:

>
>
> -Original Message-
> From: Meghna Kale [mailto:meghna.k...@sungardas.com]
> Sent: Wednesday, June 04, 2014 11:24 PM
> To: dev
> Cc: Daan Hoogland; Hugo Trippaers
> Subject: Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?
>
> Thanks Min and Prachi.
>
> >Based on above, for your usecase, you can attach a new policy to one
> account to deny specific operations. So even if that account belongs to
> the group that allows All, the second >policy has an explicit Deny, so this
> will deny the specific operations.
>
> Does that mean that a new deny permission role should be created and then
> applied to the user? If yes then is it like we are apply two roles to a
> single user.
>
> >> Yes it means attaching two policies to the account. The policy
> evaluation logic should look at all the policies attached and evaluate
> using the precedence.
>
> Thanks
> Meghna.
>
> Thanks
> Meghna.
>
>
>
> On Thu, Jun 5, 2014 at 1:19 AM, Prachi Damle 
> wrote:
>
> > >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?
> >
> > This will be decided depending on whether Deny has higher precedence
> > over Allow or the other way. If Deny has the higher precedence, the
> > evaluation logic will be:
> > - If there is a policy attached to the account or to a group that the
> > account belongs to, which states an explicit Deny, then the permission
> > will be denied.
> >
> > Based on above, for your usecase, you can attach a new policy to one
> > account to deny specific operations. So even if that account belongs
> > to the group that allows All, the second policy has an explicit Deny,
> > so this will deny the specific operations.
> >
> > Thanks,
> > Prachi
> >
> > -Original Message-
> > From: Min Chen [mailto:min.c...@citrix.com]
> > Sent: Tuesday, June 03, 2014 9:30 AM
> > To: dev@cloudstack.apache.org
> > Cc: Daan Hoogland; Hugo Trippaers
> > Subject: 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"  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  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"  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" 
> 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 

Re: OpenVM.eu - repository of Cloudstack images and appliances

[Sebastien Goasguen]

[removing users@, marketing@ etc…]

On Jun 26, 2014, at 3:30 AM, Nux!  wrote:

> Daan,
> 
> Yup, a link will do just fine for now. 
> In addition to that I'll require also the kickstart file used to build it. 
> The images will have to be rebuilt regularly so we don't ship 
> vulnerable/obsolete stuff.
> 

Nux, it would be nice to keep all build scripts in a github repo of sorts…so 
that people can inspect how the image was built.

I know there was a packer cloudstack processor in the works, I don't think it 
got merged in packer trunk, but maybe providing all images in a packer file 
like Ian is doing would be a way to go.


> I'll have to write some sort of FAQ on this.
> 
> 
> Lucian
> 
> - Original Message -
>> From: "Daan Hoogland" 
>> To: "dev" 
>> Cc: "Sally Khudairi" , 
>> market...@cloudstack.apache.org, us...@cloudstack.apache.org
>> Sent: Thursday, 26 June, 2014 8:05:14 AM
>> Subject: Re: OpenVM.eu - repository of Cloudstack images and appliances
>> 
>> love it Lucian, How will the procedure for submissions look? (I'm
>> thinking a mail to you with a download link)

[Issue]: Cannot start virtual router

[huangchunmei]

Hi,

 

I am a CloudStack user, below issues blocked me, would you please help to
check?

For hyper-v, systemvms are running successfully. But when creating a hyper-v
VM, could not start the virtual router as following, the Link Local IP
Address is always 0.0.0.0

 



 

 

Thanks,

Chunmei

 

Re: Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage

[Abhinandan Prateek]

On 25/06/14 11:30 pm, "Daan Hoogland"  wrote:

>On Wed, Jun 25, 2014 at 7:58 PM, Santhosh Edukulla
> wrote:
>...
>> Team uses 4.4-forward marvin to test the changes.
>You should really not test 4.4-forward, but 4.4!
It is mainly about testing and fixing the Marvin framework.
Didn¹t want to interfere with the current release.

-abhi
>

RE: [Issue]: Cannot start virtual router

[Rajesh Battala]

Hi
Is the VR started successfully?
Is the systemvms(ssvm, cpvm) have got configured successfully! Were you able to 
view the console of VMs!
Share the logs why vm deployment is failing.
Am not able to see the screenshot.

Thanks
Rajesh Battala

From: huangchunmei [mailto:huangchun...@internetware.cn]
Sent: Thursday, June 26, 2014 8:18 AM
To: dev@cloudstack.apache.org
Subject: [Issue]: Cannot start virtual router

Hi,

I am a CloudStack user, below issues blocked me, would you please help to check?
For hyper-v, systemvms are running successfully. But when creating a hyper-v 
VM, could not start the virtual router as following, the Link Local IP Address 
is always 0.0.0.0

[cid:image001.jpg@01CF912A.DC92DCE0]


Thanks,
Chunmei

Review Request 23008: Reverted the hardcoding fix for "SR-Label:" and "Path:" strings

[Vetrivel Chinnasamy]

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

Review request for cloudstack, Brian Federle and Jessica Wang.


Repository: cloudstack-git


Description
---

Reverted the hard-coding fix for strings "Path:" and "SR-Name Label:".


Diffs
-

  ui/scripts/system.js 67e01f1 

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


Testing
---

No


Thanks,

Vetrivel Chinnasamy

Review Request 23009: Fix for test_portable_ip.py script issues

[sanjeev n]

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

Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.


Bugs: CS-6992
https://issues.apache.org/jira/browse/CS-6992


Repository: cloudstack-git


Description
---

1.Currently the test is not reading test data from the config file. So I have 
made changes in the script to read test data and use it in all the test methods
2.Reading portable ip config values was not proper in 
getPortableIpRangeServices in lib/common.py so made changes in the library to 
read portable ip values properly


Diffs
-

  test/integration/component/test_portable_ip.py b9c9059 
  tools/marvin/marvin/lib/common.py 7b0c7ad 

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


Testing
---

Yes


Thanks,

sanjeev n

RE: [ACS4.4] i18n problems in Add Primary Storage dialog

[Vetrivel Chinnasamy]

Hi Mike,

Kindly accept my apology for the issue. I have used script to identify certain 
pattern of hardcoded strings and fixed them. Some exceptions like this got 
escaped from my unit testing also.

I have reverted the changes as suggested and created a patch for review.

Brian/Jessica, Could you please do the needful?

Review Request #23008.

Kindly accept my apology for inconvenience caused because of this issue.

Thanks.

Regards,
Vetri

P.S: I am reviewing again the externalization code changes committed in the 
past to avoid these type of issues.

From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: 26 June 2014 03:56
To: dev@cloudstack.apache.org; Vetrivel Chinnasamy
Cc: Brian Federle; Alena Prokharchyk; Jessica Wang
Subject: Re: [ACS4.4] i18n problems in Add Primary Storage dialog

By the way, what I was referring to with my proposed hack was just to fix the 
two situations ("SR Name-Label" and "Path") by hardcoding the English back in.

On Wed, Jun 25, 2014 at 2:34 PM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>> wrote:
It looks like these issues were introduced in 
182c31899bb353eac66a43ca4e81117c4fd06332 by vetrivelc with regards to 
externalizing hardcoded strings.

My guess is that this substitution was done in an automated fashion and some 
unintended consequences of the substitution logic occurred.

vetrivelc - Any chance you could take a look at these issues and decide on a 
way for us to proceed? This is in 4.4 code (first RC currently planned for this 
Friday), so it would be awesome if we could resolve these quickly.

One hack would be for us to just hard code the English words back, but of 
course these labels would then be incorrect in other languages (unless, of 
course, by coincidence the words happened to be the same in each lang).

Thanks!


 
$form.find('.form-item[rel=path]').css('display', 'inline-block');

 var $required = 
$form.find('.form-item[rel=path]').find(".name").find("label span");

-
$form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);

+
$form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);



 
$form.find('.form-item[rel=smbUsername]').hide();

 
$form.find('.form-item[rel=smbPassword]').hide();

@@ -15414,7 +15414,7 @@



 
$form.find('.form-item[rel=path]').css('display', 'inline-block');

 var $required = 
$form.find('.form-item[rel=path]').find(".name").find("label span");

-
$form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);

+
$form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);



 
$form.find('.form-item[rel=smbUsername]').css('display', 'inline-block');

 
$form.find('.form-item[rel=smbPassword]').css('display', 'inline-block');

@@ -15441,7 +15441,7 @@



 
$form.find('.form-item[rel=path]').css('display', 'inline-block');

 var $required = 
$form.find('.form-item[rel=path]').find(".name").find("label span");

-
$form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);

+
$form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);



 
$form.find('.form-item[rel=smbUsername]').hide();

 
$form.find('.form-item[rel=smbPassword]').hide();

@@ -15467,7 +15467,7 @@



 
$form.find('.form-item[rel=path]').css('display', 'inline-block');

 var $required = 
$form.find('.form-item[rel=path]').find(".name").find("label span");

-
$form.find('.form-item[rel=path]').find(".name").find("label").text("SR 
Name-Label:").prepend($required);

+
$form.find('.form-item[rel=path]').find(".name").find("label").text('label.SR.name'+":").prepend($required);

Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?

[Daan Hoogland]

Megha, the page you mention is a collection bin for all things planned
that are going to require a major version upgrade as they change the
application programming interface.

It is not just for the IAM extensions planned.

It is completed only when 5.0 is out ;) Feel free to add to it or to
propose implementing parts of it.

regards

On Thu, Jun 26, 2014 at 12:02 PM, Meghna Kale  wrote:
> Hi All,
>
> I have been following the IAM functionality work from quite sometime.
> And I am interested in this work and would like to contribute in the API
> changes and discussions.
> If there are any design documents or any Jira tickets related to these
> changes can you please point me to them that will be helpful.
>
> From looking over the API changes documentation for the IAM feature I was
> curious if everything you set out to accomplish that is mentioned
> here https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes is
> completed ?
>
> Thanks
> Meghna.
>
>
>
> On Thu, Jun 5, 2014 at 11:03 PM, Prachi Damle 
> wrote:
>>
>>
>>
>> -Original Message-
>> From: Meghna Kale [mailto:meghna.k...@sungardas.com]
>> Sent: Wednesday, June 04, 2014 11:24 PM
>> To: dev
>> Cc: Daan Hoogland; Hugo Trippaers
>> Subject: Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?
>>
>> Thanks Min and Prachi.
>>
>> >Based on above, for your usecase, you can attach a new policy to one
>> account to deny specific operations. So even if that account belongs to
>> the group that allows All, the second >policy has an explicit Deny, so this
>> will deny the specific operations.
>>
>> Does that mean that a new deny permission role should be created and then
>> applied to the user? If yes then is it like we are apply two roles to a
>> single user.
>>
>> >> Yes it means attaching two policies to the account. The policy
>> >> evaluation logic should look at all the policies attached and evaluate 
>> >> using
>> >> the precedence.
>>
>> Thanks
>> Meghna.
>>
>> Thanks
>> Meghna.
>>
>>
>>
>> On Thu, Jun 5, 2014 at 1:19 AM, Prachi Damle 
>> wrote:
>>
>> > >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?
>> >
>> > This will be decided depending on whether Deny has higher precedence
>> > over Allow or the other way. If Deny has the higher precedence, the
>> > evaluation logic will be:
>> > - If there is a policy attached to the account or to a group that the
>> > account belongs to, which states an explicit Deny, then the permission
>> > will be denied.
>> >
>> > Based on above, for your usecase, you can attach a new policy to one
>> > account to deny specific operations. So even if that account belongs
>> > to the group that allows All, the second policy has an explicit Deny,
>> > so this will deny the specific operations.
>> >
>> > Thanks,
>> > Prachi
>> >
>> > -Original Message-
>> > From: Min Chen [mailto:min.c...@citrix.com]
>> > Sent: Tuesday, June 03, 2014 9:30 AM
>> > To: dev@cloudstack.apache.org
>> > Cc: Daan Hoogland; Hugo Trippaers
>> > Subject: 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"  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  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"  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" 

Re: Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage

[Daan Hoogland]

if it is test code it will hardly interfere with the release, If it
does it is extra important to know about it early. The only reason to
not put them in the 4.4 branch is because you don't want them in the
4.4.0 release.

On Thu, Jun 26, 2014 at 1:33 PM, Abhinandan Prateek
 wrote:
>
>
> On 25/06/14 11:30 pm, "Daan Hoogland"  wrote:
>
>>On Wed, Jun 25, 2014 at 7:58 PM, Santhosh Edukulla
>> wrote:
>>...
>>> Team uses 4.4-forward marvin to test the changes.
>>You should really not test 4.4-forward, but 4.4!
> It is mainly about testing and fixing the Marvin framework.
> Didn¹t want to interfere with the current release.
>
> -abhi
>>
>



-- 
Daan

Re: Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage

[Leo Simons]

+1! I’ve been slowly trying to figure out which part of the public marvin
test infrastructure we can run against our test infrastructure (and then,
later on, add our own tests to the public set…).

Having some kind of a defined set of “these tests belong with and pass
against 4.4.0 (in the citrix QA environment)” would be a _huge_ help.

Cheers,

Leo

On 6/26/14, 3:21 PM, "Daan Hoogland"  wrote:

>if it is test code it will hardly interfere with the release, If it
>does it is extra important to know about it early. The only reason to
>not put them in the 4.4 branch is because you don't want them in the
>4.4.0 release.
>
>On Thu, Jun 26, 2014 at 1:33 PM, Abhinandan Prateek
> wrote:
>>
>>
>> On 25/06/14 11:30 pm, "Daan Hoogland"  wrote:
>>
>>>On Wed, Jun 25, 2014 at 7:58 PM, Santhosh Edukulla
>>> wrote:
>>>...
 Team uses 4.4-forward marvin to test the changes.
>>>You should really not test 4.4-forward, but 4.4!
>> It is mainly about testing and fixing the Marvin framework.
>> Didn¹t want to interfere with the current release.
>>
>> -abhi
>>>
>>
>
>
>
>-- 
>Daan

Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?

[Meghna Kale]

Thanks Daan.

With completion I meant the documentation part.




On Thu, Jun 26, 2014 at 6:49 PM, Daan Hoogland 
wrote:

> Megha, the page you mention is a collection bin for all things planned
> that are going to require a major version upgrade as they change the
> application programming interface.
>
> It is not just for the IAM extensions planned.
>
> It is completed only when 5.0 is out ;) Feel free to add to it or to
> propose implementing parts of it.
>
> regards
>
> On Thu, Jun 26, 2014 at 12:02 PM, Meghna Kale 
> wrote:
> > Hi All,
> >
> > I have been following the IAM functionality work from quite sometime.
> > And I am interested in this work and would like to contribute in the API
> > changes and discussions.
> > If there are any design documents or any Jira tickets related to these
> > changes can you please point me to them that will be helpful.
> >
> > From looking over the API changes documentation for the IAM feature I was
> > curious if everything you set out to accomplish that is mentioned
> > here https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes
> is
> > completed ?
> >
> > Thanks
> > Meghna.
> >
> >
> >
> > On Thu, Jun 5, 2014 at 11:03 PM, Prachi Damle 
> > wrote:
> >>
> >>
> >>
> >> -Original Message-
> >> From: Meghna Kale [mailto:meghna.k...@sungardas.com]
> >> Sent: Wednesday, June 04, 2014 11:24 PM
> >> To: dev
> >> Cc: Daan Hoogland; Hugo Trippaers
> >> Subject: Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?
> >>
> >> Thanks Min and Prachi.
> >>
> >> >Based on above, for your usecase, you can attach a new policy to one
> >> account to deny specific operations. So even if that account belongs to
> >> the group that allows All, the second >policy has an explicit Deny, so
> this
> >> will deny the specific operations.
> >>
> >> Does that mean that a new deny permission role should be created and
> then
> >> applied to the user? If yes then is it like we are apply two roles to a
> >> single user.
> >>
> >> >> Yes it means attaching two policies to the account. The policy
> >> >> evaluation logic should look at all the policies attached and
> evaluate using
> >> >> the precedence.
> >>
> >> Thanks
> >> Meghna.
> >>
> >> Thanks
> >> Meghna.
> >>
> >>
> >>
> >> On Thu, Jun 5, 2014 at 1:19 AM, Prachi Damle 
> >> wrote:
> >>
> >> > >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?
> >> >
> >> > This will be decided depending on whether Deny has higher precedence
> >> > over Allow or the other way. If Deny has the higher precedence, the
> >> > evaluation logic will be:
> >> > - If there is a policy attached to the account or to a group that the
> >> > account belongs to, which states an explicit Deny, then the permission
> >> > will be denied.
> >> >
> >> > Based on above, for your usecase, you can attach a new policy to one
> >> > account to deny specific operations. So even if that account belongs
> >> > to the group that allows All, the second policy has an explicit Deny,
> >> > so this will deny the specific operations.
> >> >
> >> > Thanks,
> >> > Prachi
> >> >
> >> > -Original Message-
> >> > From: Min Chen [mailto:min.c...@citrix.com]
> >> > Sent: Tuesday, June 03, 2014 9:30 AM
> >> > To: dev@cloudstack.apache.org
> >> > Cc: Daan Hoogland; Hugo Trippaers
> >> > Subject: 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"  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 
> 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"  wrote:
> >> > >>
> >> > >> >Tha

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

[Silvano Nogueira Buback]

Thank you David.

I put design documents on wiki:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+and+PowerDNS+integration+by+Globo+DNSAPI.
I create an issue https://issues.apache.org/jira/browse/CLOUDSTACK-6998 too.

I look forward to hearing your feedbacks.

[]'s,

Silvano Buback


On Wed, Jun 25, 2014 at 5:50 PM, David Nalley  wrote:

> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
>  wrote:
> > Hi guys,
> >
> >I finish the first version of design document:
> >
> https://docs.google.com/document/d/1kbPQJrBC87ZtR-t7LwHFDzAmT436ShtjwKE84FVfByM/pub
> > .
> >
> >Someone could give me access to put design documents in wiki? Bellow
> the
> > username of people work with Cloudstack in Globo.com and need access.
> >
> > snbuback silv...@corp.globo.com
> > daniel.simoes daniel.sim...@corp.globo.com
> > lokama - lok...@gmail.com
> >
> > Regards,
> >
> > Silvano Buback
> >
> >
> >
> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback 
> wrote:
> >
> >> Of course, I forgotten my account info:
> >> snbuback / silv...@corp.globo.com
> >>
>
>
> Done.
>
> --David
>

Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[Alex Ough]

Kishan,

The type of region id is Integer, not Long, so I'm wondering why it
should be Long.

Alex Ough



On Thu, Jun 26, 2014 at 2:08 AM, Kishan Kavala 
wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20099/
>
> Alex,
>  As discussed on the mailing list, ORIGINATEDREGIONUUID should be the 
> regionId which is Long. So all the ORIGINATEDREGIONUUID references should 
> just be ORIGINATEDREGIONID and of datatype Long.
>
>
> - Kishan Kavala
>
> On June 24th, 2014, 9:24 p.m. IST, Alex Ough wrote:
>   Review request for cloudstack.
> By Alex Ough.
>
> *Updated June 24, 2014, 9:24 p.m.*
>  *Repository: * cloudstack-git
> Description
>
> This is the review request for the core changes related with #17790 that has 
> only the new plugin codes.
>
>   Testing
>
> 1. Successfully tested real time synchronization as soon as resources are 
> created/deleted/modified in one region.
> 2. Successfully tested full scans to synchronize resources that were missed 
> during real time synchronization because of any reasons like network 
> connection issues.
> 3. The tests were done manually and also automatically by randomly generating 
> changes each region.
>
>   Diffs
>
>- api/src/com/cloud/event/EventTypes.java (0fa3cd5)
>- api/src/com/cloud/user/AccountService.java (eac8a76)
>- api/src/com/cloud/user/DomainService.java (4c1f93d)
>- api/src/org/apache/cloudstack/api/ApiConstants.java (adda5f4)
>- api/src/org/apache/cloudstack/api/BaseCmd.java (ac9a208)
>- 
> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccountCmd.java
>(50d67d9)
>- 
> api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccountCmd.java
>(5754ec5)
>- 
> api/src/org/apache/cloudstack/api/command/admin/account/DisableAccountCmd.java
>(3e5e1d3)
>- 
> api/src/org/apache/cloudstack/api/command/admin/account/EnableAccountCmd.java
>(f30c985)
>- 
> api/src/org/apache/cloudstack/api/command/admin/account/LockAccountCmd.java
>(3c185e4)
>- 
> api/src/org/apache/cloudstack/api/command/admin/account/UpdateAccountCmd.java
>(a7ce74a)
>- 
> api/src/org/apache/cloudstack/api/command/admin/domain/CreateDomainCmd.java
>(312c9ee)
>- 
> api/src/org/apache/cloudstack/api/command/admin/domain/DeleteDomainCmd.java
>(a6d2b0b)
>- 
> api/src/org/apache/cloudstack/api/command/admin/domain/UpdateDomainCmd.java
>(409a84d)
>- api/src/org/apache/cloudstack/api/command/admin/region/AddRegionCmd.java
>(f6743ba)
>- 
> api/src/org/apache/cloudstack/api/command/admin/region/UpdateRegionCmd.java
>(b08cbbb)
>- api/src/org/apache/cloudstack/api/command/admin/user/CreateUserCmd.java
>(8f223ac)
>- api/src/org/apache/cloudstack/api/command/admin/user/DeleteUserCmd.java
>(08ba521)
>- api/src/org/apache/cloudstack/api/command/admin/user/DisableUserCmd.java
>(c6e09ef)
>- api/src/org/apache/cloudstack/api/command/admin/user/EnableUserCmd.java
>(d69eccf)
>- api/src/org/apache/cloudstack/api/command/admin/user/LockUserCmd.java
>(69623d0)
>- api/src/org/apache/cloudstack/api/command/admin/user/RegisterCmd.java
>(2090d21)
>- api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java
>(f21e264)
>- api/src/org/apache/cloudstack/api/response/RegionResponse.java
>(6c74fa6)
>- api/src/org/apache/cloudstack/region/Region.java (df64e44)
>- api/src/org/apache/cloudstack/region/RegionService.java (afefcc7)
>- api/test/org/apache/cloudstack/api/command/test/RegionCmdTest.java
>(10c3d85)
>- client/pom.xml (29fef4f)
>- 
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
>(2ef0d20)
>- engine/schema/src/com/cloud/user/AccountVO.java (0f5a044)
>- engine/schema/src/org/apache/cloudstack/region/RegionVO.java
>(608bd2b)
>- 
> plugins/network-elements/juniper-contrail/test/org/apache/cloudstack/network/contrail/management/MockAccountManager.java
>(4136b5c)
>- plugins/pom.xml (b5e6a61)
>- 
> plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LdapCreateAccountCmd.java
>(b753952)
>- 
> plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LdapImportUsersCmd.java
>(6f7be90)
>- server/src/com/cloud/api/ApiResponseHelper.java (f1f0d2c)
>- server/src/com/cloud/api/dispatch/ParamProcessWorker.java (1592b93)
>- server/src/com/cloud/event/ActionEventUtils.java (2b3cfea)
>- server/src/com/cloud/projects/ProjectManagerImpl.java (d10c059)
>- server/src/com/cloud/user/AccountManager.java (194c5d2)
>- server/src/com/cloud/user/AccountManagerImpl.java (7a889f1)
>- server/src/com/cloud/user/DomainManager.java (f72b18a)
>- server/src/com/cloud/user/DomainManagerImpl.java (fbbe0c2)
>- server/src/org/apache/cloudstack/region/RegionManager.java (6f25481)
>- server/src/org/apache/cloudstack/region/Re

Re: [ACS4.4] i18n problems in Add Primary Storage dialog

[Mike Tutkowski]

Hi Vetri,

No problem! It happens to all of us. :)

I appreciate your efforts in making these files more i18n friendly.

Thanks for fixing the issue so quickly. That helps a lot!

Talk to you later,
Mike


On Thu, Jun 26, 2014 at 6:06 AM, Vetrivel Chinnasamy <
vetrivel.chinnas...@citrix.com> wrote:

>  Hi Mike,
>
>
>
> Kindly accept my apology for the issue. I have used script to identify
> certain pattern of hardcoded strings and fixed them. Some exceptions like
> this got escaped from my unit testing also.
>
>
>
> I have reverted the changes as suggested and created a patch for review.
>
>
>
> Brian/Jessica, Could you please do the needful?
>
>
>
> Review Request #23008 .
>
>
>
> Kindly accept my apology for inconvenience caused because of this issue.
>
>
>
> Thanks.
>
>
> Regards,
>
> Vetri
>
>
>
> P.S: I am reviewing again the externalization code changes committed in
> the past to avoid these type of issues.
>
>
>
> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> *Sent:* 26 June 2014 03:56
> *To:* dev@cloudstack.apache.org; Vetrivel Chinnasamy
> *Cc:* Brian Federle; Alena Prokharchyk; Jessica Wang
> *Subject:* Re: [ACS4.4] i18n problems in Add Primary Storage dialog
>
>
>
> By the way, what I was referring to with my proposed hack was just to fix
> the two situations ("SR Name-Label" and "Path") by hardcoding the English
> back in.
>
>
>
> On Wed, Jun 25, 2014 at 2:34 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>  It looks like these issues were introduced in
> 182c31899bb353eac66a43ca4e81117c4fd06332 by vetrivelc with regards to
> externalizing hardcoded strings.
>
>
>
> My guess is that this substitution was done in an automated fashion and
> some unintended consequences of the substitution logic occurred.
>
>
>
> vetrivelc - Any chance you could take a look at these issues and decide on
> a way for us to proceed? This is in 4.4 code (first RC currently planned
> for this Friday), so it would be awesome if we could resolve these quickly.
>
>
>
> One hack would be for us to just hard code the English words back, but of
> course these labels would then be incorrect in other languages (unless, of
> course, by coincidence the words happened to be the same in each lang).
>
>
>
> Thanks!
>
>
>
>
>  $form.find('.form-item[rel=path]').css('display', 'inline-block');
>
>  var $required =
> $form.find('.form-item[rel=path]').find(".name").find("label span");
>
> -
> $form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);
>
> +
> $form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);
>
>
>
>
> $form.find('.form-item[rel=smbUsername]').hide();
>
>
> $form.find('.form-item[rel=smbPassword]').hide();
>
> @@ -15414,7 +15414,7 @@
>
>
>
>
> $form.find('.form-item[rel=path]').css('display', 'inline-block');
>
>  var $required =
> $form.find('.form-item[rel=path]').find(".name").find("label span");
>
> -
> $form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);
>
> +
> $form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);
>
>
>
>
> $form.find('.form-item[rel=smbUsername]').css('display', 'inline-block');
>
>
> $form.find('.form-item[rel=smbPassword]').css('display', 'inline-block');
>
> @@ -15441,7 +15441,7 @@
>
>
>
>
> $form.find('.form-item[rel=path]').css('display', 'inline-block');
>
>  var $required =
> $form.find('.form-item[rel=path]').find(".name").find("label span");
>
> -
> $form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);
>
> +
> $form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);
>
>
>
>
> $form.find('.form-item[rel=smbUsername]').hide();
>
>
> $form.find('.form-item[rel=smbPassword]').hide();
>
> @@ -15467,7 +15467,7 @@
>
>
>
>
> $form.find('.form-item[rel=path]').css('display', 'inline-block');
>
>  var $required =
> $form.find('.form-item[rel=path]').find(".name").find("label span");
>
> -
> $form.find('.form-item[rel=path]').find(".name").find("label").text("SR
> Name-Label:").prepend($required);
>
> +
> $form.find('.form-item[rel=path]').find(".name").find("label").text('
> label.SR.name'+":").prepend($required);
>
>
>
>
> $form.find('.form-item[rel=smbUsername]').hide();
>
>
> $form.find('.form-item[rel=smbPassword]').hide();
>
> @@ -15566,7 +15566,7 @@
>
>
>
>
> $form.find('.form-item[rel=path]').css('display', 'inline-block');
>
>  var $required =
> $form.find('.form-item[rel=path]').find(".name").find("label span");
>
> -
> $form.find('.form-item[rel=path]').find(".name").find("label").text("P

Re: Review Request 23008: Reverted the hardcoding fix for "SR-Label:" and "Path:" strings

[Mike Tutkowski]

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


This line looks incorrect to me:

-
$form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);
+
$form.find('.form-item[rel=path]').find(".name").find("label").text("SR 
Name-Label:").prepend($required);

I think the replaced text should be "Path:".

- Mike Tutkowski


On June 26, 2014, 11:52 a.m., Vetrivel Chinnasamy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23008/
> ---
> 
> (Updated June 26, 2014, 11:52 a.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Reverted the hard-coding fix for strings "Path:" and "SR-Name Label:".
> 
> 
> Diffs
> -
> 
>   ui/scripts/system.js 67e01f1 
> 
> Diff: https://reviews.apache.org/r/23008/diff/
> 
> 
> Testing
> ---
> 
> No
> 
> 
> Thanks,
> 
> Vetrivel Chinnasamy
> 
>

Re: Review Request 23008: Reverted the hardcoding fix for "SR-Label:" and "Path:" strings

[Mike Tutkowski]

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

Ship it!


Due to time constraints with regards to RC1 of 4.4 (tentatively planned for 
tomorrow), I went ahead and modified the patch per my previous comment and 
committed it to 4.4-forward:

9c2e6f5ed45522ff68131556028f3fb4ff91ee90

- Mike Tutkowski


On June 26, 2014, 11:52 a.m., Vetrivel Chinnasamy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23008/
> ---
> 
> (Updated June 26, 2014, 11:52 a.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Reverted the hard-coding fix for strings "Path:" and "SR-Name Label:".
> 
> 
> Diffs
> -
> 
>   ui/scripts/system.js 67e01f1 
> 
> Diff: https://reviews.apache.org/r/23008/diff/
> 
> 
> Testing
> ---
> 
> No
> 
> 
> Thanks,
> 
> Vetrivel Chinnasamy
> 
>

[ACS4.4] Please cherry-pick 9c2e6f5ed45522ff68131556028f3fb4ff91ee90

[Mike Tutkowski]

Hi Daan,

Please cherry pick 9c2e6f5ed45522ff68131556028f3fb4ff91ee90.

This is the i18n issue I referred to yesterday that was in the Add Primary
Storage window.

Thanks!

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

Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[Alena Prokharchyk]

Alex,

By “huge” I’ve meant that there was a lot of repetitive hardcoded things, lot 
of unnecessary changes to the CS orchestration layer. If you compare a number 
of changes now and originally, you can see that it reduced almost twice.

But lets discuss the complains about lack of initial review as its more 
important question.

Review of the design spec should happen before you start designing/coding. As I 
jumped on review much later, after you’ve submitted the entire plugin code, so 
I I didn’t participate in “Feature Request” discussion review that might have 
happened earlier. And I do assume that the reviews/emails exchanges were done 
at that initial phase? You should have contacted the people participating in 
the initial phase, and ask them for the review as well.

As a part of my review, I’ve made sure to cover the things I’m certain should 
have been changed. I’ve reviewed the feature logic as well, consulting the FS 
you’ve written. I’m not saying that there is anything wrong with your initial 
design, but asking for a second opinion from the guys who have more expertise 
in Regions.

Kishan, please help to do the final review the Alex’s plugin design 
https://reviews.apache.org/r/17790

Thank you,
Alena.
From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Wednesday, June 25, 2014 at 9:03 PM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Kishan Kavala mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Murali Reddy 
mailto:murali.re...@citrix.com>>, Ram Ganesh 
mailto:ram.gan...@citrix.com>>, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple 
Regions (Core Changes)

Alena,

I understand that you have been helping a lot to make my codes to match the 
coding standards, but I'm not sure what you mean by "the code base was 
unnecessary huge".
The initial implementation was to support the synchronization inside the CS 
because this feature is missing in the current multiple region support, and 
most of jobs were  to separate the implementation from the CS because you guys 
wanted me to provide it as a plugin.

And I kept asking reviews for the design spec from when I published the 
documents with initial prototype, it took a while for you to start to review my 
implementation and they have been mostly about the coding standards instead of 
the logic itself. So I'm saying that it would have been better if there has 
been someone to review the design spec and the prototype from the initial phase.

Again, I really appreciate your help to come this far, but it was also very 
painful for me.
Thanks
Alex Ough


On Wed, Jun 25, 2014 at 10:41 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Alex,

In the beginning the code was not very well organazied, didn't match coding 
standarts (no use of spring, misleading names, not segregated to its own 
plugin), and the code base was unneccessary huge.
All of the above it very hard to review and understand the code logic from the 
beginning and engage more people to the review. Therefore Chiradeep pointed it 
in his original review that the code needs to match CS standarts first, and be 
better organized. I helped to review the fixes, and did logic review as well 
after the code came into “reviewable” shape.

I'm asking Kishan/Murali to look at it to see if anything is missing or 
incorrect in the final review, not to make you override or change everything 
you've already put in.

Thank you,
Alena.

From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Wednesday, June 25, 2014 at 7:12 PM

To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Kishan Kavala mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Murali Reddy 
mailto:murali.re...@citrix.com>>, Ram Ganesh 
mailto:ram.gan...@citrix.com>>, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple 
Regions (Core Changes)

Alena,

Don't get me wrong. What I'm saying is that it would have been better if you 
asked the review to whomever you thought was important when you started the 
review.

Thanks
Alex Ough


On Wed, Jun 25, 2014 at 9:45 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Alex,

I did my best to review the code, made sure it came in shape with the CS 
guidelines and java code style There was no way to anticipate all the things to 
fix originally, as every subsequent review update added more things to fix as 
the review code was new/refactored.

And I don’t see anything wrong about asking for a FINAL opinion from other 
people on the mailing list, considering some of them participated in the review 
process along the way already (Kishan). Anybody can review the review ticket 
till its closed, and po

Re: [ACS4.4] Please cherry-pick 9c2e6f5ed45522ff68131556028f3fb4ff91ee90

[Daan Hoogland]

On Thu, Jun 26, 2014 at 6:53 PM, Mike Tutkowski
 wrote:
> 9c2e6f5ed45522ff68131556028f3fb4ff91ee90


is in

-- 
Daan

Cloudstack MS failover

[Tejas Gadaria]

I want to setup HA of MS with HAproxy OR Keepalived.

I have MS1 & DB1 installed on 10.1.1.2  &
MS2 & DB2 installed on 10.1.1.3

also DB has master - master replication setup.

Need help on this how can i setup failover for MS.

Regards,
Tejas

RE: [ACS4.4] i18n problems in Add Primary Storage dialog

[Jessica Wang]

Vetrivel,
Mike has reviewed it.

Mike,
thanks a lot!

Jessica

From: Vetrivel Chinnasamy
Sent: Thursday, June 26, 2014 5:07 AM
To: Mike Tutkowski; dev@cloudstack.apache.org
Cc: Brian Federle; Alena Prokharchyk; Jessica Wang
Subject: RE: [ACS4.4] i18n problems in Add Primary Storage dialog

Hi Mike,

Kindly accept my apology for the issue. I have used script to identify certain 
pattern of hardcoded strings and fixed them. Some exceptions like this got 
escaped from my unit testing also.

I have reverted the changes as suggested and created a patch for review.

Brian/Jessica, Could you please do the needful?

Review Request #23008.

Kindly accept my apology for inconvenience caused because of this issue.

Thanks.

Regards,
Vetri

P.S: I am reviewing again the externalization code changes committed in the 
past to avoid these type of issues.

From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: 26 June 2014 03:56
To: dev@cloudstack.apache.org; Vetrivel Chinnasamy
Cc: Brian Federle; Alena Prokharchyk; Jessica Wang
Subject: Re: [ACS4.4] i18n problems in Add Primary Storage dialog

By the way, what I was referring to with my proposed hack was just to fix the 
two situations ("SR Name-Label" and "Path") by hardcoding the English back in.

On Wed, Jun 25, 2014 at 2:34 PM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>> wrote:
It looks like these issues were introduced in 
182c31899bb353eac66a43ca4e81117c4fd06332 by vetrivelc with regards to 
externalizing hardcoded strings.

My guess is that this substitution was done in an automated fashion and some 
unintended consequences of the substitution logic occurred.

vetrivelc - Any chance you could take a look at these issues and decide on a 
way for us to proceed? This is in 4.4 code (first RC currently planned for this 
Friday), so it would be awesome if we could resolve these quickly.

One hack would be for us to just hard code the English words back, but of 
course these labels would then be incorrect in other languages (unless, of 
course, by coincidence the words happened to be the same in each lang).

Thanks!


 
$form.find('.form-item[rel=path]').css('display', 'inline-block');

 var $required = 
$form.find('.form-item[rel=path]').find(".name").find("label span");

-
$form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);

+
$form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);



 
$form.find('.form-item[rel=smbUsername]').hide();

 
$form.find('.form-item[rel=smbPassword]').hide();

@@ -15414,7 +15414,7 @@



 
$form.find('.form-item[rel=path]').css('display', 'inline-block');

 var $required = 
$form.find('.form-item[rel=path]').find(".name").find("label span");

-
$form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);

+
$form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);



 
$form.find('.form-item[rel=smbUsername]').css('display', 'inline-block');

 
$form.find('.form-item[rel=smbPassword]').css('display', 'inline-block');

@@ -15441,7 +15441,7 @@



 
$form.find('.form-item[rel=path]').css('display', 'inline-block');

 var $required = 
$form.find('.form-item[rel=path]').find(".name").find("label span");

-
$form.find('.form-item[rel=path]').find(".name").find("label").text("Path:").prepend($required);

+
$form.find('.form-item[rel=path]').find(".name").find("label").text('label.path'+":").prepend($required);



 
$form.find('.form-item[rel=smbUsername]').hide();

 
$form.find('.form-item[rel=smbPassword]').hide();

@@ -15467,7 +15467,7 @@



 
$form.find('.form-item[rel=path]').css('display', 'inline-block');

 var $required = 
$form.find('.form-item[rel=path]').find(".name").find("label span");

-
$form.find('.form-item[rel=path]').find(".nam

Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[Alex Ough]

Alena,

It has been reduced almost twice because a lot has been separated from the
CS and moved to the plug-in not because they are 'unnecessary'. Please
remember that my initial implementation was inside the CS not as a plug-in
as I said in the previous email.

Of course, I asked and urged the review repeatedly and you'll see the all
the histories of them if you find emails using this subject, which started
10/17/13.
[DISCUSS] Domain-Account-User Sync Up Among Multiple Regions
Even if I asked so many times, unfortunately, I couldn't get an actual
feedback until Daan finally asked Chiradeep and you to review them, which
is 3/10/14.

Kishan,
I posted 2 questions, so please guide me for the questions.

Thanks
Alex Ough



On Thu, Jun 26, 2014 at 12:57 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>  Alex,
>
>  By “huge” I’ve meant that there was a lot of repetitive hardcoded
> things, lot of unnecessary changes to the CS orchestration layer. If you
> compare a number of changes now and originally, you can see that it reduced
> almost twice.
>
>  But lets discuss the complains about lack of initial review as its more
> important question.
>
>  Review of the design spec should happen before you start
> designing/coding. As I jumped on review much later, after you’ve submitted
> the entire plugin code, so I I didn’t participate in “Feature Request”
> discussion review that might have happened earlier. And I do assume that
> the reviews/emails exchanges were done at that initial phase? You should
> have contacted the people participating in the initial phase, and ask them
> for the review as well.
>
>  As a part of my review, I’ve made sure to cover the things I’m certain
> should have been changed. I’ve reviewed the feature logic as well,
> consulting the FS you’ve written. I’m not saying that there is anything
> wrong with your initial design, but asking for a second opinion from the
> guys who have more expertise in Regions.
>
>  Kishan, please help to do the final review the Alex’s plugin design
> https://reviews.apache.org/r/17790
>
>  Thank you,
> Alena.
>  From: Alex Ough 
> Date: Wednesday, June 25, 2014 at 9:03 PM
>
> To: Alena Prokharchyk 
> Cc: Kishan Kavala , "dev@cloudstack.apache.org"
> , Murali Reddy , Ram
> Ganesh , Animesh Chaturvedi <
> animesh.chaturv...@citrix.com>
> Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among
> Multiple Regions (Core Changes)
>
>   Alena,
>
>  I understand that you have been helping a lot to make my codes to match
> the coding standards, but I'm not sure what you mean by "the code base was
> unnecessary huge".
> The initial implementation was to support the synchronization inside the
> CS because this feature is missing in the current multiple region support,
> and most of jobs were  to separate the implementation from the CS because
> you guys wanted me to provide it as a plugin.
>
>  And I kept asking reviews for the design spec from when I published the
> documents with initial prototype, it took a while for you to start to
> review my implementation and they have been mostly about the coding
> standards instead of the logic itself. So I'm saying that it would have
> been better if there has been someone to review the design spec and the
> prototype from the initial phase.
>
>  Again, I really appreciate your help to come this far, but it was also
> very painful for me.
> Thanks
> Alex Ough
>
>
> On Wed, Jun 25, 2014 at 10:41 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>>  Alex,
>>
>>  In the beginning the code was not very well organazied, didn't match
>> coding standarts (no use of spring, misleading names, not segregated to its
>> own plugin), and the code base was unneccessary huge.
>> All of the above it very hard to review and understand the code logic
>> from the beginning and engage more people to the review. Therefore
>> Chiradeep pointed it in his original review that the code needs to match CS
>> standarts first, and be better organized. I helped to review the fixes, and
>> did logic review as well after the code came into “reviewable” shape.
>>
>>  I'm asking Kishan/Murali to look at it to see if anything is missing or
>> incorrect in the final review, not to make you override or change
>> everything you've already put in.
>>
>>  Thank you,
>> Alena.
>>
>>   From: Alex Ough 
>> Date: Wednesday, June 25, 2014 at 7:12 PM
>>
>> To: Alena Prokharchyk 
>> Cc: Kishan Kavala , "dev@cloudstack.apache.org"
>> , Murali Reddy , Ram
>> Ganesh , Animesh Chaturvedi <
>> animesh.chaturv...@citrix.com>
>> Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among
>> Multiple Regions (Core Changes)
>>
>>   Alena,
>>
>>  Don't get me wrong. What I'm saying is that it would have been better
>> if you asked the review to whomever you thought was important when you
>> started the review.
>>
>>  Thanks
>> Alex Ough
>>
>>
>> On Wed, Jun 25, 2014 at 9:45 PM, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wr

Re: Review Request 22019: CLOUDSTACK-6732: [OVS][UI] Network Service Providers page displays two ovs providers

[ASF Subversion and Git Services]

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


Commit 6d5d48f460438c7df43e3d0e3da9bd91866c53d5 in cloudstack's branch 
refs/heads/4.4-forward from Gabor Apati-Nagy
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6d5d48f ]

CLOUDSTACK-6732: Fix:[OVS][UI] Network Service Providers page displays two ovs 
providers


- ASF Subversion and Git Services


On May 29, 2014, 2:16 p.m., Gabor Apati-Nagy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22019/
> ---
> 
> (Updated May 29, 2014, 2:16 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Bugs: CLOUDSTACK-6732
> https://issues.apache.org/jira/browse/CLOUDSTACK-6732
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed: CLOUDSTACK-6732: [OVS][UI] Network Service Providers page displays two 
> ovs providers
> 
> 
> Diffs
> -
> 
>   ui/scripts/system.js 67e01f1 
> 
> Diff: https://reviews.apache.org/r/22019/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabor Apati-Nagy
> 
>

Re: Review Request 22019: CLOUDSTACK-6732: [OVS][UI] Network Service Providers page displays two ovs providers

[ASF Subversion and Git Services]

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


Commit 5c36fe84b69441714c2577b40b42afaf8f65a1ce in cloudstack's branch 
refs/heads/master from Gabor Apati-Nagy
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5c36fe8 ]

CLOUDSTACK-6732: Fix:[OVS][UI] Network Service Providers page displays two ovs 
providers


- ASF Subversion and Git Services


On May 29, 2014, 2:16 p.m., Gabor Apati-Nagy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22019/
> ---
> 
> (Updated May 29, 2014, 2:16 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Bugs: CLOUDSTACK-6732
> https://issues.apache.org/jira/browse/CLOUDSTACK-6732
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed: CLOUDSTACK-6732: [OVS][UI] Network Service Providers page displays two 
> ovs providers
> 
> 
> Diffs
> -
> 
>   ui/scripts/system.js 67e01f1 
> 
> Diff: https://reviews.apache.org/r/22019/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabor Apati-Nagy
> 
>

Re: NetworkOrchestrator selects 2 NetworkGurus at one time....

[Chiradeep Vittal]

For 4.3/4.4, I’m guessing this is the same solution.

For 4.5, here’s a couple of options we could implement:

  1.  New isolation provider (“BrocadeVLAN” or “JuniperEXVLAN”)
  2.  When creating the network offering, the administrator gets to select the 
guru
  3.  New VLAN provider mechanism.

From: Pradeep Cloudstack 
mailto:pradeepcloudst...@yahoo.com>>
Reply-To: Pradeep Cloudstack 
mailto:pradeepcloudst...@yahoo.com>>
Date: Wednesday, June 25, 2014 at 3:06 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>
Cc: Sheng Yang mailto:sheng.y...@citrix.com>>, Jayapal 
Reddy Uradi 
mailto:jayapalreddy.ur...@citrix.com>>, Alena 
Prokharchyk mailto:alena.prokharc...@citrix.com>>
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

We have a use-case where we will patch an existing 4.3 installation with our 
plugin.
We are facing the same issue .
In 4.2, we used to disable the entry for ExternalNetworkGuru in
componentContext.xml as part of installing the patch.

How do we do this in 4.3 (on an existing installation) ?

-Pradeep


From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>; Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>
Cc: Sheng Yang mailto:sheng.y...@citrix.com>>; Jayapal 
Reddy Uradi 
mailto:jayapalreddy.ur...@citrix.com>>; Alena 
Prokharchyk mailto:alena.prokharc...@citrix.com>>
Sent: Thursday, June 12, 2014 12:13 AM
Subject: RE: NetworkOrchestrator selects 2 NetworkGurus at one time

Thanks Chiradeep and Murali for the reply!

I am thinking of explicitly telling ExternalNetworkGuru to skip design when 
Brocade plugin is designing the network. I don't want to disable 
ExternalNetworkGuru from default build when Brocade plugin is not present so 
won't exclude it from the spring class loader.

Thanks & Regards,
Ritu S.



-Original Message-
From: Murali Reddy 
[mailto:murali.re...@citrix.com]
Sent: Tuesday, June 10, 2014 10:54 PM
To: Chiradeep Vittal; 
dev@cloudstack.apache.org
Cc: Sheng Yang; Jayapal Reddy Uradi; Alena Prokharchyk
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

This is know design issue. Unlike service orchestration (which has prescriptive 
way to tell which network elements to be called for with network offerings ) 
there is no such logic for network design. Orchestrator just loops through all 
the network guru's asking to design the network which can results in one or 
more networks. Hugo did a cleanup [1] but I believe it was not merged as there 
was no consensus. There is 1-1 mapping between isolation type and Guru but In 
this case both Brocade Guru and ExternalNetworkGuru will attempt to design the 
VLAN isolated networks.

One in-elegent solution is to hard code ExternalGuestNetworu guru to skip 
network deign when Brocade plug-in is supposed to do design the network. Other 
option could be exclude ExternalNetworkGuru bean from spring class loader.

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

From: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>>
Date: Wednesday, 11 June 2014 6:24 AM
To: 
"dev@cloudstack.apache.org>"
 
mailto:dev@cloudstack.apache.org>>>
Cc: Sheng Yang 
mailto:sheng.y...@citrix.com>>>,
 Murali Reddy 
mailto:murali.re...@citrix.com>>>,
 Jayapal Reddy Uradi 
mailto:jayapalreddy.ur...@citrix.com>>>,
 Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>>
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

That is strange. Looks like a bug to me. That is because the 
ExternalGuestNetworkGuru returns 'true' for canHandle.

From: Ritu Sabharwal 
mailto:rsabh...@brocade.com>>>
Reply-To: 
"dev@cloudstack.apache.org>"
 
mailto:dev@cloudstack.apache.org>>>
Date: Tuesday, June 10, 2014 at 11:02 AM
To: 
"dev@cloudstack.apache.org>"
 
mailto:dev@cloudstack.apache.org>

Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[Alena Prokharchyk]

Alex, sorry to hear that it took so long to get on the review process. The 
question still remains – before you started working on implementation, and 
posted your plugin’s code, was the FS approved/reviewed as a part of [PROPOSAL] 
discussion? We should never start the development until you get the input from 
the community on the FS and confirm that the design is valid and the feature 
can contribute to CS. Only after the proposal is accepted, you can request the 
Reviewboard ticket review. So I did assume that the [PROPOSAL] phase was 
finished, and the FS was validated as a part of it, when I was asked by Daan to 
review the Reviewboard ticket.

I’ve also looked at the history. I can see that Chiradeep contributed to the 
design/plugin logic discussion as well as pointed to the changes that need to 
be done to the code structure. I helped to review the second.

Lets wait for the update from Kishan. Kishan, in addition to answering Alex’s 
questions, please go over the plugin design once again.

Thank you,
Alena.

From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Thursday, June 26, 2014 at 11:32 AM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Kishan Kavala mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Murali Reddy 
mailto:murali.re...@citrix.com>>, Ram Ganesh 
mailto:ram.gan...@citrix.com>>, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple 
Regions (Core Changes)

Alena,

It has been reduced almost twice because a lot has been separated from the CS 
and moved to the plug-in not because they are 'unnecessary'. Please remember 
that my initial implementation was inside the CS not as a plug-in as I said in 
the previous email.

Of course, I asked and urged the review repeatedly and you'll see the all the 
histories of them if you find emails using this subject, which started 10/17/13.
[DISCUSS] Domain-Account-User Sync Up Among Multiple Regions
Even if I asked so many times, unfortunately, I couldn't get an actual feedback 
until Daan finally asked Chiradeep and you to review them, which is 3/10/14.

Kishan,
I posted 2 questions, so please guide me for the questions.

Thanks
Alex Ough



On Thu, Jun 26, 2014 at 12:57 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Alex,

By “huge” I’ve meant that there was a lot of repetitive hardcoded things, lot 
of unnecessary changes to the CS orchestration layer. If you compare a number 
of changes now and originally, you can see that it reduced almost twice.

But lets discuss the complains about lack of initial review as its more 
important question.

Review of the design spec should happen before you start designing/coding. As I 
jumped on review much later, after you’ve submitted the entire plugin code, so 
I I didn’t participate in “Feature Request” discussion review that might have 
happened earlier. And I do assume that the reviews/emails exchanges were done 
at that initial phase? You should have contacted the people participating in 
the initial phase, and ask them for the review as well.

As a part of my review, I’ve made sure to cover the things I’m certain should 
have been changed. I’ve reviewed the feature logic as well, consulting the FS 
you’ve written. I’m not saying that there is anything wrong with your initial 
design, but asking for a second opinion from the guys who have more expertise 
in Regions.

Kishan, please help to do the final review the Alex’s plugin design 
https://reviews.apache.org/r/17790

Thank you,
Alena.
From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Wednesday, June 25, 2014 at 9:03 PM

To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Kishan Kavala mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Murali Reddy 
mailto:murali.re...@citrix.com>>, Ram Ganesh 
mailto:ram.gan...@citrix.com>>, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple 
Regions (Core Changes)

Alena,

I understand that you have been helping a lot to make my codes to match the 
coding standards, but I'm not sure what you mean by "the code base was 
unnecessary huge".
The initial implementation was to support the synchronization inside the CS 
because this feature is missing in the current multiple region support, and 
most of jobs were  to separate the implementation from the CS because you guys 
wanted me to provide it as a plugin.

And I kept asking reviews for the design spec from when I published the 
documents with initial prototype, it took a while for you to start to review my 
implementation and they have been mostly about the coding standards instead of 
the logic itself. So I'm saying that it would have been better if there has 
been someone to 

Re: Review Request 22019: CLOUDSTACK-6732: [OVS][UI] Network Service Providers page displays two ovs providers

[Jessica Wang]

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

Ship it!


Ship It!

- Jessica Wang


On May 29, 2014, 2:16 p.m., Gabor Apati-Nagy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22019/
> ---
> 
> (Updated May 29, 2014, 2:16 p.m.)
> 
> 
> Review request for cloudstack, Brian Federle and Jessica Wang.
> 
> 
> Bugs: CLOUDSTACK-6732
> https://issues.apache.org/jira/browse/CLOUDSTACK-6732
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed: CLOUDSTACK-6732: [OVS][UI] Network Service Providers page displays two 
> ovs providers
> 
> 
> Diffs
> -
> 
>   ui/scripts/system.js 67e01f1 
> 
> Diff: https://reviews.apache.org/r/22019/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabor Apati-Nagy
> 
>

Re: Review Request 23084: Making the "Adding primary storage form" support adding primary storage to CS that is based on storage plug-ins

[Seifeddine JEMLI]

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

(Updated June 26, 2014, 8:47 p.m.)


Review request for cloudstack and Mike Wang.


Repository: cloudstack-git


Description
---

Making the GUI support adding primary storage to CS that is based on storage 
plug-ins
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Create+GUI+to+add+primary+storage+based+on+plug-ins


Diffs
-

  client/WEB-INF/classes/resources/messages.properties b504a18 
  ui/dictionary.jsp 9026a36 
  ui/scripts/docs.js aad358b 
  ui/scripts/system.js 44a08a6 

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


Testing
---

manual testing by changing GUI controls and observing the behavior. verifying 
that data ended up in the storage_pool table as expected.


Thanks,

Seifeddine JEMLI

Re: Review Request 23084: Making the "Adding primary storage form" support adding primary storage to CS that is based on storage plug-ins

[Seifeddine JEMLI]

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

(Updated June 26, 2014, 8:49 p.m.)


Review request for cloudstack and Mike Tutkowski.


Repository: cloudstack-git


Description
---

Making the GUI support adding primary storage to CS that is based on storage 
plug-ins
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Create+GUI+to+add+primary+storage+based+on+plug-ins


Diffs
-

  client/WEB-INF/classes/resources/messages.properties b504a18 
  ui/dictionary.jsp 9026a36 
  ui/scripts/docs.js aad358b 
  ui/scripts/system.js 44a08a6 

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


Testing
---

manual testing by changing GUI controls and observing the behavior. verifying 
that data ended up in the storage_pool table as expected.


Thanks,

Seifeddine JEMLI

Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[Alex Ough]

Alena,
Didn't you say that you guys already "did logic review" in the previous
email?

Thanks
Alex Ough


On Thu, Jun 26, 2014 at 2:59 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>  Alex, sorry to hear that it took so long to get on the review process.
> The question still remains – before you started working on implementation,
> and posted your plugin’s code, was the FS approved/reviewed as a part of
> [PROPOSAL] discussion? We should never start the development until you get
> the input from the community on the FS and confirm that the design is valid
> and the feature can contribute to CS. Only after the proposal is accepted,
> you can request the Reviewboard ticket review. So I did assume that the
> [PROPOSAL] phase was finished, and the FS was validated as a part of it,
> when I was asked by Daan to review the Reviewboard ticket.
>
>  I’ve also looked at the history. I can see that Chiradeep contributed to
> the design/plugin logic discussion as well as pointed to the changes that
> need to be done to the code structure. I helped to review the second.
>
>  Lets wait for the update from Kishan. Kishan, in addition to answering
> Alex’s questions, please go over the plugin design once again.
>
>  Thank you,
> Alena.
>
>   From: Alex Ough 
> Date: Thursday, June 26, 2014 at 11:32 AM
>
> To: Alena Prokharchyk 
> Cc: Kishan Kavala , "dev@cloudstack.apache.org"
> , Murali Reddy , Ram
> Ganesh , Animesh Chaturvedi <
> animesh.chaturv...@citrix.com>
> Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among
> Multiple Regions (Core Changes)
>
>   Alena,
>
>  It has been reduced almost twice because a lot has been separated from
> the CS and moved to the plug-in not because they are 'unnecessary'. Please
> remember that my initial implementation was inside the CS not as a plug-in
> as I said in the previous email.
>
>  Of course, I asked and urged the review repeatedly and you'll see the
> all the histories of them if you find emails using this subject, which
> started 10/17/13.
> [DISCUSS] Domain-Account-User Sync Up Among Multiple Regions
>  Even if I asked so many times, unfortunately, I couldn't get an actual
> feedback until Daan finally asked Chiradeep and you to review them, which
> is 3/10/14.
>
>  Kishan,
> I posted 2 questions, so please guide me for the questions.
>
>  Thanks
> Alex Ough
>
>
>
> On Thu, Jun 26, 2014 at 12:57 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>>  Alex,
>>
>>  By “huge” I’ve meant that there was a lot of repetitive hardcoded
>> things, lot of unnecessary changes to the CS orchestration layer. If you
>> compare a number of changes now and originally, you can see that it reduced
>> almost twice.
>>
>>  But lets discuss the complains about lack of initial review as its more
>> important question.
>>
>>  Review of the design spec should happen before you start
>> designing/coding. As I jumped on review much later, after you’ve submitted
>> the entire plugin code, so I I didn’t participate in “Feature Request”
>> discussion review that might have happened earlier. And I do assume that
>> the reviews/emails exchanges were done at that initial phase? You should
>> have contacted the people participating in the initial phase, and ask them
>> for the review as well.
>>
>>  As a part of my review, I’ve made sure to cover the things I’m certain
>> should have been changed. I’ve reviewed the feature logic as well,
>> consulting the FS you’ve written. I’m not saying that there is anything
>> wrong with your initial design, but asking for a second opinion from the
>> guys who have more expertise in Regions.
>>
>>  Kishan, please help to do the final review the Alex’s plugin design
>> https://reviews.apache.org/r/17790
>>
>>  Thank you,
>> Alena.
>>  From: Alex Ough 
>> Date: Wednesday, June 25, 2014 at 9:03 PM
>>
>> To: Alena Prokharchyk 
>> Cc: Kishan Kavala , "dev@cloudstack.apache.org"
>> , Murali Reddy , Ram
>> Ganesh , Animesh Chaturvedi <
>> animesh.chaturv...@citrix.com>
>> Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among
>> Multiple Regions (Core Changes)
>>
>>   Alena,
>>
>>  I understand that you have been helping a lot to make my codes to match
>> the coding standards, but I'm not sure what you mean by "the code base was
>> unnecessary huge".
>> The initial implementation was to support the synchronization inside the
>> CS because this feature is missing in the current multiple region support,
>> and most of jobs were  to separate the implementation from the CS because
>> you guys wanted me to provide it as a plugin.
>>
>>  And I kept asking reviews for the design spec from when I published the
>> documents with initial prototype, it took a while for you to start to
>> review my implementation and they have been mostly about the coding
>> standards instead of the logic itself. So I'm saying that it would have
>> been better if there has been someone to review the design spec and the
>> prototype from the ini

[VMWARE][ACS430] Traffic Shaping

[ilya musayev]

Are we enabling traffic shaping on vmware standard switches/portgroups 
and if so, how do we change the behavior or turn it off complete?

Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[Alena Prokharchyk]

I did logic review according to the FS assuming that the FS (and the design 
described there) was approved on the [PROPOSAL] stage, BEFORE the code was put 
it to the review board. Was it approved at that stage?

Alex, the feature is not small, and considering that it raised so many 
questions and arguing, I would really like to get a final design/logic review + 
“ship it” from people having expertise on the topic, and/or who originally 
participated in review/discussion: Chiradeep, Kishan, Murail.

Thank you,
Alena.

From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Thursday, June 26, 2014 at 1:53 PM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Kishan Kavala mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Murali Reddy 
mailto:murali.re...@citrix.com>>, Ram Ganesh 
mailto:ram.gan...@citrix.com>>, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple 
Regions (Core Changes)

Alena,
Didn't you say that you guys already "did logic review" in the previous email?

Thanks
Alex Ough


On Thu, Jun 26, 2014 at 2:59 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Alex, sorry to hear that it took so long to get on the review process. The 
question still remains – before you started working on implementation, and 
posted your plugin’s code, was the FS approved/reviewed as a part of [PROPOSAL] 
discussion? We should never start the development until you get the input from 
the community on the FS and confirm that the design is valid and the feature 
can contribute to CS. Only after the proposal is accepted, you can request the 
Reviewboard ticket review. So I did assume that the [PROPOSAL] phase was 
finished, and the FS was validated as a part of it, when I was asked by Daan to 
review the Reviewboard ticket.

I’ve also looked at the history. I can see that Chiradeep contributed to the 
design/plugin logic discussion as well as pointed to the changes that need to 
be done to the code structure. I helped to review the second.

Lets wait for the update from Kishan. Kishan, in addition to answering Alex’s 
questions, please go over the plugin design once again.

Thank you,
Alena.

From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Thursday, June 26, 2014 at 11:32 AM

To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Kishan Kavala mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Murali Reddy 
mailto:murali.re...@citrix.com>>, Ram Ganesh 
mailto:ram.gan...@citrix.com>>, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple 
Regions (Core Changes)

Alena,

It has been reduced almost twice because a lot has been separated from the CS 
and moved to the plug-in not because they are 'unnecessary'. Please remember 
that my initial implementation was inside the CS not as a plug-in as I said in 
the previous email.

Of course, I asked and urged the review repeatedly and you'll see the all the 
histories of them if you find emails using this subject, which started 10/17/13.
[DISCUSS] Domain-Account-User Sync Up Among Multiple Regions
Even if I asked so many times, unfortunately, I couldn't get an actual feedback 
until Daan finally asked Chiradeep and you to review them, which is 3/10/14.

Kishan,
I posted 2 questions, so please guide me for the questions.

Thanks
Alex Ough



On Thu, Jun 26, 2014 at 12:57 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Alex,

By “huge” I’ve meant that there was a lot of repetitive hardcoded things, lot 
of unnecessary changes to the CS orchestration layer. If you compare a number 
of changes now and originally, you can see that it reduced almost twice.

But lets discuss the complains about lack of initial review as its more 
important question.

Review of the design spec should happen before you start designing/coding. As I 
jumped on review much later, after you’ve submitted the entire plugin code, so 
I I didn’t participate in “Feature Request” discussion review that might have 
happened earlier. And I do assume that the reviews/emails exchanges were done 
at that initial phase? You should have contacted the people participating in 
the initial phase, and ask them for the review as well.

As a part of my review, I’ve made sure to cover the things I’m certain should 
have been changed. I’ve reviewed the feature logic as well, consulting the FS 
you’ve written. I’m not saying that there is anything wrong with your initial 
design, but asking for a second opinion from the guys who have more expertise 
in Regions.

Kishan, please help to do the final review the Alex’s plugin design 
https://reviews.apache.org/r/17790

Thank you,
Alena.
From: Alex Ough mailto:alex.o...@sungardas.com>>

Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[Alex Ough]

Sounds like it goes back to what I said I wish they have been involved
more actively from the start.

Thanks but really making me tired.
Alex Ough


On Thu, Jun 26, 2014 at 5:17 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>  I did logic review according to the FS assuming that the FS (and the
> design described there) was approved on the [PROPOSAL] stage, BEFORE the
> code was put it to the review board. Was it approved at that stage?
>
>  Alex, the feature is not small, and considering that it raised so many
> questions and arguing, I would really like to get a final design/logic
> review + “ship it” from people having expertise on the topic, and/or who
> originally participated in review/discussion: Chiradeep, Kishan, Murail.
>
>  Thank you,
> Alena.
>
>   From: Alex Ough 
> Date: Thursday, June 26, 2014 at 1:53 PM
>
> To: Alena Prokharchyk 
> Cc: Kishan Kavala , "dev@cloudstack.apache.org"
> , Murali Reddy , Ram
> Ganesh , Animesh Chaturvedi <
> animesh.chaturv...@citrix.com>
> Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among
> Multiple Regions (Core Changes)
>
>   Alena,
> Didn't you say that you guys already "did logic review" in the previous
> email?
>
>  Thanks
> Alex Ough
>
>
> On Thu, Jun 26, 2014 at 2:59 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>>  Alex, sorry to hear that it took so long to get on the review process.
>> The question still remains – before you started working on implementation,
>> and posted your plugin’s code, was the FS approved/reviewed as a part of
>> [PROPOSAL] discussion? We should never start the development until you get
>> the input from the community on the FS and confirm that the design is valid
>> and the feature can contribute to CS. Only after the proposal is accepted,
>> you can request the Reviewboard ticket review. So I did assume that the
>> [PROPOSAL] phase was finished, and the FS was validated as a part of it,
>> when I was asked by Daan to review the Reviewboard ticket.
>>
>>  I’ve also looked at the history. I can see that Chiradeep contributed
>> to the design/plugin logic discussion as well as pointed to the changes
>> that need to be done to the code structure. I helped to review the second.
>>
>>  Lets wait for the update from Kishan. Kishan, in addition to answering
>> Alex’s questions, please go over the plugin design once again.
>>
>>  Thank you,
>> Alena.
>>
>>   From: Alex Ough 
>> Date: Thursday, June 26, 2014 at 11:32 AM
>>
>> To: Alena Prokharchyk 
>> Cc: Kishan Kavala , "dev@cloudstack.apache.org"
>> , Murali Reddy , Ram
>> Ganesh , Animesh Chaturvedi <
>> animesh.chaturv...@citrix.com>
>> Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among
>> Multiple Regions (Core Changes)
>>
>>   Alena,
>>
>>  It has been reduced almost twice because a lot has been separated from
>> the CS and moved to the plug-in not because they are 'unnecessary'. Please
>> remember that my initial implementation was inside the CS not as a plug-in
>> as I said in the previous email.
>>
>>  Of course, I asked and urged the review repeatedly and you'll see the
>> all the histories of them if you find emails using this subject, which
>> started 10/17/13.
>> [DISCUSS] Domain-Account-User Sync Up Among Multiple Regions
>>  Even if I asked so many times, unfortunately, I couldn't get an actual
>> feedback until Daan finally asked Chiradeep and you to review them,
>> which is 3/10/14.
>>
>>  Kishan,
>> I posted 2 questions, so please guide me for the questions.
>>
>>  Thanks
>> Alex Ough
>>
>>
>>
>> On Thu, Jun 26, 2014 at 12:57 PM, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wrote:
>>
>>>  Alex,
>>>
>>>  By “huge” I’ve meant that there was a lot of repetitive hardcoded
>>> things, lot of unnecessary changes to the CS orchestration layer. If you
>>> compare a number of changes now and originally, you can see that it reduced
>>> almost twice.
>>>
>>>  But lets discuss the complains about lack of initial review as its
>>> more important question.
>>>
>>>  Review of the design spec should happen before you start
>>> designing/coding. As I jumped on review much later, after you’ve submitted
>>> the entire plugin code, so I I didn’t participate in “Feature Request”
>>> discussion review that might have happened earlier. And I do assume that
>>> the reviews/emails exchanges were done at that initial phase? You should
>>> have contacted the people participating in the initial phase, and ask them
>>> for the review as well.
>>>
>>>  As a part of my review, I’ve made sure to cover the things I’m certain
>>> should have been changed. I’ve reviewed the feature logic as well,
>>> consulting the FS you’ve written. I’m not saying that there is anything
>>> wrong with your initial design, but asking for a second opinion from the
>>> guys who have more expertise in Regions.
>>>
>>>  Kishan, please help to do the final review the Alex’s plugin design
>>> https://reviews.apache.org/r/17790
>>>
>>>  Thank yo

[ISSUE] can not parse [10.1.1.0] error while creating Guest Network for CIDR

[Ritu Sabharwal]

Hi,

I am trying to create a guest network for a network offering. I am giving in 
all the values and when I give IPv6 cidr value to 10.1.10/23 I get error on UI.

can not parse [10.1.1.0].

I tried this with 4.3 and it was workin. It does not work with master branch 
codebase.

Please let me know what is the change in the format.

Thanks & Regards,
Ritu S.

Re: [ISSUE] can not parse [10.1.1.0] error while creating Guest Network for CIDR

[Daan Hoogland]

H Ritu,

Are you sure you entered 10.1.10/23? it seems to me it would have to
be 10.1.10.0/23.
and did you enter it in the field for IPv6? this is an ipv4 address format

Daan

On Thu, Jun 26, 2014 at 11:40 PM, Ritu Sabharwal  wrote:
> Hi,
>
> I am trying to create a guest network for a network offering. I am giving in 
> all the values and when I give IPv6 cidr value to 10.1.10/23 I get error on 
> UI.
>
> can not parse [10.1.1.0].
>
> I tried this with 4.3 and it was workin. It does not work with master branch 
> codebase.
>
> Please let me know what is the change in the format.
>
> Thanks & Regards,
> Ritu S.



-- 
Daan

Re: [ISSUE] can not parse [10.1.1.0] error while creating Guest Network for CIDR

[Daan Hoogland]

PS
Don't know of a format change.

On Thu, Jun 26, 2014 at 11:46 PM, Daan Hoogland  wrote:
> H Ritu,
>
> Are you sure you entered 10.1.10/23? it seems to me it would have to
> be 10.1.10.0/23.
> and did you enter it in the field for IPv6? this is an ipv4 address format
>
> Daan
>
> On Thu, Jun 26, 2014 at 11:40 PM, Ritu Sabharwal  wrote:
>> Hi,
>>
>> I am trying to create a guest network for a network offering. I am giving in 
>> all the values and when I give IPv6 cidr value to 10.1.10/23 I get error on 
>> UI.
>>
>> can not parse [10.1.1.0].
>>
>> I tried this with 4.3 and it was workin. It does not work with master branch 
>> codebase.
>>
>> Please let me know what is the change in the format.
>>
>> Thanks & Regards,
>> Ritu S.
>
>
>
> --
> Daan



-- 
Daan

RE: [ISSUE] can not parse [10.1.1.0] error while creating Guest Network for CIDR

[Ritu Sabharwal]

Sorry for the typo in earlier mail.

I gave 10.1.10.1/23 in the IPv6 CIDR field and get an error can not parse 
[10.1.10.1]. This was working with 4.3

Ritu.

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Thursday, June 26, 2014 2:47 PM
To: dev
Subject: Re: [ISSUE] can not parse [10.1.1.0] error while creating Guest 
Network for CIDR

PS
Don't know of a format change.

On Thu, Jun 26, 2014 at 11:46 PM, Daan Hoogland  wrote:
> H Ritu,
>
> Are you sure you entered 10.1.10/23? it seems to me it would have to 
> be 10.1.10.0/23.
> and did you enter it in the field for IPv6? this is an ipv4 address 
> format
>
> Daan
>
> On Thu, Jun 26, 2014 at 11:40 PM, Ritu Sabharwal  wrote:
>> Hi,
>>
>> I am trying to create a guest network for a network offering. I am giving in 
>> all the values and when I give IPv6 cidr value to 10.1.10/23 I get error on 
>> UI.
>>
>> can not parse [10.1.1.0].
>>
>> I tried this with 4.3 and it was workin. It does not work with master branch 
>> codebase.
>>
>> Please let me know what is the change in the format.
>>
>> Thanks & Regards,
>> Ritu S.
>
>
>
> --
> Daan



--
Daan

Re: [ISSUE] can not parse [10.1.1.0] error while creating Guest Network for CIDR

[Daan Hoogland]

that would be strange. It is not a IPv6 cidr. It is IPv4.

On Thu, Jun 26, 2014 at 11:51 PM, Ritu Sabharwal  wrote:
> Sorry for the typo in earlier mail.
>
> I gave 10.1.10.1/23 in the IPv6 CIDR field and get an error can not parse 
> [10.1.10.1]. This was working with 4.3
>
> Ritu.
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Thursday, June 26, 2014 2:47 PM
> To: dev
> Subject: Re: [ISSUE] can not parse [10.1.1.0] error while creating Guest 
> Network for CIDR
>
> PS
> Don't know of a format change.
>
> On Thu, Jun 26, 2014 at 11:46 PM, Daan Hoogland  
> wrote:
>> H Ritu,
>>
>> Are you sure you entered 10.1.10/23? it seems to me it would have to
>> be 10.1.10.0/23.
>> and did you enter it in the field for IPv6? this is an ipv4 address
>> format
>>
>> Daan
>>
>> On Thu, Jun 26, 2014 at 11:40 PM, Ritu Sabharwal  
>> wrote:
>>> Hi,
>>>
>>> I am trying to create a guest network for a network offering. I am giving 
>>> in all the values and when I give IPv6 cidr value to 10.1.10/23 I get error 
>>> on UI.
>>>
>>> can not parse [10.1.1.0].
>>>
>>> I tried this with 4.3 and it was workin. It does not work with master 
>>> branch codebase.
>>>
>>> Please let me know what is the change in the format.
>>>
>>> Thanks & Regards,
>>> Ritu S.
>>
>>
>>
>> --
>> Daan
>
>
>
> --
> Daan



-- 
Daan

Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

[Ritu Sabharwal]

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

(Updated June 26, 2014, 10:25 p.m.)


Review request for cloudstack.


Changes
---

Fixed the issues as provided in review comments. Uploaded new diff file with 
changes and patch file for Brocade functionality code.


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


Repository: cloudstack-git


Description
---

First code drop for Brocade Network plugin to orchestrate Brocade VDX switches 
for L2 connectivity. Please create a new branch for Brocade plugin.


Diffs (updated)
-

  api/src/com/cloud/network/Network.java 885bffe 
  api/src/com/cloud/network/Networks.java 1e4d229 
  api/src/com/cloud/network/PhysicalNetwork.java 8cc214e 
  client/pom.xml 29fef4f 
  plugins/pom.xml b5e6a61 
  setup/db/db/schema-440to450.sql 77445a9 
  ui/scripts/system.js 9a98a5c 

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


Testing
---

•   Create an isolated network; verify that the port-profile is created on 
the Brocade switch.
•   Attach a VM to the network; verify that the VMs MAC address is 
associated with the port profile of the network on the Brocade switch.
•   Delete VMs for an isolated network; verify that the VMs MAC address is 
disassociated with the port profile of the network on the Brocade switch.
•   Delete the isolated network; verify that the port-profile is deleted 
from the Brocade switch.


File Attachments (updated)


Diff for the existing cloudstack code
  
https://reviews.apache.org/media/uploaded/files/2014/06/23/8fc3cfb1-7a21-4714-98f3-6514cf54ba84__diff
Patch file for Brocade functionality code
  
https://reviews.apache.org/media/uploaded/files/2014/06/26/92bb0014-a7b7-4f0b-97c9-018d615b658a__brocade-vcs.patch


Thanks,

Ritu  Sabharwal

Re: Review Request 21817: [UI] New Zones tab for Templates and ISOs

[Jessica Wang]

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

Ship it!


Ship It!

- Jessica Wang


On May 22, 2014, 4:52 p.m., Gabor Apati-Nagy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21817/
> ---
> 
> (Updated May 22, 2014, 4:52 p.m.)
> 
> 
> Review request for cloudstack and Jessica Wang.
> 
> 
> Bugs: CLOUDSTACK-6565
> https://issues.apache.org/jira/browse/CLOUDSTACK-6565
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> New diff with improved ui layout
> 
> 
> Diffs
> -
> 
>   ui/css/cloudstack3.css cb9fa35 
>   ui/dictionary.jsp 9cc030a 
>   ui/scripts/templates.js 67cc2fb 
> 
> Diff: https://reviews.apache.org/r/21817/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabor Apati-Nagy
> 
>

Review Request 23098: Updated Marvin code to support more properties.

[Vania Xu]

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

Review request for cloudstack and Mike Tutkowski.


Repository: cloudstack-git


Description
---

Building automated integration tests that needed additional properties added to 
Marvin code. 


Diffs
-

  tools/marvin/marvin/integration/lib/base.py 95b7fe9 

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


Testing
---

Ran new code against my integration tests, and it was successful. 


Thanks,

Vania Xu

Re: [VMWARE][ACS430] Traffic Shaping

[Nux!]

Ilya,

Isn't this tied into the network/service offering? (it is for other HVs, 
defaults to 200 Mbps afaik)

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "ilya musayev" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, 26 June, 2014 9:55:09 PM
> Subject: [VMWARE][ACS430] Traffic Shaping
> 
> Are we enabling traffic shaping on vmware standard switches/portgroups
> and if so, how do we change the behavior or turn it off complete?
> 

RE: [VMWARE][ACS430] Traffic Shaping

[Sateesh Chodapuneedi]

Yes, it's tied to networking offering. Implemented network settings follows the 
network offering.

Regards,
Sateesh
> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: 27 June 2014 05:32
> To: dev@cloudstack.apache.org
> Subject: Re: [VMWARE][ACS430] Traffic Shaping
> 
> Ilya,
> 
> Isn't this tied into the network/service offering? (it is for other HVs, 
> defaults to 200 Mbps afaik)
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
> > From: "ilya musayev" 
> > To: dev@cloudstack.apache.org
> > Sent: Thursday, 26 June, 2014 9:55:09 PM
> > Subject: [VMWARE][ACS430] Traffic Shaping
> >
> > Are we enabling traffic shaping on vmware standard switches/portgroups
> > and if so, how do we change the behavior or turn it off complete?
> >

Re: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[John Burwell]

All,

I apologize for joining this conversation late.  I understand that this patch 
was submitted back in February.  Around this time, my family had a significant 
medical event, and I was disengaged from all work activities — missing the 
original conversation.

Reading through the specification, and briefly reviewing the code, I would like 
to understand the following assumptions/design decisions:

   1. Why aren’t projects being sync’ed?  It seems very likely that users would 
want to have projects span data centers for redundancy/DR purposes.
   2. Why aren’t events being sync’ed?  I can imagine a number of scenarios 
where I would want to examine the operation of an logical application or system 
across both regions. Without the sync of event data, I would be forced to 
either perform that interleave visually with two browser tabs or dump the data 
into another datastore to be merged.
   3. Why isn’t template metadata being sync’ed?  When spanning an 
application/system across regions, it would seem to follow that I would want to 
use the same templates.
   4. How does this design deal with modifications to a record in two or more 
regions during a network partition?
   5. Given that messages can/will be processed out of order, how is 
referential integrity maintained when a parent and a set of children are 
created (e.g. creation of a new account and a set of users rapidly through the 
API)?
   6. Is RabbitMQ being relied upon to provide partition tolerance?
   7. Is there a back pressure mechanism to throttle the full sync operation 
when the database/management server is under heavy load?

Finally, I would like to understand why we are taking on multi-datacenter data 
replication in CloudStack, and not deferring to underlying datastore.  Speaking 
as someone whose $dayjob involves delivering such a system (at Basho for Riak), 
it is a very hard thing to get right (there literally thousands of corner 
cases).  The design document does not speak to this decision, and I would like 
understand how CloudStack could not leverage existing, mature mechanisms at the 
datastore-level.

I apologize if some of these questions have been answered already.  I attempt 
to look back in the archives, but given the span of this conversation, it was 
difficult to piece together retroactively.

Thanks,
-John
On June 26, 2014 at 5:34:31 PM, Alex Ough (alex.o...@sungardas.com) wrote:

Sounds like it goes back to what I said I wish they have been involved  
more actively from the start.  

Thanks but really making me tired.  
Alex Ough  


On Thu, Jun 26, 2014 at 5:17 PM, Alena Prokharchyk <  
alena.prokharc...@citrix.com> wrote:  

> I did logic review according to the FS assuming that the FS (and the  
> design described there) was approved on the [PROPOSAL] stage, BEFORE the  
> code was put it to the review board. Was it approved at that stage?  
>  
> Alex, the feature is not small, and considering that it raised so many  
> questions and arguing, I would really like to get a final design/logic  
> review + “ship it” from people having expertise on the topic, and/or who  
> originally participated in review/discussion: Chiradeep, Kishan, Murail.  
>  
> Thank you,  
> Alena.  
>  
> From: Alex Ough   
> Date: Thursday, June 26, 2014 at 1:53 PM  
>  
> To: Alena Prokharchyk   
> Cc: Kishan Kavala , "dev@cloudstack.apache.org"  
> , Murali Reddy , Ram  
> Ganesh , Animesh Chaturvedi <  
> animesh.chaturv...@citrix.com>  
> Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among  
> Multiple Regions (Core Changes)  
>  
> Alena,  
> Didn't you say that you guys already "did logic review" in the previous  
> email?  
>  
> Thanks  
> Alex Ough  
>  
>  
> On Thu, Jun 26, 2014 at 2:59 PM, Alena Prokharchyk <  
> alena.prokharc...@citrix.com> wrote:  
>  
>> Alex, sorry to hear that it took so long to get on the review process.  
>> The question still remains – before you started working on implementation,  
>> and posted your plugin’s code, was the FS approved/reviewed as a part of  
>> [PROPOSAL] discussion? We should never start the development until you get  
>> the input from the community on the FS and confirm that the design is valid  
>> and the feature can contribute to CS. Only after the proposal is accepted,  
>> you can request the Reviewboard ticket review. So I did assume that the  
>> [PROPOSAL] phase was finished, and the FS was validated as a part of it,  
>> when I was asked by Daan to review the Reviewboard ticket.  
>>  
>> I’ve also looked at the history. I can see that Chiradeep contributed  
>> to the design/plugin logic discussion as well as pointed to the changes  
>> that need to be done to the code structure. I helped to review the second.  
>>  
>> Lets wait for the update from Kishan. Kishan, in addition to answering  
>> Alex’s questions, please go over the plugin design once again.  
>>  
>> Thank you,  
>> Alena.  
>>  
>> From: Alex Ough   
>> Date: Thursday, June 26, 2014

RE: Review Request 20099: Domain-Account-User Sync Up Among Multiple Regions (Core Changes)

[Kishan Kavala]

Alex, 
You are correct. It should be Integer and not Long.

> -Original Message-
> From: Alex Ough [mailto:alex.o...@sungardas.com]
> Sent: Thursday, 26 June 2014 8:09 PM
> To: Kishan Kavala
> Cc: cloudstack
> Subject: Re: Review Request 20099: Domain-Account-User Sync Up Among
> Multiple Regions (Core Changes)
> 
> Kishan,
> 
> The type of region id is Integer, not Long, so I'm wondering why it should be
> Long.
> 
> Alex Ough
> 
> 
> 
> On Thu, Jun 26, 2014 at 2:08 AM, Kishan Kavala 
> wrote:
> 
> >This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/20099/
> >
> > Alex,
> >  As discussed on the mailing list, ORIGINATEDREGIONUUID should be the
> regionId which is Long. So all the ORIGINATEDREGIONUUID references should
> just be ORIGINATEDREGIONID and of datatype Long.
> >
> >
> > - Kishan Kavala
> >
> > On June 24th, 2014, 9:24 p.m. IST, Alex Ough wrote:
> >   Review request for cloudstack.
> > By Alex Ough.
> >
> > *Updated June 24, 2014, 9:24 p.m.*
> >  *Repository: * cloudstack-git
> > Description
> >
> > This is the review request for the core changes related with #17790 that has
> only the new plugin codes.
> >
> >   Testing
> >
> > 1. Successfully tested real time synchronization as soon as resources are
> created/deleted/modified in one region.
> > 2. Successfully tested full scans to synchronize resources that were missed
> during real time synchronization because of any reasons like network
> connection issues.
> > 3. The tests were done manually and also automatically by randomly
> generating changes each region.
> >
> >   Diffs
> >
> >- api/src/com/cloud/event/EventTypes.java (0fa3cd5)
> >- api/src/com/cloud/user/AccountService.java (eac8a76)
> >- api/src/com/cloud/user/DomainService.java (4c1f93d)
> >- api/src/org/apache/cloudstack/api/ApiConstants.java (adda5f4)
> >- api/src/org/apache/cloudstack/api/BaseCmd.java (ac9a208)
> >-
> api/src/org/apache/cloudstack/api/command/admin/account/CreateAccount
> Cmd.java
> >(50d67d9)
> >-
> api/src/org/apache/cloudstack/api/command/admin/account/DeleteAccount
> Cmd.java
> >(5754ec5)
> >-
> api/src/org/apache/cloudstack/api/command/admin/account/DisableAccount
> Cmd.java
> >(3e5e1d3)
> >-
> api/src/org/apache/cloudstack/api/command/admin/account/EnableAccount
> Cmd.java
> >(f30c985)
> >-
> api/src/org/apache/cloudstack/api/command/admin/account/LockAccountCm
> d.java
> >(3c185e4)
> >-
> api/src/org/apache/cloudstack/api/command/admin/account/UpdateAccount
> Cmd.java
> >(a7ce74a)
> >-
> api/src/org/apache/cloudstack/api/command/admin/domain/CreateDomainC
> md.java
> >(312c9ee)
> >-
> api/src/org/apache/cloudstack/api/command/admin/domain/DeleteDomainC
> md.java
> >(a6d2b0b)
> >-
> api/src/org/apache/cloudstack/api/command/admin/domain/UpdateDomain
> Cmd.java
> >(409a84d)
> >-
> api/src/org/apache/cloudstack/api/command/admin/region/AddRegionCmd.j
> ava
> >(f6743ba)
> >-
> api/src/org/apache/cloudstack/api/command/admin/region/UpdateRegionC
> md.java
> >(b08cbbb)
> >-
> api/src/org/apache/cloudstack/api/command/admin/user/CreateUserCmd.jav
> a
> >(8f223ac)
> >-
> api/src/org/apache/cloudstack/api/command/admin/user/DeleteUserCmd.jav
> a
> >(08ba521)
> >-
> api/src/org/apache/cloudstack/api/command/admin/user/DisableUserCmd.ja
> va
> >(c6e09ef)
> >-
> api/src/org/apache/cloudstack/api/command/admin/user/EnableUserCmd.jav
> a
> >(d69eccf)
> >-
> api/src/org/apache/cloudstack/api/command/admin/user/LockUserCmd.java
> >(69623d0)
> >-
> api/src/org/apache/cloudstack/api/command/admin/user/RegisterCmd.java
> >(2090d21)
> >-
> api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.ja
> va
> >(f21e264)
> >- api/src/org/apache/cloudstack/api/response/RegionResponse.java
> >(6c74fa6)
> >- api/src/org/apache/cloudstack/region/Region.java (df64e44)
> >- api/src/org/apache/cloudstack/region/RegionService.java (afefcc7)
> >- api/test/org/apache/cloudstack/api/command/test/RegionCmdTest.java
> >(10c3d85)
> >- client/pom.xml (29fef4f)
> >- engine/schema/resources/META-INF/cloudstack/core/spring-engine-
> schema-core-daos-context.xml
> >(2ef0d20)
> >- engine/schema/src/com/cloud/user/AccountVO.java (0f5a044)
> >- engine/schema/src/org/apache/cloudstack/region/RegionVO.java
> >(608bd2b)
> >- plugins/network-elements/juniper-
> contrail/test/org/apache/cloudstack/network/contrail/management/MockAcc
> ountManager.java
> >(4136b5c)
> >- plugins/pom.xml (b5e6a61)
> >- plugins/user-
> authenticators/ldap/src/org/apache/cloudstack/api/command/LdapCreateAcc
> ountCmd.java
> >(b753952)
> >- plugins/user-
> authenticators/ldap/src/org/apache/cloudstack/api/command/LdapImportUs
> ersCmd.java
> >(6f7be90)
> >- server/src/com/cloud/api/ApiResponseHelper.java (f1f0d2c)
> >- server

Re: Cloudstack MS failover

[Abhinandan Prateek]

http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Instal
lation_Guide/management-server-install-flow.html

Section 4.5.7 has instructions on adding additional MS.

-abhi

On 26/06/14 10:55 pm, "Tejas Gadaria"  wrote:

>I want to setup HA of MS with HAproxy OR Keepalived.
>
>I have MS1 & DB1 installed on 10.1.1.2  &
>MS2 & DB2 installed on 10.1.1.3
>
>also DB has master - master replication setup.
>
>Need help on this how can i setup failover for MS.
>
>Regards,
>Tejas

Re: Review Request 22717: refactor StoragePoolAllocator#filter logic

[Mike Tutkowski]

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


I first had a chance to run this patch through a sophisticated test tonight and 
noticed an issue with zone-wide primary storage that's based on the iSCSI 
protocol.

This patch leads to iSCSI storage being filtered out for ROOT volumes, which is 
a legitimate use case in my scenario.

As such, I had to return the filter method to the ZoneWideStoragePoolAllocator 
class.

I left in the other modification to the AbstractStoragePoolAllocator.

- Mike Tutkowski


On June 18, 2014, 12:10 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22717/
> ---
> 
> (Updated June 18, 2014, 12:10 a.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski and Prachi Damle.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> refactor StoragePoolAllocator#filter logic to enable hypervisor type check, 
> storage type check for root volume and avoid list check, and to support IOPS 
> capacity control in a cluster wide storage pool and a local storage pool.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/AbstractStoragePoolAllocator.java
>  ddbb5a4 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java
>  8fb9c8d 
> 
> Diff: https://reviews.apache.org/r/22717/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 23084: Making the "Adding primary storage form" support adding primary storage to CS that is based on storage plug-ins

[Mike Tutkowski]

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

Ship it!


Committed the changes in 9a27f201b02fe33cdba1dcca7da63497b323a874

- Mike Tutkowski


On June 26, 2014, 2:49 p.m., Seifeddine JEMLI wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23084/
> ---
> 
> (Updated June 26, 2014, 2:49 p.m.)
> 
> 
> Review request for cloudstack and Mike Tutkowski.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Making the GUI support adding primary storage to CS that is based on storage 
> plug-ins
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Create+GUI+to+add+primary+storage+based+on+plug-ins
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties b504a18 
>   ui/dictionary.jsp 9026a36 
>   ui/scripts/docs.js aad358b 
>   ui/scripts/system.js 44a08a6 
> 
> Diff: https://reviews.apache.org/r/23084/diff/
> 
> 
> Testing
> ---
> 
> manual testing by changing GUI controls and observing the behavior. verifying 
> that data ended up in the storage_pool table as expected.
> 
> 
> Thanks,
> 
> Seifeddine JEMLI
> 
>

[ACS4.4, 4.4-forward] Please revert commit

[Mike Tutkowski]

Hi Daan,

Please revert commit 99dd86e588fd28dedd5fb3b830297a8a4f885760 from 4.4.

Also, please revert commit 45f0c7367680f4bfbcee470139b708d69322be78 from
4.4-forward.

These commits actually break zone-wide primary storage.

I was not aware that they ended up in 4.4 and 4.4-forward (I was thinking
they were just in master).

I performed some testing on this logic in master tonight and saw the
breakage of zone-wide primary storage.

In my opinion, we don't have enough in the way of regression testing in
CloudStack to be comfortable committing code that can have such
wide-ranging effects this late in the game.

I think we should start asking for a risk analysis from the developer when
code is checked in this late in the game (the more risk, the more important
the issue better be and the more testing that better have been done). In
this case, my entire plug-in would have been rendered useless in 4.4 by
these checkins and I don't understand how the issue itself even qualified
as a Blocker or Critical.

Thanks, Daan!

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

Re: [ACS4.4] Please cherry-pick 9c2e6f5ed45522ff68131556028f3fb4ff91ee90

[Mike Tutkowski]

Hi Daan,

I'm not seeing this commit in 4.4.

Did I miss something?

Thanks!
Mike


On Thu, Jun 26, 2014 at 11:16 AM, Daan Hoogland 
wrote:

> On Thu, Jun 26, 2014 at 6:53 PM, Mike Tutkowski
>  wrote:
> > 9c2e6f5ed45522ff68131556028f3fb4ff91ee90
>
>
> is in
>
> --
> Daan
>



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

Re: [ACS4.4, 4.4-forward] Please revert commit

[Mike Tutkowski]

Yeah, I just looked at the Review Request:

https://reviews.apache.org/r/22717/#review46838

It says it's for master (4.5), so I'm not sure how this ended up in 4.4 or
4.4-forward.


On Fri, Jun 27, 2014 at 12:09 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi Daan,
>
> Please revert commit 99dd86e588fd28dedd5fb3b830297a8a4f885760 from 4.4.
>
> Also, please revert commit 45f0c7367680f4bfbcee470139b708d69322be78 from
> 4.4-forward.
>
> These commits actually break zone-wide primary storage.
>
> I was not aware that they ended up in 4.4 and 4.4-forward (I was thinking
> they were just in master).
>
> I performed some testing on this logic in master tonight and saw the
> breakage of zone-wide primary storage.
>
> In my opinion, we don't have enough in the way of regression testing in
> CloudStack to be comfortable committing code that can have such
> wide-ranging effects this late in the game.
>
> I think we should start asking for a risk analysis from the developer when
> code is checked in this late in the game (the more risk, the more important
> the issue better be and the more testing that better have been done). In
> this case, my entire plug-in would have been rendered useless in 4.4 by
> these checkins and I don't understand how the issue itself even qualified
> as a Blocker or Critical.
>
> Thanks, Daan!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>



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

[ACS4.4] cherry pick commit dc22566c642e400014332045a224e5545d33a11c and 48646ae186eb75052da3da385404a823bd785444

[Sanjay Tripathi]

Hi Daan,

Could you please cherry-pick following commits to 4.4 branch.

Commit: dc22566c642e400014332045a224e5545d33a11c
CLOUDSTACK-6453: [GPU] Windows 2012 Server instance created with vGPU offering 
is not coming up after installing PV drivers.

Commit: 48646ae186eb75052da3da385404a823bd785444
CLOUDSTACK-6884: List Capacity API always returns GPU capacity also even if 
type is different.


--Sanjay

Fwd: [jira] [Created] (CLOUDSTACK-7003) Arithmetic exception while creating a vdi on nfs volume in managed storage.

[Punith S]

hi mike,

can you take a look at this logic, today i met an arithmetic exception(/ by
0) while creating a nfs volume.
any suggestions to calculate the maxNumberOfTries if the unavailableSrSpace
is equal to zero.

thanks


-- Forwarded message --
From: punith (JIRA) 
Date: Fri, Jun 27, 2014 at 11:57 AM
Subject: [jira] [Created] (CLOUDSTACK-7003) Arithmetic exception while
creating a vdi on nfs volume in managed storage.
To: cloudstack-iss...@incubator.apache.org


punith created CLOUDSTACK-7003:
--

 Summary: Arithmetic exception while creating a vdi on nfs
volume in managed storage.
 Key: CLOUDSTACK-7003
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7003
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the
default.)
  Components: Management Server
Affects Versions: 4.5.0
Reporter: punith


it seems we have a bug while creating a nfs disk on managed storage,

file - CitrixResourceBase.java
api - createVdi

long unavailableSrSpace = sr.getPhysicalUtilisation(conn);

6216long maxNumberOfTries = (totalSrSpace / unavailableSrSpace >= 1) ?
(totalSrSpace / unavailableSrSpace) : 1;

since while creation nfs disk does not have a meta data written on it like
in iscsi , unavailableSrSpace might turn out to be 0(zero), hence throwing
an divide bt zero exception.
sometimes the unavailable



--
This message was sent by Atlassian JIRA
(v6.2#6252)



-- 
regards,

punith s
cloudbyte.com

Re: Review Request 22717: refactor StoragePoolAllocator#filter logic

[Yoshikazu Nojima]

> On June 27, 2014, 5:46 a.m., Mike Tutkowski wrote:
> > I first had a chance to run this patch through a sophisticated test tonight 
> > and noticed an issue with zone-wide primary storage that's based on the 
> > iSCSI protocol.
> > 
> > This patch leads to iSCSI storage being filtered out for ROOT volumes, 
> > which is a legitimate use case in my scenario.
> > 
> > As such, I had to return the filter method to the 
> > ZoneWideStoragePoolAllocator class.
> > 
> > I left in the other modification to the AbstractStoragePoolAllocator.

I thought the root volume filtering logic weird, but I didn't dig into the 
problem.
Since this is a good opportunity, I would like to rethink this logic.
which storage requires the root volume filtering logic?
I understand that SolidFire's storage doesn't require it, but what about other 
iSCSI storage?
Is there any reason that other iSCSI storage cannot handle a root volume? Does 
anyone know?
Even if SolidFire's storage is the only iSCSI storage that can handle a root 
volume, I think SolidFire's storage should be exempted from the filtering logic 
not because storage is zone wide, but because storage is SolidFire's.


- Yoshikazu


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


On June 18, 2014, 6:10 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22717/
> ---
> 
> (Updated June 18, 2014, 6:10 a.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski and Prachi Damle.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> refactor StoragePoolAllocator#filter logic to enable hypervisor type check, 
> storage type check for root volume and avoid list check, and to support IOPS 
> capacity control in a cluster wide storage pool and a local storage pool.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/AbstractStoragePoolAllocator.java
>  ddbb5a4 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java
>  8fb9c8d 
> 
> Diff: https://reviews.apache.org/r/22717/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 22717: refactor StoragePoolAllocator#filter logic

[Mike Tutkowski]

> On June 26, 2014, 11:46 p.m., Mike Tutkowski wrote:
> > I first had a chance to run this patch through a sophisticated test tonight 
> > and noticed an issue with zone-wide primary storage that's based on the 
> > iSCSI protocol.
> > 
> > This patch leads to iSCSI storage being filtered out for ROOT volumes, 
> > which is a legitimate use case in my scenario.
> > 
> > As such, I had to return the filter method to the 
> > ZoneWideStoragePoolAllocator class.
> > 
> > I left in the other modification to the AbstractStoragePoolAllocator.
> 
> Yoshikazu Nojima wrote:
> I thought the root volume filtering logic weird, but I didn't dig into 
> the problem.
> Since this is a good opportunity, I would like to rethink this logic.
> which storage requires the root volume filtering logic?
> I understand that SolidFire's storage doesn't require it, but what about 
> other iSCSI storage?
> Is there any reason that other iSCSI storage cannot handle a root volume? 
> Does anyone know?
> Even if SolidFire's storage is the only iSCSI storage that can handle a 
> root volume, I think SolidFire's storage should be exempted from the 
> filtering logic not because storage is zone wide, but because storage is 
> SolidFire's.
>

I'm pretty sure any vendor's iSCSI storage can handle root volumes as it's just 
data placed on a disk. I don't know why that logic is there.

Any thoughts on how this code ended up in 4.4 and 4.4-forward (since the review 
request is just for master)? If that would have went out to the field, it would 
have rendered my plug-in completely useless.

Thanks!


- Mike


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


On June 18, 2014, 12:10 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22717/
> ---
> 
> (Updated June 18, 2014, 12:10 a.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski and Prachi Damle.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> refactor StoragePoolAllocator#filter logic to enable hypervisor type check, 
> storage type check for root volume and avoid list check, and to support IOPS 
> capacity control in a cluster wide storage pool and a local storage pool.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/AbstractStoragePoolAllocator.java
>  ddbb5a4 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java
>  8fb9c8d 
> 
> Diff: https://reviews.apache.org/r/22717/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>

Re: Review Request 22717: refactor StoragePoolAllocator#filter logic

[Yoshikazu Nojima]

> On June 27, 2014, 5:46 a.m., Mike Tutkowski wrote:
> > I first had a chance to run this patch through a sophisticated test tonight 
> > and noticed an issue with zone-wide primary storage that's based on the 
> > iSCSI protocol.
> > 
> > This patch leads to iSCSI storage being filtered out for ROOT volumes, 
> > which is a legitimate use case in my scenario.
> > 
> > As such, I had to return the filter method to the 
> > ZoneWideStoragePoolAllocator class.
> > 
> > I left in the other modification to the AbstractStoragePoolAllocator.
> 
> Yoshikazu Nojima wrote:
> I thought the root volume filtering logic weird, but I didn't dig into 
> the problem.
> Since this is a good opportunity, I would like to rethink this logic.
> which storage requires the root volume filtering logic?
> I understand that SolidFire's storage doesn't require it, but what about 
> other iSCSI storage?
> Is there any reason that other iSCSI storage cannot handle a root volume? 
> Does anyone know?
> Even if SolidFire's storage is the only iSCSI storage that can handle a 
> root volume, I think SolidFire's storage should be exempted from the 
> filtering logic not because storage is zone wide, but because storage is 
> SolidFire's.
>
> 
> Mike Tutkowski wrote:
> I'm pretty sure any vendor's iSCSI storage can handle root volumes as 
> it's just data placed on a disk. I don't know why that logic is there.
> 
> Any thoughts on how this code ended up in 4.4 and 4.4-forward (since the 
> review request is just for master)? If that would have went out to the field, 
> it would have rendered my plug-in completely useless.
> 
> Thanks!

Hi Mike,

What about reverting your latest 
commit(12e92e10ffbd9f86ebff11c2a1b22c5bafafb3d1) and removing root disk 
filtering logic for iSCSI storage in AbstractStoragePoolAllocator?
If you are OK, I'll make a commit.

Thanks.


- Yoshikazu


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


On June 18, 2014, 6:10 a.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22717/
> ---
> 
> (Updated June 18, 2014, 6:10 a.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski and Prachi Damle.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> refactor StoragePoolAllocator#filter logic to enable hypervisor type check, 
> storage type check for root volume and avoid list check, and to support IOPS 
> capacity control in a cluster wide storage pool and a local storage pool.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/AbstractStoragePoolAllocator.java
>  ddbb5a4 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/ZoneWideStoragePoolAllocator.java
>  8fb9c8d 
> 
> Diff: https://reviews.apache.org/r/22717/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Yoshikazu Nojima
> 
>