Re: [ACS44] Cherry pick 73330167228d14ea8494c9c1893627b6936626a7

[Daan Hoogland]

On Tue, Jun 3, 2014 at 8:02 PM, Nitin Mehta  wrote:
> 73330167228d14ea8494c9c1893627b6936626a7


is in

-- 
Daan

Re: [ACS44] cherry pick 5e80e5d33d9a295b91cdba9377f52d9d963d802a

[Daan Hoogland]

is in

On Tue, Jun 3, 2014 at 8:19 PM, Edison Su  wrote:
> If Vpc public network with snat enabled, mgt server will send down "vlan-id" 
> instead of "vlan://vlan-id" in ipassoccommand, which will cause issue on the 
> hypervisor resource to program VR.



-- 
Daan

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

[Daan Hoogland]

I read here that this commit is not needed. Can we think of scenarios
where it is?

On Tue, Jun 3, 2014 at 11:29 PM, Marcus  wrote:
> Your commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a actually does the fix
> mgmt server side and makes this patch irrelevant, as we are now passing a
> proper vlan:// in this command. However, Daan's fix will make the data in
> the db consistent for upgraders and fresh installers, which will fix this
> and all other bugs like it.
>
>
> On Tue, Jun 3, 2014 at 3:26 PM, Marcus  wrote:
>
>> I don't think that's the root cause, but it shouldn't hurt. The root cause
>> seems to be that we're telling the agent that the broadcastUri for the vlan
>> is 'vlan://100' (as reported by Anders), but the IpAssocCmd passes
>> broadcast URI as just '100'. This is a bit messy to workaround the mgmt
>> server inconsistency in the agent, but it won't hurt. Fixing the
>> inconsistency would be better, and Daan has applied a patch that should
>> blanket fix that during the 4.4 upgrade.
>>
>>
>> On Tue, Jun 3, 2014 at 2:44 PM, Edison Su  wrote:
>>
>>> Need to cherry pick it into 4.3.1 also.
>>>
>>> > -Original Message-
>>> > From: Edison Su [mailto:edison...@citrix.com]
>>> > Sent: Tuesday, June 03, 2014 1:37 PM
>>> > To: dev@cloudstack.apache.org
>>> > Subject: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd
>>> >
>>> > CLOUDSTACK-6464:
>>> > The root cause is that, in 3.0.x, if guest network is
>>> "vlan://untagged", then
>>> > kvm agent will use whatever value in "private.network.device", while in
>>> 4.x,
>>> > kvm agent will use "guest.network.device". So if both value are not the
>>> same
>>> > in the agent.properties, then kvm agent will use incorrect bridge to
>>> create vif.
>>> > The fix will be, kvm agent code needs to honor traffic type passed down
>>> > from mgt server in startcommand, in case of "vlan://untagged".
>>>
>>
>>



-- 
Daan

SSVM & CPVM Public IP not pinging

[Tejas Gadaria]

Hi,

I am trying to create setup with xenserver, where Storage,public,Guest &
Management traffic will be carried by 4 diff. nics & all are in different
VLAN.
After assigning the name-label in xen. System vm's are created but I am not
able ping to SSVM & CPVM public IP .

root@s-1-VM:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
default 10.129.152.10.0.0.0 UG0  00 eth2
google-public-d 10.129.151.1255.255.255.255 UGH   0  00 eth1
10.129.151.0*   255.255.255.0   U 0  00 eth1
10.129.152.0*   255.255.255.0   U 0  00 eth2
10.129.155.0*   255.255.255.0   U 0  00 eth3
link-local  *   255.255.0.0 U 0  00 eth0

root@s-1-VM:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 48 data bytes
56 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=64.948 ms
^C--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 64.948/64.948/64.948/0.000 ms

I am not able to ping to Storage from SSVM either.

Following below link right now.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM%2C+templates%2C+Secondary+storage+troubleshooting

Need help on this.

Regards,
Tejas

Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity

[Daan Hoogland]

I did, please check


On Wed, Jun 4, 2014 at 7:42 AM, Rajani Karuturi 
wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22193/
>
> On June 3rd, 2014, 11:07 a.m. UTC, *Santhosh Edukulla* wrote:
>
> Ship It!
>
>  Hi Hugo,
> Can you commit the latest patch as well which fixes the issue reported by 
> Santhosh.
>
>
> - Rajani
>
> On June 3rd, 2014, 11:02 a.m. UTC, Rajani Karuturi wrote:
>   Review request for cloudstack, Abhinandan Prateek, daan Hoogland, and
> Santhosh Edukulla.
> By Rajani Karuturi.
>
> *Updated June 3, 2014, 11:02 a.m.*
>  *Repository: * cloudstack-git
> Description
>
> The issue is reported by coverity scan @ 
> https://scan.coverity.com/projects/943
>
>   Diffs
>
>- engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java
>(7fe285f)
>
> View Diff 
>



-- 
Daan

Re: Review Request 22193: Fixed ResourceLeak on pstmtCidr in the function Upgrade430to440.moveCidrsToTheirOwnTable as reported by coverity

[Rajani Karuturi]

its in. closed the review request. thanks.

~Rajani



On 04-Jun-2014, at 1:13 pm, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:

I did, please check


On Wed, Jun 4, 2014 at 7:42 AM, Rajani Karuturi 
mailto:rajanikarut...@gmail.com>> wrote:
This is an automatically generated e-mail. To reply, visit: 
https://reviews.apache.org/r/22193/


On June 3rd, 2014, 11:07 a.m. UTC, Santhosh Edukulla wrote:

Ship It!

Hi Hugo,
Can you commit the latest patch as well which fixes the issue reported by 
Santhosh.


- Rajani


On June 3rd, 2014, 11:02 a.m. UTC, Rajani Karuturi wrote:

Review request for cloudstack, Abhinandan Prateek, daan Hoogland, and Santhosh 
Edukulla.
By Rajani Karuturi.

Updated June 3, 2014, 11:02 a.m.

Repository: cloudstack-git
Description

The issue is reported by coverity scan @ https://scan.coverity.com/projects/943


Diffs

  *   engine/schema/src/com/cloud/upgrade/dao/Upgrade430to440.java (7fe285f)

View Diff




--
Daan

Review Request 22226: Make set-eclipse-profile.sh work with bsd/mac sed

[Leo Simons]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

bsd/mac sed interprets wants -e to be completely clear that the next arg is the 
expression instead of an argument to -i.


Diffs
-

  tools/eclipse/set-eclipse-profile.sh 1abc662 

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


Testing
---

Successfully ran fixed script on stock mac install. Not tested on linux but 
this is common portability error so _should_ be fine.


Thanks,

Leo Simons

RE: Cpu, cpu speed and memory in usage records

[Harikrishna Patnala]

Hi,
We are recording the cpu and ram values in usage_vm_instance table while 
parsing the usage events. These details needs to be populated in cloud_usage 
table as well. Please feel free to file a ticket for this.

Thanks
Harikrishna
From: Olivier Lemasle [olivier.lema...@apalia.net]
Sent: Tuesday, June 03, 2014 8:54 PM
To: dev@cloudstack.apache.org
Cc: Harikrishna Patnala; Kishan Kavala
Subject: Cpu, cpu speed and memory in usage records

Hi,

Is it normal if CloudStack does not return usage details (cpu cores, cpu speed 
and memory) in the usage records?

Since the introduction of dynamic compute offerings, these details are recorded 
in table cloud_usage.usage_vm_instance, but they are not in table 
cloud_usage.cloud_usage, and they aren't returned by the "listUsageRecords" API 
command.

So, what was the purpose of these details in cloud_usage (CLOUDSTACK-4737, 
CLOUDSTACK-5515, CLOUDSTACK-6466)? It seems they're saved in database but never 
read. Am I wrong?

Thanks,

--
Olivier Lemasle
Software Engineer
Apalia™
Mobile: +33-611-69-12-11
http://www.apalia.net
olivier.lema...@apalia.net

Re: Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py

[Ashutosh Kelkar]

> On June 3, 2014, 12:27 p.m., Santhosh Edukulla wrote:
> > test/integration/smoke/test_non_contigiousvlan.py, line 47
> > 
> >
> > As well, can we run these changes once and see no issues if its 
> > possible?

Yes I did run it again after the changes.


> On June 3, 2014, 12:27 p.m., Santhosh Edukulla wrote:
> > test/integration/smoke/test_non_contigiousvlan.py, line 45
> > 
> >
> > It seems we are not reading test data. Can we check that?

It is not required here. As only test data the test case was earlier reading 
was vlan ids. And now we have removed that data and getting the free vlan ids 
through code from the setup.


- Ashutosh


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


On June 3, 2014, 11:45 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22197/
> ---
> 
> (Updated June 3, 2014, 11:45 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6776
> https://issues.apache.org/jira/browse/CLOUDSTACK-6776
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
>  The test case fails whenever hard coded values overlap with already 
> configured VLAN in the physical network. Removed hard code VLAN ids and used 
> the common function to get unused VLAN ids from the physical network 
> dynamically.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_non_contigiousvlan.py 90235ec 
> 
> Diff: https://reviews.apache.org/r/22197/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test to update a physical network and extend its vlan ... === TestName: 
> test_extendPhysicalNetworkVlan | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 15.328s
> 
> OK
> ~
> ~
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On June 3, 2014, 11:45 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22197/
> ---
> 
> (Updated June 3, 2014, 11:45 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6776
> https://issues.apache.org/jira/browse/CLOUDSTACK-6776
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
>  The test case fails whenever hard coded values overlap with already 
> configured VLAN in the physical network. Removed hard code VLAN ids and used 
> the common function to get unused VLAN ids from the physical network 
> dynamically.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_non_contigiousvlan.py 90235ec 
> 
> Diff: https://reviews.apache.org/r/22197/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test to update a physical network and extend its vlan ... === TestName: 
> test_extendPhysicalNetworkVlan | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 15.328s
> 
> OK
> ~
> ~
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: [DOCS] Problem generating 4.4 API docs

[sebgoa]

On Jun 2, 2014, at 9:16 PM, Will Stevens  wrote:

> I started playing with the 'javasphinx' project to see if it would work for 
> generating the API docs.
> 
> So here is the basic idea of what it produces.
> 
> I created docs for the following cloudstack directory: 
> 'api/src/org/apache/cloudstack/api/'
> 
> I then took the RST files and generated the html docs from it.  I got a lot 
> of errors like the following when trying to build the html docs with 
> 'sphinx-build':
> 
> ERROR: Unknown directive type "java:package"
> ERROR: Unknown directive type "java:import
> ERROR: Unknown directive type "java:type"
> ERROR: Unknown directive type "java:constructor"
> ERROR: Unknown directive type "java:method"
> etc...
> 
> I am not sure if this is a long term issue, but we will probably have to 
> solve other bigger problems first.
> 
> For example, here is the RST output for the CreateNetwork command for an 
> Admin:
> 
> .. java:import:: org.apache.log4j Logger
> 
> .. java:import:: org.apache.cloudstack.api APICommand
> 
> .. java:import:: org.apache.cloudstack.api ApiConstants
> 
> .. java:import:: org.apache.cloudstack.api ApiErrorCode
> 
> .. java:import:: org.apache.cloudstack.api Parameter
> 
> .. java:import:: org.apache.cloudstack.api ResponseObject.ResponseView
> 
> .. java:import:: org.apache.cloudstack.api ServerApiException
> 
> .. java:import:: org.apache.cloudstack.api.command.user.network 
> CreateNetworkCmd
> 
> .. java:import:: org.apache.cloudstack.api.response NetworkResponse
> 
> .. java:import:: com.cloud.exception ConcurrentOperationException
> 
> .. java:import:: com.cloud.exception InsufficientCapacityException
> 
> .. java:import:: com.cloud.exception ResourceAllocationException
> 
> .. java:import:: com.cloud.network Network
> 
> CreateNetworkCmdByAdmin
> ===
> 
> .. java:package:: org.apache.cloudstack.api.command.admin.network
>:noindex:
> 
> .. java:type:: @APICommand public class CreateNetworkCmdByAdmin extends 
> CreateNetworkCmd
> 
> Fields
> --
> s_logger
> 
> 
> .. java:field:: public static final Logger s_logger
>:outertype: CreateNetworkCmdByAdmin
> 
> Methods
> ---
> execute
> ^^^
> 
> .. java:method:: @Override public void execute() throws 
> InsufficientCapacityException, ConcurrentOperationException, 
> ResourceAllocationException
>:outertype: CreateNetworkCmdByAdmin
> 
> getVlan
> ^^^
> 
> .. java:method:: public String getVlan()
>:outertype: CreateNetworkCmdByAdmin
> 
> 
> I have also attached the themed output for this doc...
> 
> Obviously, this is not enough detail for us to use for actual API 
> documentation.
> 
> If we wanted to go with this sort of documentation, we would need to really 
> look at how the details are being discovered...
> 
> Do any of you have ideas or suggestions on this front?
> 

I got to the same stage as you,

Might not be worth pursuing. I will try to contact some of the 
javasphinx-developer and see what they say.

-sebastien

> Cheers,
> 
> Will
> 
> 
> 
> On Fri, May 30, 2014 at 4:33 PM, Sebastien Goasguen  wrote:
> 
> On May 30, 2014, at 4:25 PM, Will Stevens  wrote:
> 
> > By clean install you mean starting from scratch, not 'mvn clean install'
> > right?  I have been doing mvn clean installs…
> >
> 
> Will, quickly stated I think that piece of code is a nightmare + folks have 
> complained about our apidocs.
> 
> Since you are familiar with sphinx now, maybe you can give a try with:
> http://bronto.github.io/javasphinx/
> 
> Create some brand new api docs …that we can build automatically like the 
> regular docs.
> 
> 2 cts
> 
> > Will
> >
> >
> > On Fri, May 30, 2014 at 4:22 PM, Rohit Yadav  wrote:
> >
> >> Hi Will,
> >>
> >> Based on my last memories of the apidocs tool and maven poms, I think it
> >> used to scan built jar artifacts and reference them against something like
> >> a properties file (commands.properties?) and internally scans bunch of
> >> annotations in available class files to find apis and create apidocs. The
> >> ApiDiscovery plugin uses the same approach to discover available apis but
> >> during load time instead of build time.
> >>
> >> I would also recommend a clean install in case there are any caching
> >> issues. See if this helps.
> >>
> >> Regards.
> >>
> >>
> >> On Sat, May 31, 2014 at 1:14 AM, Will Stevens 
> >> wrote:
> >>
> >>> Hey All,
> >>> Paul Angus and I have both tested this and this is what we are seeing.
> >>>
> >>> When we compile the the 'master' branch, the docs in
> >>> 'tools/apidoc/target/xmldoc/html', but they appear to be the wrong docs.
> >>> Yes, we know that the versions that appear in the output is hardcoded in
> >>> the XSL files, but that is not what we are using as our reference.
> >>>
> >>> So in the 'tools/apidoc/pom.xml' the 4.4.0-SNAPSHOT is referenced.  I
> >> have
> >>> also confirmed that when a build is done, the
> >> 'tools/apidoc/log/@AGENTLOG@
> >>> '
> >>> shows that the
> >> 'client/target/cloud-client

Need help on the CS First class object hiding feature.

[Girish Chaudhari]

Hi Team,

I am looking into the CS first class object hiding feature to verify
how the Admin user has better control over the display of CS resources
to end users.

The only reference link I could find is
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+better+control+over+first+class+objects+in+CS

Is there any other documentation available around this feature
providing more use cases and examples..etc.

Whereas I have tried to verify this feature by creating the
resources(VM) by Admin and associated it with the account. In usual
case Account user as well the admin user can retrieve the VM using the
listVMs call. When I am trying to set the display_vm flag as false, as
expected the account user don't see the VM. But even the Admin user
can't see the VM in list.

Not sure whether I am following the right steps or its buggy behavior.

Also like to check whether Admin can update this feature flags or
provide the meta data through UI?

Curious to know whether anyone is using this feature in production and how?

Thanks,
Girish

Re: Control event publishing in multi region setups

[Alex Ough]

All,

Alex Huang, Alena and I had a conversation to find out the best solution
for one remaining issue,
which is to prevent the changes from being sent to remote regions even when
resource changes are occurred in the local region during FullScan
and these are what we decided.

1. A new parameter, 'originated_region_uuid', will be used to control the
flow
   - during the realtime sync, the value will be the uuid of the local
region to allow the changes to be transferred to remote regions,
   - during the full scan, the value will be the uuid of the remote region
to prevent them from being transferred to remote regions even if the change
was occurred in the local region.

2. To support this change, a new input param, 'originated_region_uuid',
will be added to all methods to manage user/account/domain in
AccountManager & DomainManager class.

3. To store the new input param value, a new field,
'originated_region_uuid', will be added to domain/account/user table and
they will be populated with the current local region uuid when the fields
are created during the schema changes because we can guarantee that the
current user/account/domain resources were created in the local region.

4. The API interfaces to manage the user/account/domain will have an
additional input param, 'originated_region_uuid', to support this change.

Please let me know if you have any comments.
Thanks
Alex Ough


On Mon, Jun 2, 2014 at 12:52 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>  Yes, I’m back. Please check with Alex Huang what time he can be on the
> call with you. I can join any time today/tomorrow.
>
>  -Alena.
>
>   From: Alex Ough 
> Date: Monday, June 2, 2014 at 9:49 AM
>
> To: Alena Prokharchyk 
> Cc: Alex Huang , Murali Reddy <
> murali.re...@citrix.com>, Kishan Kavala , "
> dev@cloudstack.apache.org" 
> Subject: Re: Control event publishing in multi region setups
>
>   Hi Alena,
>
>  Did you get back from the vacation?
> If so, let me know when it is the good time to discuss this.
>
>  Thanks
> Alex Ough
>
>
> On Thu, May 15, 2014 at 9:02 AM, Alex Ough 
> wrote:
>
>> I know. That's why I asked before Alex Huang to let me know when he's
>> available after he's coming back next week.
>>
>>  Have a good vacation.
>> Thanks
>>  Alex Ough
>>
>>
>> On Wed, May 14, 2014 at 4:21 PM, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wrote:
>>
>>>  Alex, I’m on vacation tomorrow; leaving today at 2 pm.
>>>
>>>  Thanks,
>>> Alena.
>>>
>>>   From: Alex Ough 
>>> Date: Wednesday, May 14, 2014 at 1:18 PM
>>>
>>> To: Alena Prokharchyk 
>>> Cc: Alex Huang , Murali Reddy <
>>> murali.re...@citrix.com>, Kishan Kavala , "
>>> dev@cloudstack.apache.org" 
>>> Subject: Re: Control event publishing in multi region setups
>>>
>>>   My meeting is being delayed, so let me know when you guys are
>>> available from tomorrow.
>>>
>>>  Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, May 14, 2014 at 3:05 PM, Alex Ough 
>>> wrote:
>>>
 I have a meeting in 20 min which is estimated to end 1pm PST, so I'll
 let you know once it is over.


 On Wed, May 14, 2014 at 3:01 PM, Alena Prokharchyk <
 alena.prokharc...@citrix.com> wrote:

>  Alex, sure we can have a call. I’m in the office till 2 pm PST
> today. Send the meeting invitation to me and Alex.
>
>   From: Alex Ough 
> Date: Wednesday, May 14, 2014 at 11:33 AM
>
> To: Alena Prokharchyk 
> Cc: Alex Huang , Murali Reddy <
> murali.re...@citrix.com>, Kishan Kavala , "
> dev@cloudstack.apache.org" 
> Subject: Re: Control event publishing in multi region setups
>
>   I think I forgot to mention this, but I think we should talk with
> Alex Huang also because you need his approval.
> So let me know when you guys are available and let's just stop sending
> emails back and forth.
>
>  Thanks
> Alex Ough
>
>
> On Wed, May 14, 2014 at 2:30 PM, Alex Ough 
> wrote:
>
>> Alena,
>>
>>  I think we should talk, so please let me know when you're available.
>>
>>  Thanks
>>  Alex Ough
>>
>>
>> On Wed, May 14, 2014 at 1:36 PM, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wrote:
>>
>>>  Alex, we do understand how “Full Scan” works and we know that your
>>> component/other components using Full Scan, should be able to 
>>> distinguish
>>> whether the event was generated locally or by another region.
>>>
>>>  Changing the event by enhancing it with “Local” flag is not a
>>> desired solution as its very specific to your feature, and we should 
>>> never
>>> modify the CS code just to satisfy only a certain plugin/service needs. 
>>> The
>>> same applies to introducing another method w/o event generation.  Both
>>> solutions are incorrect, and I’m against putting them to the CS.
>>>
>>>  Here are the rules that should apply to account/domain/user
>>> changes on the CS side:
>>>

RE: Marvin Question

[Santhosh Edukulla]

1. Check the config file you are providing input to nose, it should have 
"LogFolderPath" variable. For reference you can see setup/dev/advanced.cfg.

2. Below example should give an idea of running a test suite using nose.
 
nosetests-2.7 --with-marvin --marvin-config=setup/dev/advanced.cfg   
--with-xunit  --xunit-file=/tmp/test_offerings_out.xml  
test/integration/smoke/path_to_test_offerings.py -a tags=advanced --zone="zone" 
--hypervisor="xenserver" 

Thanks!
Santhosh

From: Mike Tutkowski [mike.tutkow...@solidfire.com]
Sent: Tuesday, June 03, 2014 3:14 PM
To: dev@cloudstack.apache.org
Subject: Marvin Question

Hi,

I've been playing around with Marvin lately.

I got it to build a CS cloud with one zone, one pod, one cluster, and two
hosts in it just fine.

I've been trying to run another script to create a Compute Offering, but
get the following error (below).

Perhaps I'm missing some piece of Marvin configuration?

Thanks!

Exception Occurred Under __initLogging :'list' object has no attribute
'LogFolderPath'

Traceback (most recent call last):

  File "/usr/local/bin/nosetests", line 8, in 

load_entry_point('nose==1.3.3', 'console_scripts', 'nosetests')()

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py", line
121, in __init__

**extra_args)

  File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/main.py",
line 95, in __init__

self.runTests()

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py", line
207, in runTests

result = self.testRunner.run(self.test)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py", line
62, in run

test(result)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py",
line 176, in __call__

return self.run(*arg, **kw)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py",
line 223, in run

test(orig)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py",
line 176, in __call__

return self.run(*arg, **kw)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py",
line 223, in run

test(orig)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/case.py", line
45, in __call__

return self.run(*arg, **kwarg)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/case.py", line
138, in run

result.addError(self, err)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/proxy.py",
line 124, in addError

plugin_handled = plugins.handleError(self.test, err)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/plugins/manager.py",
line 99, in __call__

return self.call(*arg, **kw)

  File
"/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/plugins/manager.py",
line 167, in simple

result = meth(*arg, **kw)

  File
"/Library/Python/2.7/site-packages/Marvin-0.1.0-py2.7.egg/marvin/marvinPlugin.py",
line 155, in handleError

self.tcRunLogger.fatal("%s: %s: %s" %

AttributeError: 'NoneType' object has no attribute 'fatal'


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

RE: Unable to upload SSL certificate

[Saksham Srivastava]

Adding Syed,

I debugged the issue and here are my findings:

The api is failing at CertServiceimpl: parseCertificate()

return (Certificate) certPem.readObject();

readObject method is failing.

I tried to use the certificate used in the test 
runUploadSslCertSelfSignedWithPassword and other tests in CertServiceTest.java
The following is the api call:

http://10.x.x.x:8096/client/api?command=uploadSslCert&certificate=-BEGIN+CERTIFICATE-%0AMIIDBjCCAe4CCQD5Q6qF5dVV0jANBgkqhkiG9w0BAQUFADBFMQswCQYDVQQGEwJB%0AVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0%0AcyBQdHkgTHRkMB4XDTEzMTAyMTEzNTgwNFoXDTE0MTAyMTEzNTgwNFowRTELMAkG%0AA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0%0AIFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB%0AAN%2F7lJtiEs68IC1ZPxY9NA34z9T4AU4LPS%2FkbQtuxx4X72XOBy%2By0cB%2FqdMD7JNV%0Ah8Mq4URDljhSDyVPdH%2F%2BjQr%2B7kWx2gNe2R%2FDCnd%2FmeVwwU30JJvpGVZXt%2BMTef5N%0AQAbSfDMsuT4FaUY80InbDd24HelrjwunPdY9wwKXO6zL2fLjyDRediiydxcx18Vb%0ADq1cm7DRi4mNkmA3RwBQMhxGp3VsfXJ4Hy2WTRCCCxWHZphAh3EUJGK3idum6%2F7j%0AHbAwpM%2Ft1kNWN8PZiYDZ1HbccgjmqB7Cub10BfB9g1RByiQ%2FC87o5cKtQha3uuXR%0AiBcHISoDydQrgxKgUpiqEF0CAwEAATANBgkqhkiG9w0BAQUFAAOCAQEASvulIaVb%0Azh8z2TysE6RFoYTAYIRXghFrmqCUyyQmUVTvs6vN8iaSXr%2BWMQJcpgXewWcFrDhr%0AmIcyRCvF91ZYb7q6lMZFSpE6u%2FSUGIEtxGUDAfbkbQdKYmrMcbggUUIvSzgUFisO%0AKr0H9PEO4AWtCCrtOJFc7jgu03Sv06wDxn9ghkyiBRnVkbAhoKfKnI179yKruJWR%0AA3ieEj0eFoUbeSH8hDkToj4ynpkAvEGoHjHG9j%2B8FJxy%2FPTjkyVPl1ykTs%2B2Jc1B%0ASnx8f2afdTenPWyyBm3wFuRZjEAJJLUO0kxM7E8hAwhGsr%2BXYanwcr1oA1dz6M3f%0Acq26lpjTH5ITwQ%3D%3D%0A-END+CERTIFICATE-%0A&privatekey=-BEGIN+RSA+PRIVATE+KEY-%0AProc-Type%3A+4%2CENCRYPTED%0ADEK-Info%3A+DES-EDE3-CBC%2CCCA6E4CB4C4039DD%0A%0ATaVCJtB0dE9xTZbX7GOaGJwwGHVAMjU1GbRIHf0jODdP%2BquZvbjklNqsw8Ozlia9%0Aq%2FG%2BUqtRJGlIPPLpce0YCrTo0P3eixZdMs0%2BhioAEJ4OLtL0SAC6b8q%2FgB6HRfAx%0ABvNg%2BumTqeF9YB68Tcuv%2F2g4VGKiaePQACyOzMdf7lGY7ojxoJCYZa1mfKb7jWrg%0AFLwmTtLLhNjb6CnOKo3klIef3A6zdutpgxF1gARzdRyXg4qCA3boYnwEptTOlJFu%0AovxbhDG9iuYYr4gXYSs1pLYptEC8J6iWpG%2Fqzkwfr4l5Cfg5uF00bbxQE5%2BWeRaj%0AYFicvXjB%2FkcoFZuCL7M%2FYRXYxkJ%2FEZ19xI9HZNBQ4L738StkSBKL4OhpF%2FqgYZ2y%0AZLRV6XT4AijUA0Ef7YTuUsTL7Qt9drj09gCtAzXTA7gpZBn5SqT9kWhuwSzY302l%0AKF8DIC6A52igk2QKPLbleM%2FV8eCu6n%2BJ4uF%2B0GwVRROuG7ThxAQiUlJKhoEYrndL%0AnzT7jHVLftjilhVWFu2On62bRf5t1QZuob%2B1AdK0ukvEIVsYnN4bnlAkc99Wi6C0%0AZJd9qW5L4A9XAC2gcjr3m0Rzw3RO%2Bk17faR8YfmTuJvGyBf5fnrSFoNkrninXQXp%0Ask0ajRi4PJ4XTswLyxjWRSt3egNsZBSKnVCibca%2FQoDEdZHSKXo2FlYiUYx8JHQX%0ASPUsLl9OQKC1W8%2F%2BReryqBLHCkiGEsvT8gVaXga0uhVaqe%2BPaVur2tbOHl4yCysC%0A%2BZlnKwsC84LQsUvpENdCh%2BD7E1I1Rao9IJMR6q9azKq8Ck63cOJ1fA9xSnxJGoCA%0AIlGLttlXrR32EtzYwEnlqf1nI%2FIqNQrAXQKrP5VPzHsgMFu5uD4OEZa92Q5cVTsz%0Aap%2F1UEqiJVYUt6nuA%2BaqOUlyjC0oNtYL%2FVO4DbHTFcHa8SI2cPSS6ebPMWPGHjUm%0Al9bWa6Q9iyplCYS6hinAVsAaLVjPi1Eu9Pc8rxFCmoiJYJju5NZuGI5UBK64dqcX%0AT6trWl0kB8QY63JtnrZaoStoSPImV5KVseUKDV8TM3Y76h1nLV3MSmAD1ivk9oKs%0AVKeVrDhZBWUq9Dqre%2F%2BlVGO0a2wo5VTR8hfpf8QkODPLeyNZNdfGKzkkFLuXa8V5%0AELhLQJ3FnbEU3NEvMwikV9MhP%2FELPTkZwJr%2FNKv%2B9JLs9eXtwz29I%2FQ8byQVrCCs%0AhAuDl0zHGRnqdpdSImeS2EXGx631zGMwSe8fhKelni5h6hXrXz52asr0k30BxWjf%0AWUn1uTInwVjWGy9B5j3mZlVDotFbvVAZgtR0IoFwihPl4VZd9oS13l%2BhMfrTy1YZ%0A8xFNg8ZqUQ0lSmKfOVqSBT0lP8tM8LuGxgY4cWluhsAQxR5Nl7wkundnqjcwEDDu%0AJz2rD54St1EZYGLDJZSfC7mpG2PgodsdeopQCTyFhHWa8s3caZ40GFOwaR%2B%2F5%2BYF%0A1oRvkR1Yr4qIS7KbX4xsaFfAA5b8QfLA74L05PAgDwKofam2GFAlAKHOcI6mexPq%0AaySON9MNdnXBNxs16mBJLzCX5ljQb0ilJildVEI3aVmABptM4ehEiw%3D%3D%0A-END+RSA+PRIVATE+KEY-%0A&password=test

and the api fails with "Invalid Certificate format. Expected X509 certificate"

Since all the tests pass, I am assuming a problem with the api encoding format.
Can someone point to a working api call for the same.

Thanks,
Saksham


-Original Message-
From: Sujaya Maiyya (Intern) [mailto:sujaya.mai...@citrix.com] 
Sent: Tuesday, June 3, 2014 2:36 PM
To: dev@cloudstack.apache.org
Cc: Vijay Venkatachalam
Subject: Unable to upload SSL certificate

Hi,
  I am trying to upload an SSL certificate to Cloudstack using uploadSslCert 
API since 4.3 version does not have UI support for the same. And I am getting 
following exception:
Invalid Certificate format. Expected X509 certificate

The certificate, private key and certificate-chain are URL encoded and sent to 
the Cloudstack using a GET on 8096 port. On debugging, it was found that some 
characters were missing from certificate after it was decoded from the URL 
which is the cause of the exception.

I am unable to figure out the reason, so can you please throw some light on why 
are some characters missing after decoding the certificate from the URL?

Thank you,
Sujaya

Review Request 22229: Test case failure in test_iso.py

[bharat kumar]

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

Review request for cloudstack, Abhinandan Prateek and Koushik Das.


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


Repository: cloudstack-git


Description
---

Hi,
there was a environment issue because of which the test suite was failing at 
setup. I fixed the env issue,
now the test suite runs on Xenserver but not on KVM (it fails at setup on KVM).

Also out of the 5 tests running on xen only 3 are passing. the failed tests are
integration.smoke.test_iso.TestISO.test_04_extract_Iso
integration.smoke.test_iso.TestISO.test_06_copy_iso

So disabling this suite until the above mentioned issues are fixed.


Diffs
-

  test/integration/smoke/test_iso.py a3e42f1 

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


Testing
---


Thanks,

bharat kumar

release procedure questions

[Daan Hoogland]

H,

I created a test release (wishfull thinking) using the command
> sh tools/build/build_asf.sh -b 4.4 -u dahn -v 4.4.0 -s 
> ~/cloudstack-4.4/cloudstack -c -t
it created a local branch called 4.4-RC20140604T1455 and a bunch of files
> ls -l /tmp/cloudstack-build/
total 15960
-rw-r--r--  1 daan  wheel  8158690 Jun  4 14:55
apache-cloudstack-4.4.0-src.tar.bz2
-rw-r--r--  1 daan  wheel  819 Jun  4 14:56
apache-cloudstack-4.4.0-src.tar.bz2.asc
-rw-r--r--  1 daan  wheel  123 Jun  4 14:56
apache-cloudstack-4.4.0-src.tar.bz2.md5
-rw-r--r--  1 daan  wheel  292 Jun  4 14:56
apache-cloudstack-4.4.0-src.tar.bz2.sha

This is a test run so test if you wish but no vote yet

There is a part of the release procedure not clear to me:

Committed revision 5485.
completed.  use commit-sh of c4494aae9f6b8ddebb0c1d018122cb2ee69425da
when starting the VOTE thread

what commit-sh should I use? or is it just a ref to the id of the
commit? (i have not pushed c4494aae9f6b8ddebb0c1d018122cb2ee69425da
yet)

-- 
Daan

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

[Marcus]

actually this specific commit isn't the one I thought it was. This one is a
relatively innocuous catch-all that forces things to the guest bridge if
all else fails. I'm not sure it will configure things 'right', but it will
help from things going on a protected network like mgmt if things fail.


On Wed, Jun 4, 2014 at 1:32 AM, Daan Hoogland 
wrote:

> I read here that this commit is not needed. Can we think of scenarios
> where it is?
>
> On Tue, Jun 3, 2014 at 11:29 PM, Marcus  wrote:
> > Your commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a actually does the
> fix
> > mgmt server side and makes this patch irrelevant, as we are now passing a
> > proper vlan:// in this command. However, Daan's fix will make the data in
> > the db consistent for upgraders and fresh installers, which will fix this
> > and all other bugs like it.
> >
> >
> > On Tue, Jun 3, 2014 at 3:26 PM, Marcus  wrote:
> >
> >> I don't think that's the root cause, but it shouldn't hurt. The root
> cause
> >> seems to be that we're telling the agent that the broadcastUri for the
> vlan
> >> is 'vlan://100' (as reported by Anders), but the IpAssocCmd passes
> >> broadcast URI as just '100'. This is a bit messy to workaround the mgmt
> >> server inconsistency in the agent, but it won't hurt. Fixing the
> >> inconsistency would be better, and Daan has applied a patch that should
> >> blanket fix that during the 4.4 upgrade.
> >>
> >>
> >> On Tue, Jun 3, 2014 at 2:44 PM, Edison Su  wrote:
> >>
> >>> Need to cherry pick it into 4.3.1 also.
> >>>
> >>> > -Original Message-
> >>> > From: Edison Su [mailto:edison...@citrix.com]
> >>> > Sent: Tuesday, June 03, 2014 1:37 PM
> >>> > To: dev@cloudstack.apache.org
> >>> > Subject: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd
> >>> >
> >>> > CLOUDSTACK-6464:
> >>> > The root cause is that, in 3.0.x, if guest network is
> >>> "vlan://untagged", then
> >>> > kvm agent will use whatever value in "private.network.device", while
> in
> >>> 4.x,
> >>> > kvm agent will use "guest.network.device". So if both value are not
> the
> >>> same
> >>> > in the agent.properties, then kvm agent will use incorrect bridge to
> >>> create vif.
> >>> > The fix will be, kvm agent code needs to honor traffic type passed
> down
> >>> > from mgt server in startcommand, in case of "vlan://untagged".
> >>>
> >>
> >>
>
>
>
> --
> Daan
>

Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template resource

[Namita Chaudhari]

Hi Santhosh,

I am unable to register a Template or ISO from UI on simulator. I get an
exception "Unable to register a template due to some missing parameters".
So I cannot proceed further and try to manually create tags on them.

Thanks and Regards,


On Tue, Jun 3, 2014 at 6:35 PM, Santhosh Edukulla <
santhosh.eduku...@citrix.com> wrote:

> Two things:
>
> 1. Is this feature of tagging iso or template available\supported in CS?
> What API we are using for it?
>
> 2. If this is supported feature, can you "manually" do it from UI on
> simulator and check if its working there?
>
> Thanks!
> Santhosh
> 
> From: Namita Chaudhari [namita.chaudh...@sungardas.com]
> Sent: Tuesday, June 03, 2014 8:51 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and
> Template resource
>
> Hi Santhosh,
>
> These are new test cases. On simulator and in same test case, I have
> created tags on various resources like volume, project, snapshot etc and
> they work perfectly fine.
> I face this issue only for ISO and Template resource tag creation.
>
> Thanks,
> Namita
>
>
> On Tue, Jun 3, 2014 at 6:16 PM, Santhosh Edukulla <
> santhosh.eduku...@citrix.com> wrote:
> Namita,
>
> 1. Just to separate this issue as simulator vs test code, can we just
> check from UI whether the objective of creating tags for simulator is
> possible there? If yes, then we can look in to test code.
>
> 2. As well, are these new tests or existing tests?
>
> Thanks!
> Santhosh
> 
> From: Namita Chaudhari [namita.chaudh...@sungardas.com namita.chaudh...@sungardas.com>]
> Sent: Tuesday, June 03, 2014 8:27 AM
> To: dev@cloudstack.apache.org
> Subject: [ACS4.4] [Issue] Unable to create a resource tag on ISO and
> Template resource
>
> Hi All,
>
> I was trying to create a resource tag on ISO and Template with a sample
> data for a test
> case. Can anyone help me toknow is there anything I'm missing in the input
> parameters ?
>
> For both resources, I get a db exception "Out of range value for column
> 'domain_id' at row 1" where the domainid gets value as -1.
>
>  I'm running this test on simulator.
>
> 1] For ISO:
>
> a) ISO in json
>
>
> iso1A": {
> "displaytext": "Dummy ISO",
> "name": "Dummy ISO",
> "url": "http://people.apache.org/~tsp/dummy.iso";,
> "zoneid": "9ecf9d8b-cf18-4322-a641-a1c0aced5857",
> # Source URL where ISO is located
> "isextractable": True,
> "isfeatured": True,
> "ispublic": False,
> "ostype": 'CentOS 5.3 (64-bit)',
> "mode": 'HTTP_DOWNLOAD',
> # Used in Extract template, value must be HTTP_DOWNLOAD
> },
>
>
> b) Creating an iso with its tag
>
>
> self.account_1A = Account.create(
>
> self.apiclient,
>
> self.services["account1A"],
>
> admin=False,
>
> domainid=self.domain_1.id<
> http://self.domain_1.id>
>
> )
>
>
>self.userapiclient_1A =
>
> self.testClient.getUserApiClient(self.user_1A.username,
>
> self.domain_1.name)
>
>
>
>
> self.iso1A = Iso.create(
>  self.apiclient,
>  self.services["iso"],
>  account=self.account_1A.name<
> http://self.account_1A.name>,
>  domainid=self.account_1A.domainid
>  )
> self.debug("ISO created with ID: %s" % self.iso1A.id<
> http://self.iso1A.id>)
>
> self.debug("Creating a tag for the ISO1A")
> self.resource_tag_1A = Tag.create(
>  self.apiclient,
>  resourceIds=self.iso1A.id<
> http://self.iso1A.id>,
>  resourceType='iso',
>  tags={'OS': 'CentOS'}
>
>
>  )
>
> 2] For Template :
>
>
> a) Template in json
>
> "template1A": {
> "displaytext": "Cent OS Template",
> "name": "Cent OS Template",
> "ostype": 'CentOS 5.3 (64-bit)',
> "templatefilter": 'self',
> },
>
> b ) Create template with tag.
>
> try:
> self.debug("Stopping the virtual machine: %s" %
> self.virtual_machine_1A.name<
> http://self.virtual_machine_1A.name>)
> #Stop virtual machine
> self.virtual_machine_1A.stop(self.apiclient)
> except Exception as e:
> self.fail("Failed to stop VM: %s" % e)
>
> timeou

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

[Marcus]

I see. My confusion lies in the fact that this commit is associated with
https://reviews.apache.org/r/21908/, which is not the right fix, but the
commit does not contain the review patch provided.

In fact, we *really* don't want to apply review 21908 now that we've
applied other fixes, as it is functionally incompatible with some of the
other commits, but these commits should be ok.


On Wed, Jun 4, 2014 at 8:13 AM, Marcus  wrote:

> actually this specific commit isn't the one I thought it was. This one is
> a relatively innocuous catch-all that forces things to the guest bridge if
> all else fails. I'm not sure it will configure things 'right', but it will
> help from things going on a protected network like mgmt if things fail.
>
>
> On Wed, Jun 4, 2014 at 1:32 AM, Daan Hoogland 
> wrote:
>
>> I read here that this commit is not needed. Can we think of scenarios
>> where it is?
>>
>> On Tue, Jun 3, 2014 at 11:29 PM, Marcus  wrote:
>> > Your commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a actually does the
>> fix
>> > mgmt server side and makes this patch irrelevant, as we are now passing
>> a
>> > proper vlan:// in this command. However, Daan's fix will make the data
>> in
>> > the db consistent for upgraders and fresh installers, which will fix
>> this
>> > and all other bugs like it.
>> >
>> >
>> > On Tue, Jun 3, 2014 at 3:26 PM, Marcus  wrote:
>> >
>> >> I don't think that's the root cause, but it shouldn't hurt. The root
>> cause
>> >> seems to be that we're telling the agent that the broadcastUri for the
>> vlan
>> >> is 'vlan://100' (as reported by Anders), but the IpAssocCmd passes
>> >> broadcast URI as just '100'. This is a bit messy to workaround the mgmt
>> >> server inconsistency in the agent, but it won't hurt. Fixing the
>> >> inconsistency would be better, and Daan has applied a patch that should
>> >> blanket fix that during the 4.4 upgrade.
>> >>
>> >>
>> >> On Tue, Jun 3, 2014 at 2:44 PM, Edison Su 
>> wrote:
>> >>
>> >>> Need to cherry pick it into 4.3.1 also.
>> >>>
>> >>> > -Original Message-
>> >>> > From: Edison Su [mailto:edison...@citrix.com]
>> >>> > Sent: Tuesday, June 03, 2014 1:37 PM
>> >>> > To: dev@cloudstack.apache.org
>> >>> > Subject: [ACS44]cherry-pick:
>> dfb59cd6cc0292a88cb619e53f34cdb713879ffd
>> >>> >
>> >>> > CLOUDSTACK-6464:
>> >>> > The root cause is that, in 3.0.x, if guest network is
>> >>> "vlan://untagged", then
>> >>> > kvm agent will use whatever value in "private.network.device",
>> while in
>> >>> 4.x,
>> >>> > kvm agent will use "guest.network.device". So if both value are not
>> the
>> >>> same
>> >>> > in the agent.properties, then kvm agent will use incorrect bridge to
>> >>> create vif.
>> >>> > The fix will be, kvm agent code needs to honor traffic type passed
>> down
>> >>> > from mgt server in startcommand, in case of "vlan://untagged".
>> >>>
>> >>
>> >>
>>
>>
>>
>> --
>> Daan
>>
>
>

Re: VPC's VR missing public NIC eth1

[Marcus]

That wasn't the patch I thought it was. Regarding
5e80e5d33d9a295b91cdba9377f52d9d963d802a, we should probably do that for
IpAssocCommand as well. I'm not sure we have the db fix in 4.3 yet, and so
a fix like this would be required for IpAssocCommand (and perhaps other
unfound things).


On Tue, Jun 3, 2014 at 3:22 PM, Marcus  wrote:

> Hmm.. ok. I guess we can apply the bandaid patch as well
>
>
> On Tue, Jun 3, 2014 at 12:16 PM, Edison Su  wrote:
>
>> I checked in a commit: 5e80e5d33d9a295b91cdba9377f52d9d963d802a, which
>> will fix some of the mess of vlan id.
>>
>> > -Original Message-
>> > From: Marcus [mailto:shadow...@gmail.com]
>> > Sent: Tuesday, June 03, 2014 9:57 AM
>> > To: Daan Hoogland
>> > Cc: dev
>> > Subject: Re: VPC's VR missing public NIC eth1
>> >
>> > Ok, thanks. It seems there are other cases where the Command being
>> > passed from the mgmt server has inconsistent broadcastUri as well, this
>> > should blanket fix them. In the meantime there's a growing group of 4.3
>> > upgraders who are getting pitchforks out over at CLOUDSTACK-6464, so we
>> > may want to have something in 4.3.1 too.
>> >
>> >
>> > On Tue, Jun 3, 2014 at 12:30 AM, Daan Hoogland > >
>> > wrote:
>> >
>> > > one clarification, I was not suggesting changing vlan://x back to x,
>> > > just the case where x==untagged. I had a little analog discussion with
>> > > Hugo and he convinced me that untagged has no special meaning in SDN
>> > > cases, maybe for vxlan. So the problem I saw is at least smaller then
>> > > in my mind.
>> > >
>> > > I have committed the db change to update 4.3.0 to 4.4.0. It will need
>> > > heavy testing. And I didn't extensively look into other tables that
>> > > need such a change. networks is the likely candidate but there may be
>> > > others.
>> > >
>> > >
>> > > On Mon, Jun 2, 2014 at 6:38 PM, Marcus  wrote:
>> > > > Just to recap... I was trying to review the issue in my head and
>> > > > thought
>> > > it
>> > > > might be useful to write it down.
>> > > >
>> > > > in 4.3 we got the BroadcastDomainType enum introduced, and many
>> > > > parts of
>> > > the
>> > > > code were changed to use that when dealing with the vlan id. This
>> > > > code, among other things, returns a vlan id in URI format,
>> > > > describing both the technology used to provide the virtual lan,
>> > > > along with the id. Along the
>> > > way
>> > > > this seems to have caused the value itself to be stored as a URI
>> > > > (still
>> > > not
>> > > > sure where, by whom, or if it was intentional). That was fine and
>> > > > seemed
>> > > to
>> > > > work after some fixing, until there was an upgrade done where the
>> > > existing
>> > > > database value was NOT in URI format. We had a few places where the
>> > > > code
>> > > was
>> > > > never changed to use BroadcastDomainType to 'normalize' the info
>> > > > from the database (e.g. the IpAssocVpcCommand the mgmt server
>> > > > constructs), so upgrades are broken.
>> > > >
>> > > > Most places in the code as it is now are working with a live value
>> > > > of 'vlan://x', regardless of whether the database has 'vlan://x' or
>> > > > just
>> > > 'x',
>> > > > thanks to this code it returns the same 'vlan://' for either stored
>> > > value.
>> > > > For these places it shouldn't matter if we fix the old databases to
>> > > > store 'vlan://x' or the 4.3 installs to go back to 'x'.
>> > > >
>> > > > However, there are a few places that are broken, like this
>> > > IpAssocVpcCommand
>> > > > the mgmt server creates and CLOUDSTACK-5505. If we switch the db
>> > > > value
>> > > back,
>> > > > we have to identify all of the outstanding ones and fix them. In
>> > > addition,
>> > > > new code since then may have perhaps assumed that the db value is
>> > > 'vlan://',
>> > > > and might have bothered to pass through the interpolation, so they
>> > > > may
>> > > break
>> > > > as well. If we had full coverage on the test suite it would be easy
>> > > > to change the value back in the DB of a 4.3 or 4.4 install and see
>> > > > what
>> > > breaks.
>> > > >
>> > > > If we don't switch the value back, and instead update old databases
>> > > > to
>> > > the
>> > > > current way, it fixes the immediate issue but we end up with code
>> > > > doing
>> > > the
>> > > > same thing in two different ways. Some places will be using the raw
>> > > > db
>> > > value
>> > > > and other places will be asking for it to be normalized, and both
>> > > > will
>> > > have
>> > > > the same result, which is kind of messy and prone to causing issues
>> > > > down
>> > > the
>> > > > road if something changes again to separate these two.
>> > > >
>> > > >
>> > > > On Mon, Jun 2, 2014 at 10:01 AM, Marcus 
>> > wrote:
>> > > >>
>> > > >> I'm not sure the KVM code needs to be changed, you're asking it to
>> > > >> deal with an inconsistency from the mgmt server. Don't you find it
>> > > >> odd that
>> > > one
>> > > >> Command from the mgmt server provides
>> > > >> broadcastUri="vlan://untag

Re: Review Request 21908: Fix for CLOUDSTACK-6464

[Marcus Sorensen]

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


let's be extra careful not to apply this patch now that the other fixes are in. 
This patch will break fresh 4.3 installs and is incompatible with the fixes for 
the upgrades.

- Marcus Sorensen


On May 26, 2014, 12:25 p.m., Anders Lannerbäck wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21908/
> ---
> 
> (Updated May 26, 2014, 12:25 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fix for CLOUDSTACK-6464.  This patch is against 4.3-branch.
> 
> The original code adds broadcastUri on the format "vlan://100", but later 
> looks for HashMap keys without the "vlan://" bit.  This causes new interfaces 
> be created with duplicate MACs and the routers become unusable.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  36382e3 
> 
> Diff: https://reviews.apache.org/r/21908/diff/
> 
> 
> Testing
> ---
> 
> Used to repair our production Cloudstack instance.
> 
> 
> Thanks,
> 
> Anders Lannerbäck
> 
>

Re: Review Request 21908: Fix for CLOUDSTACK-6464

[Anders Lannerbäck]

> On June 4, 2014, 2:29 p.m., Marcus Sorensen wrote:
> > let's be extra careful not to apply this patch now that the other fixes are 
> > in. This patch will break fresh 4.3 installs and is incompatible with the 
> > fixes for the upgrades.

Yes, this patch should be rejected now that a better fix is in.


- Anders


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


On May 26, 2014, 12:25 p.m., Anders Lannerbäck wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21908/
> ---
> 
> (Updated May 26, 2014, 12:25 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fix for CLOUDSTACK-6464.  This patch is against 4.3-branch.
> 
> The original code adds broadcastUri on the format "vlan://100", but later 
> looks for HashMap keys without the "vlan://" bit.  This causes new interfaces 
> be created with duplicate MACs and the routers become unusable.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  36382e3 
> 
> Diff: https://reviews.apache.org/r/21908/diff/
> 
> 
> Testing
> ---
> 
> Used to repair our production Cloudstack instance.
> 
> 
> Thanks,
> 
> Anders Lannerbäck
> 
>

Re: release procedure questions

[Chip Childers]

On Wed, Jun 04, 2014 at 03:31:47PM +0200, Daan Hoogland wrote:
> H,
> 
> I created a test release (wishfull thinking) using the command
> > sh tools/build/build_asf.sh -b 4.4 -u dahn -v 4.4.0 -s 
> > ~/cloudstack-4.4/cloudstack -c -t
> it created a local branch called 4.4-RC20140604T1455 and a bunch of files
> > ls -l /tmp/cloudstack-build/
> total 15960
> -rw-r--r--  1 daan  wheel  8158690 Jun  4 14:55
> apache-cloudstack-4.4.0-src.tar.bz2
> -rw-r--r--  1 daan  wheel  819 Jun  4 14:56
> apache-cloudstack-4.4.0-src.tar.bz2.asc
> -rw-r--r--  1 daan  wheel  123 Jun  4 14:56
> apache-cloudstack-4.4.0-src.tar.bz2.md5
> -rw-r--r--  1 daan  wheel  292 Jun  4 14:56
> apache-cloudstack-4.4.0-src.tar.bz2.sha
> 
> This is a test run so test if you wish but no vote yet
> 
> There is a part of the release procedure not clear to me:
> 
> Committed revision 5485.
> completed.  use commit-sh of c4494aae9f6b8ddebb0c1d018122cb2ee69425da
> when starting the VOTE thread
> 
> what commit-sh should I use? or is it just a ref to the id of the
> commit? (i have not pushed c4494aae9f6b8ddebb0c1d018122cb2ee69425da
> yet)
> 
> -- 
> Daan

The commit ID pushed out is the specific commit that has the pom.xml
version fixes in it.  If you look at git log -3 you'll see a version fix
(remove SNAPSHOT) and then another to put it back.

If you were doing this for real, after confirming you are happy with the
release artifact, you would push your 4.4 branch (which would contain
those 2 version related commits) to origin.

Make sense?

Re: Review Request 21908: Fix for CLOUDSTACK-6464

[ASF Subversion and Git Services]

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


Commit 91391e6779bd25b91a3ca4d014656e24592187eb in cloudstack's branch 
refs/heads/4.4 from Edison Su
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=91391e6 ]

CLOUDSTACK-6464: if guest network type is vlan://untagged, and traffic label is 
used, kvm agent needs to honor traffic label

(cherry picked from commit dfb59cd6cc0292a88cb619e53f34cdb713879ffd)


- ASF Subversion and Git Services


On May 26, 2014, 12:25 p.m., Anders Lannerbäck wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21908/
> ---
> 
> (Updated May 26, 2014, 12:25 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fix for CLOUDSTACK-6464.  This patch is against 4.3-branch.
> 
> The original code adds broadcastUri on the format "vlan://100", but later 
> looks for HashMap keys without the "vlan://" bit.  This causes new interfaces 
> be created with duplicate MACs and the routers become unusable.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  36382e3 
> 
> Diff: https://reviews.apache.org/r/21908/diff/
> 
> 
> Testing
> ---
> 
> Used to repair our production Cloudstack instance.
> 
> 
> Thanks,
> 
> Anders Lannerbäck
> 
>

Re: Need help on the CS First class object hiding feature.

[Nitin Mehta]

On 04/06/14 4:52 AM, "Girish Chaudhari" 
wrote:

>Hi Team,
>
>I am looking into the CS first class object hiding feature to verify
>how the Admin user has better control over the display of CS resources
>to end users.
>
>The only reference link I could find is
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+bet
>ter+control+over+first+class+objects+in+CS
>
>Is there any other documentation available around this feature
>providing more use cases and examples..etc.

This is the functional spec and should provide you most of the
information. I see that some more first class entities have gotten added
but the underlying concept remains the same.

>
>Whereas I have tried to verify this feature by creating the
>resources(VM) by Admin and associated it with the account. In usual
>case Account user as well the admin user can retrieve the VM using the
>listVMs call. When I am trying to set the display_vm flag as false, as
>expected the account user don't see the VM. But even the Admin user
>can't see the VM in list.
>
>Not sure whether I am following the right steps or its buggy behavior.

I would think that would be a bug. Please file it and I will try and look
into it.



>
>Also like to check whether Admin can update this feature flags or
>provide the meta data through UI?

Yes, admin can update the display flag during creation time or using
update apis. Check deployvm and updateVm apis

>
>Curious to know whether anyone is using this feature in production and
>how?
>
>Thanks,
>Girish

Re: [ACS44]cherry-pick: dfb59cd6cc0292a88cb619e53f34cdb713879ffd

[Daan Hoogland]

I had the same confusion as I inspected this id (from subject)
it is pulled in now.

On Wed, Jun 4, 2014 at 4:22 PM, Marcus  wrote:
> I see. My confusion lies in the fact that this commit is associated with
> https://reviews.apache.org/r/21908/, which is not the right fix, but the
> commit does not contain the review patch provided.
>
> In fact, we *really* don't want to apply review 21908 now that we've
> applied other fixes, as it is functionally incompatible with some of the
> other commits, but these commits should be ok.
>
>
> On Wed, Jun 4, 2014 at 8:13 AM, Marcus  wrote:
>
>> actually this specific commit isn't the one I thought it was. This one is
>> a relatively innocuous catch-all that forces things to the guest bridge if
>> all else fails. I'm not sure it will configure things 'right', but it will
>> help from things going on a protected network like mgmt if things fail.
>>
>>
>> On Wed, Jun 4, 2014 at 1:32 AM, Daan Hoogland 
>> wrote:
>>
>>> I read here that this commit is not needed. Can we think of scenarios
>>> where it is?
>>>
>>> On Tue, Jun 3, 2014 at 11:29 PM, Marcus  wrote:
>>> > Your commit 5e80e5d33d9a295b91cdba9377f52d9d963d802a actually does the
>>> fix
>>> > mgmt server side and makes this patch irrelevant, as we are now passing
>>> a
>>> > proper vlan:// in this command. However, Daan's fix will make the data
>>> in
>>> > the db consistent for upgraders and fresh installers, which will fix
>>> this
>>> > and all other bugs like it.
>>> >
>>> >
>>> > On Tue, Jun 3, 2014 at 3:26 PM, Marcus  wrote:
>>> >
>>> >> I don't think that's the root cause, but it shouldn't hurt. The root
>>> cause
>>> >> seems to be that we're telling the agent that the broadcastUri for the
>>> vlan
>>> >> is 'vlan://100' (as reported by Anders), but the IpAssocCmd passes
>>> >> broadcast URI as just '100'. This is a bit messy to workaround the mgmt
>>> >> server inconsistency in the agent, but it won't hurt. Fixing the
>>> >> inconsistency would be better, and Daan has applied a patch that should
>>> >> blanket fix that during the 4.4 upgrade.
>>> >>
>>> >>
>>> >> On Tue, Jun 3, 2014 at 2:44 PM, Edison Su 
>>> wrote:
>>> >>
>>> >>> Need to cherry pick it into 4.3.1 also.
>>> >>>
>>> >>> > -Original Message-
>>> >>> > From: Edison Su [mailto:edison...@citrix.com]
>>> >>> > Sent: Tuesday, June 03, 2014 1:37 PM
>>> >>> > To: dev@cloudstack.apache.org
>>> >>> > Subject: [ACS44]cherry-pick:
>>> dfb59cd6cc0292a88cb619e53f34cdb713879ffd
>>> >>> >
>>> >>> > CLOUDSTACK-6464:
>>> >>> > The root cause is that, in 3.0.x, if guest network is
>>> >>> "vlan://untagged", then
>>> >>> > kvm agent will use whatever value in "private.network.device",
>>> while in
>>> >>> 4.x,
>>> >>> > kvm agent will use "guest.network.device". So if both value are not
>>> the
>>> >>> same
>>> >>> > in the agent.properties, then kvm agent will use incorrect bridge to
>>> >>> create vif.
>>> >>> > The fix will be, kvm agent code needs to honor traffic type passed
>>> down
>>> >>> > from mgt server in startcommand, in case of "vlan://untagged".
>>> >>>
>>> >>
>>> >>
>>>
>>>
>>>
>>> --
>>> Daan
>>>
>>
>>



-- 
Daan

RE: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template resource

[Santhosh Edukulla]

Namitha,

Actually, my point is mainly to say that there is no provision available to tag 
an iso or template from CS. So, is the reason to inquire the below point "1". 
You may wanted to confirm  the below point on normal CS, with out simulator?  

1. Is this feature of tagging iso or template available\supported in CS? What 
API we are using for it?( check on normal CS with out simulator)

Santhosh

From: Namita Chaudhari [namita.chaudh...@sungardas.com]
Sent: Wednesday, June 04, 2014 10:14 AM
To: dev@cloudstack.apache.org
Subject: Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and 
Template resource

Hi Santhosh,

I am unable to register a Template or ISO from UI on simulator. I get an 
exception "Unable to register a template due to some missing parameters". So I 
cannot proceed further and try to manually create tags on them.

Thanks and Regards,


On Tue, Jun 3, 2014 at 6:35 PM, Santhosh Edukulla 
mailto:santhosh.eduku...@citrix.com>> wrote:
Two things:

1. Is this feature of tagging iso or template available\supported in CS? What 
API we are using for it?

2. If this is supported feature, can you "manually" do it from UI on simulator 
and check if its working there?

Thanks!
Santhosh

From: Namita Chaudhari 
[namita.chaudh...@sungardas.com]
Sent: Tuesday, June 03, 2014 8:51 AM
To: dev@cloudstack.apache.org
Subject: Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and 
Template resource

Hi Santhosh,

These are new test cases. On simulator and in same test case, I have created 
tags on various resources like volume, project, snapshot etc and they work 
perfectly fine.
I face this issue only for ISO and Template resource tag creation.

Thanks,
Namita


On Tue, Jun 3, 2014 at 6:16 PM, Santhosh Edukulla 
mailto:santhosh.eduku...@citrix.com>>>
 wrote:
Namita,

1. Just to separate this issue as simulator vs test code, can we just check 
from UI whether the objective of creating tags for simulator is possible there? 
If yes, then we can look in to test code.

2. As well, are these new tests or existing tests?

Thanks!
Santhosh

From: Namita Chaudhari 
[namita.chaudh...@sungardas.com>]
Sent: Tuesday, June 03, 2014 8:27 AM
To: 
dev@cloudstack.apache.org>
Subject: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template 
resource

Hi All,

I was trying to create a resource tag on ISO and Template with a sample data 
for a test
case. Can anyone help me toknow is there anything I'm missing in the input
parameters ?

For both resources, I get a db exception "Out of range value for column 
'domain_id' at row 1" where the domainid gets value as -1.

 I'm running this test on simulator.

1] For ISO:

a) ISO in json


iso1A": {
"displaytext": "Dummy ISO",
"name": "Dummy ISO",
"url": "http://people.apache.org/~tsp/dummy.iso";,
"zoneid": "9ecf9d8b-cf18-4322-a641-a1c0aced5857",
# Source URL where ISO is located
"isextractable": True,
"isfeatured": True,
"ispublic": False,
"ostype": 'CentOS 5.3 (64-bit)',
"mode": 'HTTP_DOWNLOAD',
# Used in Extract template, value must be HTTP_DOWNLOAD
},


b) Creating an iso with its tag


self.account_1A = Account.create(

self.apiclient,

self.services["account1A"],

admin=False,


domainid=self.domain_1.id

)


   self.userapiclient_1A =

self.testClient.getUserApiClient(self.user_1A.username,

self.domain_1.name)




self.iso1A = Iso.create(
 self.apiclient,
 self.services["iso"],
 
account=self.account_1A.name,
 domainid=self.account_1A.domainid
 )
self.debug("ISO created with ID: %s" % 
self.iso1A.id)

self.debug("Creating a tag for the ISO1A")
self.resource_tag_1A = Tag.create(
 self.apiclient,
 
resourceIds=self.iso1A.id<

Re: release procedure questions

[Daan Hoogland]

Does, but I changed build_asf.sh to create a branch an no longer
revert. this commit-sh is meant to be the id on my branch then. and it
is the one we vote on. Not some script that creates another commit.

So in the new situation the release branch x.y keeps the SNAPSHOT at
all times. In addition an x.y-RCT branch is created
and a x.y.z tag on the first commit in it.

I have pushed the release attempt I spoke about, so in theory I could
now send out the VOTE mail containing the commit id (aka commit-sh).
<-- me sounding sure but actually asking

On Wed, Jun 4, 2014 at 4:39 PM, Chip Childers  wrote:
> On Wed, Jun 04, 2014 at 03:31:47PM +0200, Daan Hoogland wrote:
>> H,
>>
>> I created a test release (wishfull thinking) using the command
>> > sh tools/build/build_asf.sh -b 4.4 -u dahn -v 4.4.0 -s 
>> > ~/cloudstack-4.4/cloudstack -c -t
>> it created a local branch called 4.4-RC20140604T1455 and a bunch of files
>> > ls -l /tmp/cloudstack-build/
>> total 15960
>> -rw-r--r--  1 daan  wheel  8158690 Jun  4 14:55
>> apache-cloudstack-4.4.0-src.tar.bz2
>> -rw-r--r--  1 daan  wheel  819 Jun  4 14:56
>> apache-cloudstack-4.4.0-src.tar.bz2.asc
>> -rw-r--r--  1 daan  wheel  123 Jun  4 14:56
>> apache-cloudstack-4.4.0-src.tar.bz2.md5
>> -rw-r--r--  1 daan  wheel  292 Jun  4 14:56
>> apache-cloudstack-4.4.0-src.tar.bz2.sha
>>
>> This is a test run so test if you wish but no vote yet
>>
>> There is a part of the release procedure not clear to me:
>>
>> Committed revision 5485.
>> completed.  use commit-sh of c4494aae9f6b8ddebb0c1d018122cb2ee69425da
>> when starting the VOTE thread
>>
>> what commit-sh should I use? or is it just a ref to the id of the
>> commit? (i have not pushed c4494aae9f6b8ddebb0c1d018122cb2ee69425da
>> yet)
>>
>> --
>> Daan
>
> The commit ID pushed out is the specific commit that has the pom.xml
> version fixes in it.  If you look at git log -3 you'll see a version fix
> (remove SNAPSHOT) and then another to put it back.
>
> If you were doing this for real, after confirming you are happy with the
> release artifact, you would push your 4.4 branch (which would contain
> those 2 version related commits) to origin.
>
> Make sense?



-- 
Daan

[GitHub] cloudstack-docs-install pull request: CentOS Link Broken

[alexhitchins]

GitHub user alexhitchins opened a pull request:

https://github.com/apache/cloudstack-docs-install/pull/14

CentOS Link Broken

CentOS ISO link is broken. When new versions come out older versions are 
archived. Linking to version 6 will pick up the latest 6.x version.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/alexhitchins/cloudstack-docs-install patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack-docs-install/pull/14.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #14


commit 03c58e9ded63ac7a8e25b05b0ecc0bd94db66b49
Author: Alex Hitchins 
Date:   2014-06-04T15:08:27Z

CentOS Link Broken

CentOS ISO link is broken. When new versions come out older versions are 
archived. Linking to version 6 will pick up the latest 6.x version.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: release procedure questions

[Chip Childers]

On Wed, Jun 04, 2014 at 04:57:18PM +0200, Daan Hoogland wrote:
> Does, but I changed build_asf.sh to create a branch an no longer
> revert. this commit-sh is meant to be the id on my branch then. and it
> is the one we vote on. Not some script that creates another commit.
> 
> So in the new situation the release branch x.y keeps the SNAPSHOT at
> all times. In addition an x.y-RCT branch is created
> and a x.y.z tag on the first commit in it.
> 
> I have pushed the release attempt I spoke about, so in theory I could
> now send out the VOTE mail containing the commit id (aka commit-sh).
> <-- me sounding sure but actually asking

I'm struggling to fully understand the comments above, so I'll try to
answer in a specific way:

The commit-sh that is included in the VOTE email needs to point to the
commit (doesn't matter what branch really) that is (1) being tagged and
(2) the exact contents that are extracted to become the release
artifact.

Make sense?

-chip

Re: release procedure questions

[Daan Hoogland]

ok, it does. i am now convinced I changed the right thing and enough.

On Wed, Jun 4, 2014 at 5:11 PM, Chip Childers  wrote:
> On Wed, Jun 04, 2014 at 04:57:18PM +0200, Daan Hoogland wrote:
>> Does, but I changed build_asf.sh to create a branch an no longer
>> revert. this commit-sh is meant to be the id on my branch then. and it
>> is the one we vote on. Not some script that creates another commit.
>>
>> So in the new situation the release branch x.y keeps the SNAPSHOT at
>> all times. In addition an x.y-RCT branch is created
>> and a x.y.z tag on the first commit in it.
>>
>> I have pushed the release attempt I spoke about, so in theory I could
>> now send out the VOTE mail containing the commit id (aka commit-sh).
>> <-- me sounding sure but actually asking
>
> I'm struggling to fully understand the comments above, so I'll try to
> answer in a specific way:
>
> The commit-sh that is included in the VOTE email needs to point to the
> commit (doesn't matter what branch really) that is (1) being tagged and
> (2) the exact contents that are extracted to become the release
> artifact.
>
> Make sense?
>
> -chip



-- 
Daan

Re: VPC's VR missing public NIC eth1

[Daan Hoogland]

Marcus,

I didn't do the db thing for 4.3 but it is idem-potent and can go in a
Upgrade430to431.java as well. This one doesn't exist yet.

On Wed, Jun 4, 2014 at 4:27 PM, Marcus  wrote:
> That wasn't the patch I thought it was. Regarding
> 5e80e5d33d9a295b91cdba9377f52d9d963d802a, we should probably do that for
> IpAssocCommand as well. I'm not sure we have the db fix in 4.3 yet, and so a
> fix like this would be required for IpAssocCommand (and perhaps other
> unfound things).
>
>
> On Tue, Jun 3, 2014 at 3:22 PM, Marcus  wrote:
>>
>> Hmm.. ok. I guess we can apply the bandaid patch as well
>>
>>
>> On Tue, Jun 3, 2014 at 12:16 PM, Edison Su  wrote:
>>>
>>> I checked in a commit: 5e80e5d33d9a295b91cdba9377f52d9d963d802a, which
>>> will fix some of the mess of vlan id.
>>>
>>> > -Original Message-
>>> > From: Marcus [mailto:shadow...@gmail.com]
>>> > Sent: Tuesday, June 03, 2014 9:57 AM
>>> > To: Daan Hoogland
>>> > Cc: dev
>>> > Subject: Re: VPC's VR missing public NIC eth1
>>> >
>>> > Ok, thanks. It seems there are other cases where the Command being
>>> > passed from the mgmt server has inconsistent broadcastUri as well, this
>>> > should blanket fix them. In the meantime there's a growing group of 4.3
>>> > upgraders who are getting pitchforks out over at CLOUDSTACK-6464, so we
>>> > may want to have something in 4.3.1 too.
>>> >
>>> >
>>> > On Tue, Jun 3, 2014 at 12:30 AM, Daan Hoogland
>>> > 
>>> > wrote:
>>> >
>>> > > one clarification, I was not suggesting changing vlan://x back to x,
>>> > > just the case where x==untagged. I had a little analog discussion
>>> > > with
>>> > > Hugo and he convinced me that untagged has no special meaning in SDN
>>> > > cases, maybe for vxlan. So the problem I saw is at least smaller then
>>> > > in my mind.
>>> > >
>>> > > I have committed the db change to update 4.3.0 to 4.4.0. It will need
>>> > > heavy testing. And I didn't extensively look into other tables that
>>> > > need such a change. networks is the likely candidate but there may be
>>> > > others.
>>> > >
>>> > >
>>> > > On Mon, Jun 2, 2014 at 6:38 PM, Marcus  wrote:
>>> > > > Just to recap... I was trying to review the issue in my head and
>>> > > > thought
>>> > > it
>>> > > > might be useful to write it down.
>>> > > >
>>> > > > in 4.3 we got the BroadcastDomainType enum introduced, and many
>>> > > > parts of
>>> > > the
>>> > > > code were changed to use that when dealing with the vlan id. This
>>> > > > code, among other things, returns a vlan id in URI format,
>>> > > > describing both the technology used to provide the virtual lan,
>>> > > > along with the id. Along the
>>> > > way
>>> > > > this seems to have caused the value itself to be stored as a URI
>>> > > > (still
>>> > > not
>>> > > > sure where, by whom, or if it was intentional). That was fine and
>>> > > > seemed
>>> > > to
>>> > > > work after some fixing, until there was an upgrade done where the
>>> > > existing
>>> > > > database value was NOT in URI format. We had a few places where the
>>> > > > code
>>> > > was
>>> > > > never changed to use BroadcastDomainType to 'normalize' the info
>>> > > > from the database (e.g. the IpAssocVpcCommand the mgmt server
>>> > > > constructs), so upgrades are broken.
>>> > > >
>>> > > > Most places in the code as it is now are working with a live value
>>> > > > of 'vlan://x', regardless of whether the database has 'vlan://x' or
>>> > > > just
>>> > > 'x',
>>> > > > thanks to this code it returns the same 'vlan://' for either stored
>>> > > value.
>>> > > > For these places it shouldn't matter if we fix the old databases to
>>> > > > store 'vlan://x' or the 4.3 installs to go back to 'x'.
>>> > > >
>>> > > > However, there are a few places that are broken, like this
>>> > > IpAssocVpcCommand
>>> > > > the mgmt server creates and CLOUDSTACK-5505. If we switch the db
>>> > > > value
>>> > > back,
>>> > > > we have to identify all of the outstanding ones and fix them. In
>>> > > addition,
>>> > > > new code since then may have perhaps assumed that the db value is
>>> > > 'vlan://',
>>> > > > and might have bothered to pass through the interpolation, so they
>>> > > > may
>>> > > break
>>> > > > as well. If we had full coverage on the test suite it would be easy
>>> > > > to change the value back in the DB of a 4.3 or 4.4 install and see
>>> > > > what
>>> > > breaks.
>>> > > >
>>> > > > If we don't switch the value back, and instead update old databases
>>> > > > to
>>> > > the
>>> > > > current way, it fixes the immediate issue but we end up with code
>>> > > > doing
>>> > > the
>>> > > > same thing in two different ways. Some places will be using the raw
>>> > > > db
>>> > > value
>>> > > > and other places will be asking for it to be normalized, and both
>>> > > > will
>>> > > have
>>> > > > the same result, which is kind of messy and prone to causing issues
>>> > > > down
>>> > > the
>>> > > > road if something changes again to separate these two.
>>> > > >
>>> > > >
>>> > > > On Mon

Re: VPC's VR missing public NIC eth1

[Daan Hoogland]

On Wed, Jun 4, 2014 at 4:27 PM, Marcus  wrote:
> Regarding 5e80e5d33d9a295b91cdba9377f52d9d963d802a, we should probably do
> that for IpAssocCommand as well.


I am feeling like in a spiral down. If the user input is fixed up
coming in it should probably be fixed down going out. when we save a
uri in the db we could still present the user with an id. Not when the
id can actually be an non vlan uri, however. This is going to take a
lot of work to get right. I doubt ipAssocCommand is going to be the
last one.

-- 
Daan

Access console VM via custom portal

[dimas yoga pratama]

Hello,
can anyone answer my question?

I create a custom web portal that provide some provisioning for user
I want user can access cloudstack VM from my web , but I kept gtting this
message: "Access denied. Invalid web session or API key in request"

I already pass the sessionkey like this :
http://10.151.32.11:8080/client/console?cmd=access&vm=018f88b2-4edc-4e6d-b318-3ec02029180f&sessionkey=d01AlQ2ZzwKBVqB2Rkj0qsHP/aw=


I google it and i found in order to access the console VM I need a token,
is there any easy way to access console VM from outside the MS? :(


thanks, please answer my question,
Dimas.

Re: Marvin Question

[Mike Tutkowski]

Hi Santhosh,

Thanks for the reply!

I usually send out a follow-up e-mail when I solve a problem after raising
a question on the mailing list; however, in this case, I forgot to do so.

As it turns out, I solved this problem the way you specified.

For some reason, I had removed the LogFolderPath variable and that was, in
fact, the problem.

Thanks!
Mike


On Wed, Jun 4, 2014 at 6:29 AM, Santhosh Edukulla <
santhosh.eduku...@citrix.com> wrote:

> 1. Check the config file you are providing input to nose, it should have
> "LogFolderPath" variable. For reference you can see setup/dev/advanced.cfg.
>
> 2. Below example should give an idea of running a test suite using nose.
>
> nosetests-2.7 --with-marvin --marvin-config=setup/dev/advanced.cfg
> --with-xunit  --xunit-file=/tmp/test_offerings_out.xml
>  test/integration/smoke/path_to_test_offerings.py -a tags=advanced
> --zone="zone" --hypervisor="xenserver"
>
> Thanks!
> Santhosh
> 
> From: Mike Tutkowski [mike.tutkow...@solidfire.com]
> Sent: Tuesday, June 03, 2014 3:14 PM
> To: dev@cloudstack.apache.org
> Subject: Marvin Question
>
> Hi,
>
> I've been playing around with Marvin lately.
>
> I got it to build a CS cloud with one zone, one pod, one cluster, and two
> hosts in it just fine.
>
> I've been trying to run another script to create a Compute Offering, but
> get the following error (below).
>
> Perhaps I'm missing some piece of Marvin configuration?
>
> Thanks!
>
> Exception Occurred Under __initLogging :'list' object has no attribute
> 'LogFolderPath'
>
> Traceback (most recent call last):
>
>   File "/usr/local/bin/nosetests", line 8, in 
>
> load_entry_point('nose==1.3.3', 'console_scripts', 'nosetests')()
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py", line
> 121, in __init__
>
> **extra_args)
>
>   File
>
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/main.py",
> line 95, in __init__
>
> self.runTests()
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py", line
> 207, in runTests
>
> result = self.testRunner.run(self.test)
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/core.py", line
> 62, in run
>
> test(result)
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py",
> line 176, in __call__
>
> return self.run(*arg, **kw)
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py",
> line 223, in run
>
> test(orig)
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py",
> line 176, in __call__
>
> return self.run(*arg, **kw)
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/suite.py",
> line 223, in run
>
> test(orig)
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/case.py", line
> 45, in __call__
>
> return self.run(*arg, **kwarg)
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/case.py", line
> 138, in run
>
> result.addError(self, err)
>
>   File
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/proxy.py",
> line 124, in addError
>
> plugin_handled = plugins.handleError(self.test, err)
>
>   File
>
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/plugins/manager.py",
> line 99, in __call__
>
> return self.call(*arg, **kw)
>
>   File
>
> "/Library/Python/2.7/site-packages/nose-1.3.3-py2.7.egg/nose/plugins/manager.py",
> line 167, in simple
>
> result = meth(*arg, **kw)
>
>   File
>
> "/Library/Python/2.7/site-packages/Marvin-0.1.0-py2.7.egg/marvin/marvinPlugin.py",
> line 155, in handleError
>
> self.tcRunLogger.fatal("%s: %s: %s" %
>
> AttributeError: 'NoneType' object has no attribute 'fatal'
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>



-- 
*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: [DISCUSS] Increasing VM IOPS by separating golden image in high IOPS partition in Xen Server ?

[Mike Tutkowski]

Daan helped out with this. You should be good to go now.


On Tue, Jun 3, 2014 at 8:50 PM, Hieu LE  wrote:

> Hi Mike,
>
> Could you please give edit/create permission on ASF Jira/Wiki confluence ?
> I can not add a new Wiki page.
>
> My Jira ID: hieulq
> Wiki: hieulq89
> Review Board: hieulq
>
> Thanks !
>
>
> On Wed, Jun 4, 2014 at 9:17 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
> > Hi,
> >
> > Yes, please feel free to add a new Wiki page for your design.
> >
> > Here is a link to applicable design info:
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design
> >
> > Also, feel free to ask more questions and have me review your design.
> >
> > Thanks!
> > Mike
> >
> >
> > On Tue, Jun 3, 2014 at 7:29 PM, Hieu LE  wrote:
> >
> > > Hi Mike,
> > >
> > > You are right, performance will be decreased over time because writes
> > IOPS
> > > will always end up on slower storage pool.
> > >
> > > In our case, we are using CloudStack integrated in VDI solution to
> > provived
> > > pooled VM type[1]. So may be my approach can bring better UX for user
> > with
> > > lower bootime ...
> > >
> > > A short change in design are followings
> > > - VM will be deployed with golden primary storage if primary storage is
> > > marked golden and this VM template is also marked as golden.
> > > - Choosing the best deploy destionation for both golden primary storage
> > and
> > > normal root volume primary storage. Chosen host can also access both
> > > storage pools.
> > > - New Xen Server plug-in for modifying VHD parent id.
> > >
> > > Is there some place for me to submit my design and code. Can I write a
> > new
> > > proposal in CS wiki ?
> > >
> > > [1]:
> > >
> > >
> >
> http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-choose-scheme-type-rho.html
> > >
> > >
> > > On Mon, Jun 2, 2014 at 9:04 PM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com
> > > > wrote:
> > >
> > > > It is an interesting idea. If the constraints you face at your
> company
> > > can
> > > > be corrected somewhat by implementing this, then you should go for
> it.
> > > >
> > > > It sounds like writes will be placed on the slower storage pool. This
> > > means
> > > > as you update OS components, those updates will be placed on the
> slower
> > > > storage pool. As such, your performance is likely to somewhat
> decrease
> > > over
> > > > time (as more and more writes end up on the slower storage pool).
> > > >
> > > > That may be OK for your use case(s), though.
> > > >
> > > > You'll have to update the storage-pool orchestration logic to take
> this
> > > new
> > > > scheme into account.
> > > >
> > > > Also, we'll have to figure out how this ties into storage tagging (if
> > at
> > > > all).
> > > >
> > > > I'd be happy to review your design and code.
> > > >
> > > >
> > > > On Mon, Jun 2, 2014 at 1:54 AM, Hieu LE  wrote:
> > > >
> > > > > Thanks Mike and Punith for quick reply.
> > > > >
> > > > > Both solutions you gave here are absolutely correct. But as I
> > mentioned
> > > > in
> > > > > the first email, I want another better solution for current
> > > > infrastructure
> > > > > at my company.
> > > > >
> > > > > Creating a high IOPS primary storage using storage tags is good but
> > it
> > > > will
> > > > > be very waste of disk capacity. For example, if I only have 1TB SSD
> > and
> > > > > deploy 100 VM from a 100GB template.
> > > > >
> > > > > So I think about a solution where a high IOPS primary storage can
> > only
> > > > > store golden image (master image), and a child image of this VM
> will
> > be
> > > > > stored in another normal (NFS, ISCSI...) storage. In this case,
> with
> > > 1TB
> > > > > SSD Primary Storage I can store as much golden image as I need.
> > > > >
> > > > > I have also tested it with 256 GB SSD mounted on Xen Server 6.2.0
> > with
> > > > 2TB
> > > > > local storage 1RPM, 6TB NFS share storage with 1GB network. The
> > > IOPS
> > > > of
> > > > > VMs which have golden image (master image) in SSD and child image
> in
> > > NFS
> > > > > increate more than 30-40% compare with VMs which have both golden
> > image
> > > > and
> > > > > child image in NFS. The boot time of each VM is also decrease.
> > ('cause
> > > > > golden image in SSD only reduced READ IOPS).
> > > > >
> > > > > Do you think this approach OK ?
> > > > >
> > > > >
> > > > > On Mon, Jun 2, 2014 at 12:50 PM, Mike Tutkowski <
> > > > > mike.tutkow...@solidfire.com> wrote:
> > > > >
> > > > > > Thanks, Punith - this is similar to what I was going to say.
> > > > > >
> > > > > > Any time a set of CloudStack volumes share IOPS from a common
> pool,
> > > you
> > > > > > cannot guarantee IOPS to a given CloudStack volume at a given
> time.
> > > > > >
> > > > > > Your choices at present are:
> > > > > >
> > > > > > 1) Use managed storage (where you can create a 1:1 mapping
> between
> > a
> > > > > > CloudStack volume and a volume on a storage system that has QoS).
> > As
> > > > > Punith
> > > > > 

Re: Control event publishing in multi region setups

[Alena Prokharchyk]

Alex, one more bullet is needed.

#5 During the DB upgrade all the account/domain/user records should be 
populated with “originated_region_uuid” = one of the regions in the system. The 
region should be picked using “region having smallest UUID” criteria.

-alena.

From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Wednesday, June 4, 2014 at 5:28 AM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Alex Huang mailto:alex.hu...@citrix.com>>, Murali 
Reddy mailto:murali.re...@citrix.com>>, Kishan Kavala 
mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: Control event publishing in multi region setups

All,

Alex Huang, Alena and I had a conversation to find out the best solution for 
one remaining issue,
which is to prevent the changes from being sent to remote regions even when 
resource changes are occurred in the local region during FullScan
and these are what we decided.

1. A new parameter, 'originated_region_uuid', will be used to control the flow
   - during the realtime sync, the value will be the uuid of the local region 
to allow the changes to be transferred to remote regions,
   - during the full scan, the value will be the uuid of the remote region to 
prevent them from being transferred to remote regions even if the change was 
occurred in the local region.

2. To support this change, a new input param, 'originated_region_uuid', will be 
added to all methods to manage user/account/domain in AccountManager & 
DomainManager class.

3. To store the new input param value, a new field, 'originated_region_uuid', 
will be added to domain/account/user table and they will be populated with the 
current local region uuid when the fields are created during the schema changes 
because we can guarantee that the current user/account/domain resources were 
created in the local region.

4. The API interfaces to manage the user/account/domain will have an additional 
input param, 'originated_region_uuid', to support this change.

Please let me know if you have any comments.
Thanks
Alex Ough


On Mon, Jun 2, 2014 at 12:52 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Yes, I’m back. Please check with Alex Huang what time he can be on the call 
with you. I can join any time today/tomorrow.

-Alena.

From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Monday, June 2, 2014 at 9:49 AM

To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Alex Huang mailto:alex.hu...@citrix.com>>, Murali 
Reddy mailto:murali.re...@citrix.com>>, Kishan Kavala 
mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: Control event publishing in multi region setups

Hi Alena,

Did you get back from the vacation?
If so, let me know when it is the good time to discuss this.

Thanks
Alex Ough


On Thu, May 15, 2014 at 9:02 AM, Alex Ough 
mailto:alex.o...@sungardas.com>> wrote:
I know. That's why I asked before Alex Huang to let me know when he's available 
after he's coming back next week.

Have a good vacation.
Thanks
Alex Ough


On Wed, May 14, 2014 at 4:21 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Alex, I’m on vacation tomorrow; leaving today at 2 pm.

Thanks,
Alena.

From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Wednesday, May 14, 2014 at 1:18 PM

To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Alex Huang mailto:alex.hu...@citrix.com>>, Murali 
Reddy mailto:murali.re...@citrix.com>>, Kishan Kavala 
mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: Control event publishing in multi region setups

My meeting is being delayed, so let me know when you guys are available from 
tomorrow.

Thanks
Alex Ough


On Wed, May 14, 2014 at 3:05 PM, Alex Ough 
mailto:alex.o...@sungardas.com>> wrote:
I have a meeting in 20 min which is estimated to end 1pm PST, so I'll let you 
know once it is over.


On Wed, May 14, 2014 at 3:01 PM, Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>> wrote:
Alex, sure we can have a call. I’m in the office till 2 pm PST today. Send the 
meeting invitation to me and Alex.

From: Alex Ough mailto:alex.o...@sungardas.com>>
Date: Wednesday, May 14, 2014 at 11:33 AM

To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: Alex Huang mailto:alex.hu...@citrix.com>>, Murali 
Reddy mailto:murali.re...@citrix.com>>, Kishan Kavala 
mailto:kishan.kav...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: Control event publishing in multi region setups

I think I forgot to mention this, but I think we should talk with Alex Huang 
also because you need his approval.
So let me know when you guys are available and let's just stop sending emails 
back and forth.

T

Re: Control event publishing in multi region setups

[Alex Ough]

I thought about this and I think it is better to save the local region uuid
because all resources are sure to be created in the local region, which is
#4.

Thanks
Alex Ough


On Wed, Jun 4, 2014 at 12:28 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>  Alex, one more bullet is needed.
>
>  #5 During the DB upgrade all the account/domain/user records should be
> populated with “originated_region_uuid” = one of the regions in the system.
> The region should be picked using “region having smallest UUID” criteria.
>
>  -alena.
>
>   From: Alex Ough 
> Date: Wednesday, June 4, 2014 at 5:28 AM
>
> To: Alena Prokharchyk 
> Cc: Alex Huang , Murali Reddy <
> murali.re...@citrix.com>, Kishan Kavala , "
> dev@cloudstack.apache.org" 
> Subject: Re: Control event publishing in multi region setups
>
>   All,
>
>  Alex Huang, Alena and I had a conversation to find out the best solution
> for one remaining issue,
> which is to prevent the changes from being sent to remote regions even
> when resource changes are occurred in the local region during FullScan
> and these are what we decided.
>
>  1. A new parameter, 'originated_region_uuid', will be used to control
> the flow
>- during the realtime sync, the value will be the uuid of the local
> region to allow the changes to be transferred to remote regions,
>- during the full scan, the value will be the uuid of the remote region
> to prevent them from being transferred to remote regions even if the change
> was occurred in the local region.
>
>  2. To support this change, a new input param, 'originated_region_uuid',
> will be added to all methods to manage user/account/domain in
> AccountManager & DomainManager class.
>
>  3. To store the new input param value, a new field,
> 'originated_region_uuid', will be added to domain/account/user table and
> they will be populated with the current local region uuid when the fields
> are created during the schema changes because we can guarantee that the
> current user/account/domain resources were created in the local region.
>
>  4. The API interfaces to manage the user/account/domain will have an
> additional input param, 'originated_region_uuid', to support this change.
>
>  Please let me know if you have any comments.
> Thanks
> Alex Ough
>
>
> On Mon, Jun 2, 2014 at 12:52 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>>  Yes, I’m back. Please check with Alex Huang what time he can be on the
>> call with you. I can join any time today/tomorrow.
>>
>>  -Alena.
>>
>>   From: Alex Ough 
>> Date: Monday, June 2, 2014 at 9:49 AM
>>
>> To: Alena Prokharchyk 
>> Cc: Alex Huang , Murali Reddy <
>> murali.re...@citrix.com>, Kishan Kavala , "
>> dev@cloudstack.apache.org" 
>> Subject: Re: Control event publishing in multi region setups
>>
>>   Hi Alena,
>>
>>  Did you get back from the vacation?
>> If so, let me know when it is the good time to discuss this.
>>
>>  Thanks
>> Alex Ough
>>
>>
>> On Thu, May 15, 2014 at 9:02 AM, Alex Ough 
>> wrote:
>>
>>> I know. That's why I asked before Alex Huang to let me know when he's
>>> available after he's coming back next week.
>>>
>>>  Have a good vacation.
>>> Thanks
>>>  Alex Ough
>>>
>>>
>>> On Wed, May 14, 2014 at 4:21 PM, Alena Prokharchyk <
>>> alena.prokharc...@citrix.com> wrote:
>>>
  Alex, I’m on vacation tomorrow; leaving today at 2 pm.

  Thanks,
 Alena.

   From: Alex Ough 
 Date: Wednesday, May 14, 2014 at 1:18 PM

 To: Alena Prokharchyk 
 Cc: Alex Huang , Murali Reddy <
 murali.re...@citrix.com>, Kishan Kavala , "
 dev@cloudstack.apache.org" 
 Subject: Re: Control event publishing in multi region setups

   My meeting is being delayed, so let me know when you guys are
 available from tomorrow.

  Thanks
 Alex Ough


 On Wed, May 14, 2014 at 3:05 PM, Alex Ough 
 wrote:

> I have a meeting in 20 min which is estimated to end 1pm PST, so I'll
> let you know once it is over.
>
>
> On Wed, May 14, 2014 at 3:01 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>>  Alex, sure we can have a call. I’m in the office till 2 pm PST
>> today. Send the meeting invitation to me and Alex.
>>
>>   From: Alex Ough 
>> Date: Wednesday, May 14, 2014 at 11:33 AM
>>
>> To: Alena Prokharchyk 
>> Cc: Alex Huang , Murali Reddy <
>> murali.re...@citrix.com>, Kishan Kavala , "
>> dev@cloudstack.apache.org" 
>> Subject: Re: Control event publishing in multi region setups
>>
>>   I think I forgot to mention this, but I think we should talk with
>> Alex Huang also because you need his approval.
>> So let me know when you guys are available and let's just stop
>> sending emails back and forth.
>>
>>  Thanks
>> Alex Ough
>>
>>
>> On Wed, May 14, 2014 at 2:30 PM, Alex Ough 
>> wrote:
>>
>>> Alena,
>>>
>>>  I think we should talk,

Re: Control event publishing in multi region setups

[Alena Prokharchyk]

But what if those resources are synced around regions prior to the
upgrade? With the approach you suggest, the same resource will have
different region id in each region¹s DB.

-Alena.

On 6/4/14, 9:33 AM, "Alex Ough"  wrote:

>I thought about this and I think it is better to save the local region
>uuid
>because all resources are sure to be created in the local region, which is
>#4.
>
>Thanks
>Alex Ough
>
>
>On Wed, Jun 4, 2014 at 12:28 PM, Alena Prokharchyk <
>alena.prokharc...@citrix.com> wrote:
>
>>  Alex, one more bullet is needed.
>>
>>  #5 During the DB upgrade all the account/domain/user records should be
>> populated with ³originated_region_uuid² = one of the regions in the
>>system.
>> The region should be picked using ³region having smallest UUID²
>>criteria.
>>
>>  -alena.
>>
>>   From: Alex Ough 
>> Date: Wednesday, June 4, 2014 at 5:28 AM
>>
>> To: Alena Prokharchyk 
>> Cc: Alex Huang , Murali Reddy <
>> murali.re...@citrix.com>, Kishan Kavala , "
>> dev@cloudstack.apache.org" 
>> Subject: Re: Control event publishing in multi region setups
>>
>>   All,
>>
>>  Alex Huang, Alena and I had a conversation to find out the best
>>solution
>> for one remaining issue,
>> which is to prevent the changes from being sent to remote regions even
>> when resource changes are occurred in the local region during FullScan
>> and these are what we decided.
>>
>>  1. A new parameter, 'originated_region_uuid', will be used to control
>> the flow
>>- during the realtime sync, the value will be the uuid of the local
>> region to allow the changes to be transferred to remote regions,
>>- during the full scan, the value will be the uuid of the remote
>>region
>> to prevent them from being transferred to remote regions even if the
>>change
>> was occurred in the local region.
>>
>>  2. To support this change, a new input param, 'originated_region_uuid',
>> will be added to all methods to manage user/account/domain in
>> AccountManager & DomainManager class.
>>
>>  3. To store the new input param value, a new field,
>> 'originated_region_uuid', will be added to domain/account/user table and
>> they will be populated with the current local region uuid when the
>>fields
>> are created during the schema changes because we can guarantee that the
>> current user/account/domain resources were created in the local region.
>>
>>  4. The API interfaces to manage the user/account/domain will have an
>> additional input param, 'originated_region_uuid', to support this
>>change.
>>
>>  Please let me know if you have any comments.
>> Thanks
>> Alex Ough
>>
>>
>> On Mon, Jun 2, 2014 at 12:52 PM, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wrote:
>>
>>>  Yes, I¹m back. Please check with Alex Huang what time he can be on the
>>> call with you. I can join any time today/tomorrow.
>>>
>>>  -Alena.
>>>
>>>   From: Alex Ough 
>>> Date: Monday, June 2, 2014 at 9:49 AM
>>>
>>> To: Alena Prokharchyk 
>>> Cc: Alex Huang , Murali Reddy <
>>> murali.re...@citrix.com>, Kishan Kavala , "
>>> dev@cloudstack.apache.org" 
>>> Subject: Re: Control event publishing in multi region setups
>>>
>>>   Hi Alena,
>>>
>>>  Did you get back from the vacation?
>>> If so, let me know when it is the good time to discuss this.
>>>
>>>  Thanks
>>> Alex Ough
>>>
>>>
>>> On Thu, May 15, 2014 at 9:02 AM, Alex Ough 
>>> wrote:
>>>
 I know. That's why I asked before Alex Huang to let me know when he's
 available after he's coming back next week.

  Have a good vacation.
 Thanks
  Alex Ough


 On Wed, May 14, 2014 at 4:21 PM, Alena Prokharchyk <
 alena.prokharc...@citrix.com> wrote:

>  Alex, I¹m on vacation tomorrow; leaving today at 2 pm.
>
>  Thanks,
> Alena.
>
>   From: Alex Ough 
> Date: Wednesday, May 14, 2014 at 1:18 PM
>
> To: Alena Prokharchyk 
> Cc: Alex Huang , Murali Reddy <
> murali.re...@citrix.com>, Kishan Kavala , "
> dev@cloudstack.apache.org" 
> Subject: Re: Control event publishing in multi region setups
>
>   My meeting is being delayed, so let me know when you guys are
> available from tomorrow.
>
>  Thanks
> Alex Ough
>
>
> On Wed, May 14, 2014 at 3:05 PM, Alex Ough 
> wrote:
>
>> I have a meeting in 20 min which is estimated to end 1pm PST, so
>>I'll
>> let you know once it is over.
>>
>>
>> On Wed, May 14, 2014 at 3:01 PM, Alena Prokharchyk <
>> alena.prokharc...@citrix.com> wrote:
>>
>>>  Alex, sure we can have a call. I¹m in the office till 2 pm PST
>>> today. Send the meeting invitation to me and Alex.
>>>
>>>   From: Alex Ough 
>>> Date: Wednesday, May 14, 2014 at 11:33 AM
>>>
>>> To: Alena Prokharchyk 
>>> Cc: Alex Huang , Murali Reddy <
>>> murali.re...@citrix.com>, Kishan Kavala
>>>, "
>>> dev@cloudstack.apache.org" 
>>> Subject: Re: Control event publishing in multi region setups
>>>
>>>   I think

Re: Control event publishing in multi region setups

[Alex Ough]

That information will be updated whenever its resource is changed, so the
prior value is not quite meaningful.
And as far as I know, there is no synchronization currently working, so all
the resources in a region must have been created in the local region.


On Wed, Jun 4, 2014 at 12:36 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> But what if those resources are synced around regions prior to the
> upgrade? With the approach you suggest, the same resource will have
> different region id in each region¹s DB.
>
> -Alena.
>
> On 6/4/14, 9:33 AM, "Alex Ough"  wrote:
>
> >I thought about this and I think it is better to save the local region
> >uuid
> >because all resources are sure to be created in the local region, which is
> >#4.
> >
> >Thanks
> >Alex Ough
> >
> >
> >On Wed, Jun 4, 2014 at 12:28 PM, Alena Prokharchyk <
> >alena.prokharc...@citrix.com> wrote:
> >
> >>  Alex, one more bullet is needed.
> >>
> >>  #5 During the DB upgrade all the account/domain/user records should be
> >> populated with ³originated_region_uuid² = one of the regions in the
> >>system.
> >> The region should be picked using ³region having smallest UUID²
> >>criteria.
> >>
> >>  -alena.
> >>
> >>   From: Alex Ough 
> >> Date: Wednesday, June 4, 2014 at 5:28 AM
> >>
> >> To: Alena Prokharchyk 
> >> Cc: Alex Huang , Murali Reddy <
> >> murali.re...@citrix.com>, Kishan Kavala , "
> >> dev@cloudstack.apache.org" 
> >> Subject: Re: Control event publishing in multi region setups
> >>
> >>   All,
> >>
> >>  Alex Huang, Alena and I had a conversation to find out the best
> >>solution
> >> for one remaining issue,
> >> which is to prevent the changes from being sent to remote regions even
> >> when resource changes are occurred in the local region during FullScan
> >> and these are what we decided.
> >>
> >>  1. A new parameter, 'originated_region_uuid', will be used to control
> >> the flow
> >>- during the realtime sync, the value will be the uuid of the local
> >> region to allow the changes to be transferred to remote regions,
> >>- during the full scan, the value will be the uuid of the remote
> >>region
> >> to prevent them from being transferred to remote regions even if the
> >>change
> >> was occurred in the local region.
> >>
> >>  2. To support this change, a new input param, 'originated_region_uuid',
> >> will be added to all methods to manage user/account/domain in
> >> AccountManager & DomainManager class.
> >>
> >>  3. To store the new input param value, a new field,
> >> 'originated_region_uuid', will be added to domain/account/user table and
> >> they will be populated with the current local region uuid when the
> >>fields
> >> are created during the schema changes because we can guarantee that the
> >> current user/account/domain resources were created in the local region.
> >>
> >>  4. The API interfaces to manage the user/account/domain will have an
> >> additional input param, 'originated_region_uuid', to support this
> >>change.
> >>
> >>  Please let me know if you have any comments.
> >> Thanks
> >> Alex Ough
> >>
> >>
> >> On Mon, Jun 2, 2014 at 12:52 PM, Alena Prokharchyk <
> >> alena.prokharc...@citrix.com> wrote:
> >>
> >>>  Yes, I¹m back. Please check with Alex Huang what time he can be on the
> >>> call with you. I can join any time today/tomorrow.
> >>>
> >>>  -Alena.
> >>>
> >>>   From: Alex Ough 
> >>> Date: Monday, June 2, 2014 at 9:49 AM
> >>>
> >>> To: Alena Prokharchyk 
> >>> Cc: Alex Huang , Murali Reddy <
> >>> murali.re...@citrix.com>, Kishan Kavala , "
> >>> dev@cloudstack.apache.org" 
> >>> Subject: Re: Control event publishing in multi region setups
> >>>
> >>>   Hi Alena,
> >>>
> >>>  Did you get back from the vacation?
> >>> If so, let me know when it is the good time to discuss this.
> >>>
> >>>  Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Thu, May 15, 2014 at 9:02 AM, Alex Ough 
> >>> wrote:
> >>>
>  I know. That's why I asked before Alex Huang to let me know when he's
>  available after he's coming back next week.
> 
>   Have a good vacation.
>  Thanks
>   Alex Ough
> 
> 
>  On Wed, May 14, 2014 at 4:21 PM, Alena Prokharchyk <
>  alena.prokharc...@citrix.com> wrote:
> 
> >  Alex, I¹m on vacation tomorrow; leaving today at 2 pm.
> >
> >  Thanks,
> > Alena.
> >
> >   From: Alex Ough 
> > Date: Wednesday, May 14, 2014 at 1:18 PM
> >
> > To: Alena Prokharchyk 
> > Cc: Alex Huang , Murali Reddy <
> > murali.re...@citrix.com>, Kishan Kavala ,
> "
> > dev@cloudstack.apache.org" 
> > Subject: Re: Control event publishing in multi region setups
> >
> >   My meeting is being delayed, so let me know when you guys are
> > available from tomorrow.
> >
> >  Thanks
> > Alex Ough
> >
> >
> > On Wed, May 14, 2014 at 3:05 PM, Alex Ough 
> > wrote:
> >
> >> I have a meeting in 20 min which is estimated to end 1pm PST, so
> >>I'll
> >> 

Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and Template resource

[Min Chen]

Santhosh,

The API command to create a resource tag is createTagsCmd. From just
ResourceObjectType enum listed in ResourceTag interface, Template/ISO is
supported.

Thanks
-min


On 6/4/14 7:57 AM, "Santhosh Edukulla" 
wrote:

>Namitha,
>
>Actually, my point is mainly to say that there is no provision available
>to tag an iso or template from CS. So, is the reason to inquire the below
>point "1". You may wanted to confirm  the below point on normal CS, with
>out simulator?  
>
>1. Is this feature of tagging iso or template available\supported in CS?
>What API we are using for it?( check on normal CS with out simulator)
>
>Santhosh
>
>From: Namita Chaudhari [namita.chaudh...@sungardas.com]
>Sent: Wednesday, June 04, 2014 10:14 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and
>Template resource
>
>Hi Santhosh,
>
>I am unable to register a Template or ISO from UI on simulator. I get an
>exception "Unable to register a template due to some missing parameters".
>So I cannot proceed further and try to manually create tags on them.
>
>Thanks and Regards,
>
>
>On Tue, Jun 3, 2014 at 6:35 PM, Santhosh Edukulla
>mailto:santhosh.eduku...@citrix.com>> wrote:
>Two things:
>
>1. Is this feature of tagging iso or template available\supported in CS?
>What API we are using for it?
>
>2. If this is supported feature, can you "manually" do it from UI on
>simulator and check if its working there?
>
>Thanks!
>Santhosh
>
>From: Namita Chaudhari
>[namita.chaudh...@sungardas.com]
>Sent: Tuesday, June 03, 2014 8:51 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [ACS4.4] [Issue] Unable to create a resource tag on ISO and
>Template resource
>
>Hi Santhosh,
>
>These are new test cases. On simulator and in same test case, I have
>created tags on various resources like volume, project, snapshot etc and
>they work perfectly fine.
>I face this issue only for ISO and Template resource tag creation.
>
>Thanks,
>Namita
>
>
>On Tue, Jun 3, 2014 at 6:16 PM, Santhosh Edukulla
>mailto:santhosh.eduku...@citrix.com>santhosh.eduku...@citrix.com>> wrote:
>Namita,
>
>1. Just to separate this issue as simulator vs test code, can we just
>check from UI whether the objective of creating tags for simulator is
>possible there? If yes, then we can look in to test code.
>
>2. As well, are these new tests or existing tests?
>
>Thanks!
>Santhosh
>
>From: Namita Chaudhari
>[namita.chaudh...@sungardas.comlto:namita.chaudh...@sungardas.com>
>]
>Sent: Tuesday, June 03, 2014 8:27 AM
>To: 
>dev@cloudstack.apache.orgudstack.apache.org>
>Subject: [ACS4.4] [Issue] Unable to create a resource tag on ISO and
>Template resource
>
>Hi All,
>
>I was trying to create a resource tag on ISO and Template with a sample
>data for a test
>case. Can anyone help me toknow is there anything I'm missing in the input
>parameters ?
>
>For both resources, I get a db exception "Out of range value for column
>'domain_id' at row 1" where the domainid gets value as -1.
>
> I'm running this test on simulator.
>
>1] For ISO:
>
>a) ISO in json
>
>
>iso1A": {
>"displaytext": "Dummy ISO",
>"name": "Dummy ISO",
>"url": "http://people.apache.org/~tsp/dummy.iso";,
>"zoneid": "9ecf9d8b-cf18-4322-a641-a1c0aced5857",
># Source URL where ISO is located
>"isextractable": True,
>"isfeatured": True,
>"ispublic": False,
>"ostype": 'CentOS 5.3 (64-bit)',
>"mode": 'HTTP_DOWNLOAD',
># Used in Extract template, value must be HTTP_DOWNLOAD
>},
>
>
>b) Creating an iso with its tag
>
>
>self.account_1A = Account.create(
>
>self.apiclient,
>
>self.services["account1A"],
>
>admin=False,
>
>  
>domainid=self.domain_1.id>
>
>)
>
>
>   self.userapiclient_1A =
>
>self.testClient.getUserApiClient(self.user_1A.username,
>
>self.domain_1.namettp://self.domain_1.name/>)
>
>
>
>
>self.iso1A = Iso.create(
> self.apiclient,
> self.services["iso"],
>  
>account=self.account_1A.nameunt_1A.name>,
> domainid=self.account_1A.domainid
>   

Re: Spectacular networking fail with KVM Adv zone - can someone address this bug?

[Pierre-Luc Dion]

Hi,
If I may step in, what would be the resolution here for the upgrade
process?  Would it make sense to have instuction or notes related to this
behavior in the release notes?


Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
855-OK-CLOUD (855-652-5683) x1101
- - -

*CloudOps*420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_


On Tue, Jun 3, 2014 at 5:41 PM, Nux!  wrote:

> On 03.06.2014 22:23, Marcus wrote:
>
>> Edison applied it for some reason, I guess it won't hurt anything.
>>
>
> That's fantastisch, thanks guys. Wonder how this was not caught sooner.
> Anyway, good job!
>
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

Re: seeing "Unknown parameters : ctxdetails" for addResourceDetail/removeResourceDetail

[Alena Prokharchyk]

Hi Antonio,

Sorry for the late reply. “ctxdetails” is used in ApiServer, so its not an 
unknown parameter. So the warning is not legitimate. Can you please fix it?

Thanks,
Alena.

From: Antonio Fornié Casarrubios 
mailto:antonio.for...@gmail.com>>
Date: Tuesday, May 13, 2014 at 2:34 PM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: seeing "Unknown parameters : ctxdetails" for 
addResourceDetail/removeResourceDetail

Hi all and sorry for the delay in the reply. Let me try to answer to different 
subjects mentioned here.

What is this functionality? It's just a server side check for the format of the 
requests, specifically for the received parameters. That's not something 
strange, there are many communication protocols that include (or can include) 
server side validation (for example, based on a xsd, dtd...). In those cases 
that would make the request completely fail. In our case, we just log it as 
warning.

My understanding is that an ideal solution is not to change this check, but to 
change the format of the requests so that it doesn't include parameters that 
will not be used. Actually, from the client point of view, if you send a 
parameter and you don't get any error or warning, that means that the parameter 
is used, right? But there are cases (like a parameter that was called 
listAll??) in which you could wonder why changing the value for that parameter 
doesn't affect the result, and you don't know that the parameter doesn't even 
exist on the server functionality.



When should a parameter be considered unknown? Any parameter that is not used - 
There are parameters that are not command specific, they are used in ApiServer, 
ApiServlet or any other"Api related class" and thus cannot be considered 
unknown : they are needed. There are also parameters that are part of the given 
command in a certain request. If you go to the code of this command you will 
see them. For example, for UpdateNetworkServiceProviderCmd, there are several 
private fields annotated as parameters not only in this class itself, but also 
the parameters inherited from BaseAsyncCmd and BaseCmd. These are also needed. 
Any other command will not be used in the server, is not expected, and thus it 
should be considered unknown. Usually these are parameters that are correct for 
a given command, but for some reason they are also sent for other commands 
(like was the case of listAll). In these cases it makes sense to change the 
client in order not to send it, right?



So is this parameter (ie: ctxdetails) used? I don't know all the parameters 
used by heart, but I can tell that ctxdetails is not part of 
UpdateNetworkServiceProviderCmd parameters. What I dont know: is ctxdetails 
used in ApiServer, ApiServlet... or any other class upon reception? If it is 
used, then the parameter should not be considered unknown and the warning is a 
false positive. If it is not, then the warning is legitimate.

If the parameter is correct (and thus the warning is a false positive), then 
obviously it should be added to the list of default parameters in the 
ParamGenericValidationWorker so that it doesn't log more false warnings. And 
the same goes for any other valid parameter added in the future. Btw, I would 
strongly recommend to use public constants so that we make sure there is not 
difference between the parameter name in the list and the parameter actually 
used.



Should we keep this functionality or get rid of it? IMHO not having server side 
validation or at least something similar, is not good. But I also understand 
other voices, and I can see that requests that are constructed with unknown 
parameters are going to stay like they are, because people usually work on more 
urgent things. Actually we now have both problems, bad requests and noisy 
warnings, but the warning annoys more. It all started with a reported issue 
about not informaing the client about unused parameters. I didn't create this 
issue, I just fixed it.

Btw, I think the ParamGenericValidationWorker is a very simple code and is not 
buggy. You can also check ParamGenericValidationWorkerTest to see what it does 
and how it is tested. If it is buggy, then let me know and I will fix it. But 
if it's just a matter of getting out of date because new generic parameters are 
added to the code, then anybody should add these parameters. Otherwise any time 
someone adds a new parameter to the code, it will be considered that I need to 
fix the worker, which could happen plenty of times in the future :-)


Please let me know your thoughts and preferences. Thanks. Cheers
antonio





2014-05-13 19:29 GMT+02:00 Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>:
My calls were also executed via 8096 port. We have to eliminate this noise
in the logs before shipping 4.4

On 5/13/14, 10:16 AM, "Amogh Vasekar" 
mailto:amogh.vase...@citrix.c

Re: Review Request 21901: L10N:001-Fixed the legacy hard-coding issues

[Gabor Apati-Nagy]

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


I checked this diff and found the followings that need to be fixed before the 
change could be committed to the repo. Some of them make the UI not to load at 
all.
I suggest this to be checked again, I might have missed other typos.

There is an extra '=' character in the line added here:

@@ -107,7 +107,7 @@ angular.module("storage").controller("VolumesListCtrl", 
["$scope", "$location",
 {
 model: 'format',
 type: 'select',
-label: 'format',
+label: 'label.format=',


There is a missing comma after '
ui/dictionary.jsp:

@@ -1881,6 +1911,49 @@ dictionary = {
'message.enabling.vpc.offering': '',
'message.confirm.remove.vpc.offering': '',
'message.confirm.disable.vpc.offering': ''
-
+'label.add.ciscoASA1000v.resource': '',
+'label.delete.ciscoASA1000v': '',
+'message.confirm.delete.ciscoASA1000v': '',

There is also a comma missing after '

There is an extra comma at the last item in dictionary.jsp.

At sharedFunctions.js the diff looks like:
-case 19:
-return "GPU";
+return _l('label.secondary.storage.vm');
+-case 19:
+-return _l('label.gpu');

The problem above is the last two lines, it causes javascript syntax error, 
because also “-“ will be added to the js file.
Thanks
Gabor

- Gabor Apati-Nagy


On May 27, 2014, 11:58 a.m., Vetrivel Chinnasamy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21901/
> ---
> 
> (Updated May 27, 2014, 11:58 a.m.)
> 
> 
> Review request for cloudstack and Brian Federle.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Externalized the hard coded strings in JavaScript files and added them to 
> messages.properties files. Also appended the link dictionary.jsp with the 
> externalized strings.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties eff2c3e 
>   systemvm/js/cloud.logger.js 751627e 
>   ui/dictionary.jsp 9cc030a 
>   ui/modules/vnmcAsa1000v/vnmcAsa1000v.js 621c52a 
>   ui/scripts/accounts.js a789084 
>   ui/scripts/configuration.js 1a88224 
>   ui/scripts/events.js 2731cb6 
>   ui/scripts/network.js f934f21 
>   ui/scripts/sharedFunctions.js 2cfc89f 
>   ui/scripts/storage.js 2660aa5 
>   ui/scripts/system.js 67e01f1 
>   ui/scripts/templates.js 67cc2fb 
>   ui/scripts/ui-custom/physicalResources.js 06fcca7 
>   ui/scripts/ui-custom/regions.js 986e009 
>   ui/scripts/ui/dialog.js 34cec7b 
>   ui/scripts/ui/widgets/listView.js be40d33 
>   ui/scripts/vpc.js 020b9d7 
> 
> Diff: https://reviews.apache.org/r/21901/diff/
> 
> 
> Testing
> ---
> 
> Tested in local environment by replacing the fixed file.
> 
> 
> File Attachments
> 
> 
> Patch - 2 Commits
>   
> https://reviews.apache.org/media/uploaded/files/2014/05/27/4d2b3c2f-246b-49a6-a528-8c95eecbfba8__001002-L10N-Hardcoding_Fix.patch
> 
> 
> Thanks,
> 
> Vetrivel Chinnasamy
> 
>

Do I need to use a new version of DevCloud with each CloudStack release?

[Demetrius Tsitrelis]

I see that DevCloud was available for 4.2 and then DevCloud 2.0 was available 
for 4.3 so does that mean that there will be a DevCloud 3.0 for 4.4?

Re: Do I need to use a new version of DevCloud with each CloudStack release?

[Chip Childers]

Not really, that's just by happenstance that it happened...  the orig
DevCloud was actually from all the way back at 4.0.0-incubating.

On Wed, Jun 4, 2014 at 3:04 PM, Demetrius Tsitrelis
 wrote:
> I see that DevCloud was available for 4.2 and then DevCloud 2.0 was available 
> for 4.3 so does that mean that there will be a DevCloud 3.0 for 4.4?

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

[Prachi Damle]

>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 calls for a 5.0 are 
>> >>coming up lately so let's move forward. (changing title)
>> >>
>> >>On Wed, May 14, 2014 at 1:53 AM, Min Chen  wrote:
>> >>> Hi All,
>> >>>
>> >>> In the past several weeks, QA has done some testing on IAM 
>> >>> feature
>>and
>> >>>found
>> >>> several backward-compatibility issues. Even though Prachi and I 
>> >>>have tried  our best to fix bugs to maintain backward 
>> >>>compatibility, we realized that in  order to support true IAM 
>> >>>model documented in our FS
>> >>>
>> >>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Ide
>> nti
>> >>>t
>> >>>y+and+Access+Management+%28IAM%29+Plugin,
>> >>> we will have to make several API changes that will require us to 
>> >>>increment  CloudStack major version.
>> >>> Therefore we think that IAM feature is not ready for ACS 4.4
>>release,
>> >>>and we
>> >>> would like to propose to disable it in 4.4 branch and re-enable 
>> >>>it later  when community decides to go for 5.x.
>> >>>
>> >>> Thanks
>> >>> -min
>> >>
>> >>
>> >>
>> >>--
>> >>Daan
>> >
>>
>>
>>

Need to revert CLOUDSTACK-5853

[Prachi Damle]

Hi Marcus,

This is regarding bug fix: https://issues.apache.org/jira/browse/CLOUDSTACK-5853
I see that as a fix, in ClusterScopeStoragePoolAllocator we remove the storage 
pools from avoid set if they happen to match the tag but are found in avoid set.

However this fix is not correct since it breaks the design of avoid set. A 
storage pool might be put in the 'avoid' set by the calling logic for a valid 
reason like capacity exceeded or creation of disks failed on previous try etc.
In such cases the fix will override the avoid set and keep on trying the same 
pool.


So will it be possible for you to revert 
https://issues.apache.org/jira/browse/CLOUDSTACK-5853?


The correct way to fix this is handling of the avoid set in the caller of the 
StoragePoolAllocator - in most of the VM operations the caller is the 
DeploymentPlanningManager.
I had already added the necessary fix in DeploymentPlanningManager  through 
this ticket https://issues.apache.org/jira/browse/CLOUDSTACK-5426


Thanks,
Prachi

[marvin] deploydatacenter broken in master

[Chiradeep Vittal]

Anybody have any ideas?

On 4.4
python marvin/marvin/deployDataCenter.py  -i ../setup/dev/advanced.cfg
(works OK)

On master:
python marvin/marvin/deployDataCenter.py  -i ../setup/dev/advanced.cfg
Traceback (most recent call last):
  File "marvin/marvin/deployDataCenter.py", line 28, in 
from marvin.cloudstackException import (
ImportError: cannot import name GetDetailExceptionInfo

Re: [ANNOUNCE] Amogh Vasekar as committer

[ilya musayev]

A bit late on my mail, but congrats again!

On 6/3/14, 9:37 AM, Amogh Vasekar wrote:

Thanks a ton everyone! :-)

Regards,
Amogh

On 6/3/14 4:06 AM, "Nux!"  wrote:


On 02.06.2014 19:14, John Kinsella wrote:

The Project Management Committee (PMC) for Apache CloudStack has
asked Amogh Vasekar to become a committer and we are pleased to
announce
that he has accepted.

Being a committer allows many contributors to contribute more
autonomously. For
developers, it makes it easier to submit changes and eliminates the
need to
have contributions reviewed via the patch submission process. Whether
contributions are development-related or otherwise, it is a
recognition of a
contributor's participation in the project and commitment to the
project and
the Apache Way.

Please join me in congratulating Amogh!

-John, on behalf of the CloudStack PMC

Congratulations, Amogh! :)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Control event publishing in multi region setups

[Alex Ough]

I just found out an issue when storing 'originatedRegionUuid' in
user/account/domainVO in case of removing them
because the record is actually removed and it is not recommended to access
attributes of the removed.

So I'd like to store the 'originatedRegionUuid' in the
'CallContext.current()' as the user/account/domain objects are stored when
they have been changed instead of storing it in their tables.

Let me know if you have any issue with this.
Thanks
Alex Ough


On Wed, Jun 4, 2014 at 1:15 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>
>
> On 6/4/14, 9:42 AM, "Alex Ough"  wrote:
>
> >That information will be updated whenever its resource is changed, so the
> >prior value is not quite meaningful.
>
> As long as your code doesn’t get confused relying on incorrect
> originated_region_id, I’m fine.
>
> >And as far as I know, there is no synchronization currently working, so
> >all
> >the resources in a region must have been created in the local region.
>
> We can’t assume that as CS users can update these values using
> plugins/hardware that are not a part of CS.
>
> >
> >
> >On Wed, Jun 4, 2014 at 12:36 PM, Alena Prokharchyk <
> >alena.prokharc...@citrix.com> wrote:
> >
> >> But what if those resources are synced around regions prior to the
> >> upgrade? With the approach you suggest, the same resource will have
> >> different region id in each region¹s DB.
> >>
> >> -Alena.
> >>
> >> On 6/4/14, 9:33 AM, "Alex Ough"  wrote:
> >>
> >> >I thought about this and I think it is better to save the local region
> >> >uuid
> >> >because all resources are sure to be created in the local region,
> >>which is
> >> >#4.
> >> >
> >> >Thanks
> >> >Alex Ough
> >> >
> >> >
> >> >On Wed, Jun 4, 2014 at 12:28 PM, Alena Prokharchyk <
> >> >alena.prokharc...@citrix.com> wrote:
> >> >
> >> >>  Alex, one more bullet is needed.
> >> >>
> >> >>  #5 During the DB upgrade all the account/domain/user records should
> >>be
> >> >> populated with ³originated_region_uuid² = one of the regions in the
> >> >>system.
> >> >> The region should be picked using ³region having smallest UUID²
> >> >>criteria.
> >> >>
> >> >>  -alena.
> >> >>
> >> >>   From: Alex Ough 
> >> >> Date: Wednesday, June 4, 2014 at 5:28 AM
> >> >>
> >> >> To: Alena Prokharchyk 
> >> >> Cc: Alex Huang , Murali Reddy <
> >> >> murali.re...@citrix.com>, Kishan Kavala ,
> "
> >> >> dev@cloudstack.apache.org" 
> >> >> Subject: Re: Control event publishing in multi region setups
> >> >>
> >> >>   All,
> >> >>
> >> >>  Alex Huang, Alena and I had a conversation to find out the best
> >> >>solution
> >> >> for one remaining issue,
> >> >> which is to prevent the changes from being sent to remote regions
> >>even
> >> >> when resource changes are occurred in the local region during
> >>FullScan
> >> >> and these are what we decided.
> >> >>
> >> >>  1. A new parameter, 'originated_region_uuid', will be used to
> >>control
> >> >> the flow
> >> >>- during the realtime sync, the value will be the uuid of the
> >>local
> >> >> region to allow the changes to be transferred to remote regions,
> >> >>- during the full scan, the value will be the uuid of the remote
> >> >>region
> >> >> to prevent them from being transferred to remote regions even if the
> >> >>change
> >> >> was occurred in the local region.
> >> >>
> >> >>  2. To support this change, a new input param,
> >>'originated_region_uuid',
> >> >> will be added to all methods to manage user/account/domain in
> >> >> AccountManager & DomainManager class.
> >> >>
> >> >>  3. To store the new input param value, a new field,
> >> >> 'originated_region_uuid', will be added to domain/account/user table
> >>and
> >> >> they will be populated with the current local region uuid when the
> >> >>fields
> >> >> are created during the schema changes because we can guarantee that
> >>the
> >> >> current user/account/domain resources were created in the local
> >>region.
> >> >>
> >> >>  4. The API interfaces to manage the user/account/domain will have an
> >> >> additional input param, 'originated_region_uuid', to support this
> >> >>change.
> >> >>
> >> >>  Please let me know if you have any comments.
> >> >> Thanks
> >> >> Alex Ough
> >> >>
> >> >>
> >> >> On Mon, Jun 2, 2014 at 12:52 PM, Alena Prokharchyk <
> >> >> alena.prokharc...@citrix.com> wrote:
> >> >>
> >> >>>  Yes, I¹m back. Please check with Alex Huang what time he can be on
> >>the
> >> >>> call with you. I can join any time today/tomorrow.
> >> >>>
> >> >>>  -Alena.
> >> >>>
> >> >>>   From: Alex Ough 
> >> >>> Date: Monday, June 2, 2014 at 9:49 AM
> >> >>>
> >> >>> To: Alena Prokharchyk 
> >> >>> Cc: Alex Huang , Murali Reddy <
> >> >>> murali.re...@citrix.com>, Kishan Kavala ,
> >>"
> >> >>> dev@cloudstack.apache.org" 
> >> >>> Subject: Re: Control event publishing in multi region setups
> >> >>>
> >> >>>   Hi Alena,
> >> >>>
> >> >>>  Did you get back from the vacation?
> >> >>> If so, let me know when it is the good time to discuss this.
> 

Review Request 22249: Remove hardcoded guest OS mapping for vmware

[Amogh Vasekar]

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

Review request for cloudstack and Nitin Mehta.


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


Repository: cloudstack-git


Description
---

Remove hardcoded guest OS mapping for vmware, as a part of supporting dynamic 
addition of guest OS.


Diffs
-

  
engine/storage/snapshot/src/org/apache/cloudstack/storage/vmsnapshot/DefaultVMSnapshotStrategy.java
 21f4968ca7657a35d19e2bad62a503d2fadd21ec 
  plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 
77c45b26b7d50f2dedfe6e46d534ea3b82e8f75f 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 52421fa4406991446ce5c8970e853abea96ceee4 

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


Testing
---

This patch is for vmware
1. Local testing on VMware
2. Successfully got up system VMs
3. Successfully created a CentOS VM


Thanks,

Amogh Vasekar

RE: New Defects reported by Coverity Scan for cloudstack

[Animesh Chaturvedi]

Rajani

Thanks for bringing this up, I looked at the analysis settings and I think the 
pattern to exclude aws code should have a leading /. I have fixed it and lets 
check it on the next run. We should see a significant bump up in defect 
density. Good job in noticing this.

Thanks
Animesh

> -Original Message-
> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
> Sent: Monday, June 02, 2014 11:48 PM
> To: dev
> Subject: Re: New Defects reported by Coverity Scan for cloudstack
> 
> These are the approximate number of defects reported by coverity from the
> generated code.
> 
> > /awsapi/src/com/amazon/ec2 -> around 4300
> 
> > /awsapi/src/com/amazon/s3 -> around 350
> 
> 
> total defects -> around 6500
> 
> ~Rajani
> 
> 
> 
> On 02-Jun-2014, at 4:57 pm, Rajani Karuturi  
> wrote:
> 
> > Hi Hugo,
> >
> > awsapi-generated-code   is excluded  for the project but I still see 
> > issues
> reported in them.
> > For example for file src/com/amazon/ec2/DeleteTagsResponseType.java
> >
> >
> > Can you check the file exclude pattern? I think .* is missing
> > (awsapi/src/com/amazon/.*)
> >
> > Fixing this might give us a better report as I see lot of them listed in 
> > these files.
> >
> >
> > ~Rajani
> >
> >
> >
> > On 29-Nov-2013, at 9:28 pm, Hugo Trippaers  wrote:
> >
> >> FYI
> >>
> >> Sent from my iPhone
> >>
> >> Begin forwarded message:
> >>
> >>> From: scan-ad...@coverity.com
> >>> Date: 29 november 2013 14:39:56 CET
> >>> Subject: New Defects reported by Coverity Scan for cloudstack
> >>>
> >>>
> >>> Hi,
> >>>
> >>>
> >>> Please find the latest report on new defect(s) introduced to cloudstack
> found with Coverity Scan.
> >>>
> >>> Defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s)
> >>>
> >>>
> >>> ** CID 1116269:  Nesting level does not match indentation
> >>> (NESTING_INDENT_MISMATCH)
> >>> /awsapi/src/com/cloud/bridge/service/controller/s3/ServiceProvider.j
> >>> ava: 124 in
> >>> com.cloud.bridge.service.controller.s3.ServiceProvider.getManagement
> >>> HostId()()
> >>>
> >>> ** CID 1133706:  Dereference after null check  (FORWARD_NULL)
> >>> /server/src/com/cloud/vm/UserVmManagerImpl.java: 2803 in
> >>> com.cloud.vm.UserVmManagerImpl$3.doInTransaction(com.cloud.utils.db.
> >>> TransactionStatus)()
> >>>
> >>> ** CID 1133705:  Resource leak on an exceptional path
> >>> (RESOURCE_LEAK)
> >>> /server/src/com/cloud/server/ConfigurationServerImpl.java: 638 in
> >>> com.cloud.server.ConfigurationServerImpl.updateSSLKeystore()()
> >>>
> >>> ** CID 1133704:  SS: Unread field should be static
> >>> (FB.SS_SHOULD_BE_STATIC)
> >>> /server/src/com/cloud/uuididentity/UUIDManagerImpl.java: 43 in ()
> >>>
> >>> ** CID 1133703:  Dm: Dubious method used  (FB.DM_DEFAULT_ENCODING)
> >>> /plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/comm
> >>> and/LdapImportUsersCmd.java: 197 in
> >>>
> org.apache.cloudstack.api.command.LdapImportUsersCmd.generatePasswor
> >>> d()()
> >>>
> >>> ** CID 1133702:  DLS: Dead local store  (FB.DLS_DEAD_LOCAL_STORE)
> >>> /plugins/network-elements/juniper-contrail/src/org/apache/cloudstack
> >>> /network/contrail/model/VirtualMachineModel.java: 119 in
> >>> org.apache.cloudstack.network.contrail.model.VirtualMachineModel.bui
> >>> ldServiceInstance(org.apache.cloudstack.network.contrail.model.Model
> >>> Controller, java.lang.String)()
> >>>
> >>>
> >>>
> >>>
> >>>
> _
> ___
> >>> 
> >>> To view the defects in Coverity Scan visit, http://scan.coverity.com
> >>>
> >>> To unsubscribe from the email notification for new defects,
> >>> http://scan5.coverity.com/cgi-bin/unsubscribe.py
> >>>
> >>>
> >>>
> >

Re: Control event publishing in multi region setups

[Alex Ough]

If you see 'AccountManagerImple', it stores the target resource uuid is
stored in the context as below.

CallContext.current().putContextParameter(Account.class, account.getUuid());

So I'd like to store the originated region uuid in the same context so that
the event listener can get the originated region uuid along with the target
uuid as below.

CallContext.current().putContextParameter(Region.class,
originatedRegionUuid);


On Wed, Jun 4, 2014 at 7:05 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> Alex,
>
> And are you planning to store regionDetails set on the callContext
> anywhere in the DB? So this info can be referred once the call is made
> from another context.
>
> Or your code is going to read it from the memory? In this case, I assume
> the follow up code is going to be called within the same context?
>
> It would be helpful if you explain the process in more details using
> regionA/regionB analogy.
>
> Thanks,
> Alena.
>
>
> On 6/4/14, 3:27 PM, "Alex Ough"  wrote:
>
> >I just found out an issue when storing 'originatedRegionUuid' in
> >user/account/domainVO in case of removing them
> >because the record is actually removed and it is not recommended to access
> >attributes of the removed.
> >
> >So I'd like to store the 'originatedRegionUuid' in the
> >'CallContext.current()' as the user/account/domain objects are stored when
> >they have been changed instead of storing it in their tables.
> >
> >Let me know if you have any issue with this.
> >Thanks
> >Alex Ough
> >
> >
> >On Wed, Jun 4, 2014 at 1:15 PM, Alena Prokharchyk <
> >alena.prokharc...@citrix.com> wrote:
> >
> >>
> >>
> >> On 6/4/14, 9:42 AM, "Alex Ough"  wrote:
> >>
> >> >That information will be updated whenever its resource is changed, so
> >>the
> >> >prior value is not quite meaningful.
> >>
> >> As long as your code doesn’t get confused relying on incorrect
> >> originated_region_id, I’m fine.
> >>
> >> >And as far as I know, there is no synchronization currently working, so
> >> >all
> >> >the resources in a region must have been created in the local region.
> >>
> >> We can’t assume that as CS users can update these values using
> >> plugins/hardware that are not a part of CS.
> >>
> >> >
> >> >
> >> >On Wed, Jun 4, 2014 at 12:36 PM, Alena Prokharchyk <
> >> >alena.prokharc...@citrix.com> wrote:
> >> >
> >> >> But what if those resources are synced around regions prior to the
> >> >> upgrade? With the approach you suggest, the same resource will have
> >> >> different region id in each region¹s DB.
> >> >>
> >> >> -Alena.
> >> >>
> >> >> On 6/4/14, 9:33 AM, "Alex Ough"  wrote:
> >> >>
> >> >> >I thought about this and I think it is better to save the local
> >>region
> >> >> >uuid
> >> >> >because all resources are sure to be created in the local region,
> >> >>which is
> >> >> >#4.
> >> >> >
> >> >> >Thanks
> >> >> >Alex Ough
> >> >> >
> >> >> >
> >> >> >On Wed, Jun 4, 2014 at 12:28 PM, Alena Prokharchyk <
> >> >> >alena.prokharc...@citrix.com> wrote:
> >> >> >
> >> >> >>  Alex, one more bullet is needed.
> >> >> >>
> >> >> >>  #5 During the DB upgrade all the account/domain/user records
> >>should
> >> >>be
> >> >> >> populated with ³originated_region_uuid² = one of the regions in
> >>the
> >> >> >>system.
> >> >> >> The region should be picked using ³region having smallest UUID²
> >> >> >>criteria.
> >> >> >>
> >> >> >>  -alena.
> >> >> >>
> >> >> >>   From: Alex Ough 
> >> >> >> Date: Wednesday, June 4, 2014 at 5:28 AM
> >> >> >>
> >> >> >> To: Alena Prokharchyk 
> >> >> >> Cc: Alex Huang , Murali Reddy <
> >> >> >> murali.re...@citrix.com>, Kishan Kavala
> >>,
> >> "
> >> >> >> dev@cloudstack.apache.org" 
> >> >> >> Subject: Re: Control event publishing in multi region setups
> >> >> >>
> >> >> >>   All,
> >> >> >>
> >> >> >>  Alex Huang, Alena and I had a conversation to find out the best
> >> >> >>solution
> >> >> >> for one remaining issue,
> >> >> >> which is to prevent the changes from being sent to remote regions
> >> >>even
> >> >> >> when resource changes are occurred in the local region during
> >> >>FullScan
> >> >> >> and these are what we decided.
> >> >> >>
> >> >> >>  1. A new parameter, 'originated_region_uuid', will be used to
> >> >>control
> >> >> >> the flow
> >> >> >>- during the realtime sync, the value will be the uuid of the
> >> >>local
> >> >> >> region to allow the changes to be transferred to remote regions,
> >> >> >>- during the full scan, the value will be the uuid of the
> >>remote
> >> >> >>region
> >> >> >> to prevent them from being transferred to remote regions even if
> >>the
> >> >> >>change
> >> >> >> was occurred in the local region.
> >> >> >>
> >> >> >>  2. To support this change, a new input param,
> >> >>'originated_region_uuid',
> >> >> >> will be added to all methods to manage user/account/domain in
> >> >> >> AccountManager & DomainManager class.
> >> >> >>
> >> >> >>  3. To store the new input param value, a new field,
> >> >> >> 'originated_region_u

Re: Review Request 21908: Fix for CLOUDSTACK-6464

[ASF Subversion and Git Services]

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


Commit 15385948dcdf4c69136e99bf3c602f95fd018f39 in cloudstack's branch 
refs/heads/4.3 from Edison Su
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1538594 ]

CLOUDSTACK-6464: if guest network type is vlan://untagged, and traffic label is 
used, kvm agent needs to honor traffic label


- ASF Subversion and Git Services


On May 26, 2014, 12:25 p.m., Anders Lannerbäck wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21908/
> ---
> 
> (Updated May 26, 2014, 12:25 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fix for CLOUDSTACK-6464.  This patch is against 4.3-branch.
> 
> The original code adds broadcastUri on the format "vlan://100", but later 
> looks for HashMap keys without the "vlan://" bit.  This causes new interfaces 
> be created with duplicate MACs and the routers become unusable.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  36382e3 
> 
> Diff: https://reviews.apache.org/r/21908/diff/
> 
> 
> Testing
> ---
> 
> Used to repair our production Cloudstack instance.
> 
> 
> Thanks,
> 
> Anders Lannerbäck
> 
>

Re: Review Request 22249: Remove hardcoded guest OS mapping for vmware

[Nitin Mehta]

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

Ship it!


Ship It!

- Nitin Mehta


On June 4, 2014, 10:37 p.m., Amogh Vasekar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22249/
> ---
> 
> (Updated June 4, 2014, 10:37 p.m.)
> 
> 
> Review request for cloudstack and Nitin Mehta.
> 
> 
> Bugs: CLOUDSTACK-6358
> https://issues.apache.org/jira/browse/CLOUDSTACK-6358
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Remove hardcoded guest OS mapping for vmware, as a part of supporting dynamic 
> addition of guest OS.
> 
> 
> Diffs
> -
> 
>   
> engine/storage/snapshot/src/org/apache/cloudstack/storage/vmsnapshot/DefaultVMSnapshotStrategy.java
>  21f4968ca7657a35d19e2bad62a503d2fadd21ec 
>   plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 
> 77c45b26b7d50f2dedfe6e46d534ea3b82e8f75f 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  52421fa4406991446ce5c8970e853abea96ceee4 
> 
> Diff: https://reviews.apache.org/r/22249/diff/
> 
> 
> Testing
> ---
> 
> This patch is for vmware
> 1. Local testing on VMware
> 2. Successfully got up system VMs
> 3. Successfully created a CentOS VM
> 
> 
> Thanks,
> 
> Amogh Vasekar
> 
>

RE: New Defects reported by Coverity Scan for cloudstack

[Animesh Chaturvedi]

While we should wait for the next run for actual results but I am expecting the 
defect density as reported by Coverity to drop down from 6.4 to about 3.4 after 
excluding AWSAPI generated code.

Animesh

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Wednesday, June 04, 2014 3:56 PM
> To: dev@cloudstack.apache.org
> Subject: RE: New Defects reported by Coverity Scan for cloudstack
> 
> Rajani
> 
> Thanks for bringing this up, I looked at the analysis settings and I think the
> pattern to exclude aws code should have a leading /. I have fixed it and lets
> check it on the next run. We should see a significant bump up in defect 
> density.
> Good job in noticing this.
> 
> Thanks
> Animesh
> 
> > -Original Message-
> > From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
> > Sent: Monday, June 02, 2014 11:48 PM
> > To: dev
> > Subject: Re: New Defects reported by Coverity Scan for cloudstack
> >
> > These are the approximate number of defects reported by coverity from
> > the generated code.
> >
> > > /awsapi/src/com/amazon/ec2 -> around 4300
> >
> > > /awsapi/src/com/amazon/s3 -> around 350
> >
> >
> > total defects -> around 6500
> >
> > ~Rajani
> >
> >
> >
> > On 02-Jun-2014, at 4:57 pm, Rajani Karuturi 
> wrote:
> >
> > > Hi Hugo,
> > >
> > > awsapi-generated-code is excluded  for the project but I still see 
> > > issues
> > reported in them.
> > > For example for file src/com/amazon/ec2/DeleteTagsResponseType.java
> > >
> > >
> > > Can you check the file exclude pattern? I think .* is missing
> > > (awsapi/src/com/amazon/.*)
> > >
> > > Fixing this might give us a better report as I see lot of them listed in 
> > > these
> files.
> > >
> > >
> > > ~Rajani
> > >
> > >
> > >
> > > On 29-Nov-2013, at 9:28 pm, Hugo Trippaers  wrote:
> > >
> > >> FYI
> > >>
> > >> Sent from my iPhone
> > >>
> > >> Begin forwarded message:
> > >>
> > >>> From: scan-ad...@coverity.com
> > >>> Date: 29 november 2013 14:39:56 CET
> > >>> Subject: New Defects reported by Coverity Scan for cloudstack
> > >>>
> > >>>
> > >>> Hi,
> > >>>
> > >>>
> > >>> Please find the latest report on new defect(s) introduced to
> > >>> cloudstack
> > found with Coverity Scan.
> > >>>
> > >>> Defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s)
> > >>>
> > >>>
> > >>> ** CID 1116269:  Nesting level does not match indentation
> > >>> (NESTING_INDENT_MISMATCH)
> > >>> /awsapi/src/com/cloud/bridge/service/controller/s3/ServiceProvider
> > >>> .j
> > >>> ava: 124 in
> > >>> com.cloud.bridge.service.controller.s3.ServiceProvider.getManageme
> > >>> nt
> > >>> HostId()()
> > >>>
> > >>> ** CID 1133706:  Dereference after null check  (FORWARD_NULL)
> > >>> /server/src/com/cloud/vm/UserVmManagerImpl.java: 2803 in
> > >>>
> com.cloud.vm.UserVmManagerImpl$3.doInTransaction(com.cloud.utils.db.
> > >>> TransactionStatus)()
> > >>>
> > >>> ** CID 1133705:  Resource leak on an exceptional path
> > >>> (RESOURCE_LEAK)
> > >>> /server/src/com/cloud/server/ConfigurationServerImpl.java: 638 in
> > >>> com.cloud.server.ConfigurationServerImpl.updateSSLKeystore()()
> > >>>
> > >>> ** CID 1133704:  SS: Unread field should be static
> > >>> (FB.SS_SHOULD_BE_STATIC)
> > >>> /server/src/com/cloud/uuididentity/UUIDManagerImpl.java: 43 in ()
> > >>>
> > >>> ** CID 1133703:  Dm: Dubious method used
> (FB.DM_DEFAULT_ENCODING)
> > >>> /plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/co
> > >>> mm
> > >>> and/LdapImportUsersCmd.java: 197 in
> > >>>
> > org.apache.cloudstack.api.command.LdapImportUsersCmd.generatePasswor
> > >>> d()()
> > >>>
> > >>> ** CID 1133702:  DLS: Dead local store  (FB.DLS_DEAD_LOCAL_STORE)
> > >>> /plugins/network-elements/juniper-contrail/src/org/apache/cloudsta
> > >>> ck
> > >>> /network/contrail/model/VirtualMachineModel.java: 119 in
> > >>> org.apache.cloudstack.network.contrail.model.VirtualMachineModel.b
> > >>> ui
> > >>> ldServiceInstance(org.apache.cloudstack.network.contrail.model.Mod
> > >>> el
> > >>> Controller, java.lang.String)()
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> >
> _
> > ___
> > >>> 
> > >>> To view the defects in Coverity Scan visit,
> > >>> http://scan.coverity.com
> > >>>
> > >>> To unsubscribe from the email notification for new defects,
> > >>> http://scan5.coverity.com/cgi-bin/unsubscribe.py
> > >>>
> > >>>
> > >>>
> > >

Re: Unable to upload SSL certificate

[Syed Ahmed]

Can you try to encode the certificate before passing it as the param?

-Syed

On Wed 04 Jun 2014 09:01:19 AM EDT, Saksham Srivastava wrote:

Adding Syed,

I debugged the issue and here are my findings:

The api is failing at CertServiceimpl: parseCertificate()

return (Certificate) certPem.readObject();

readObject method is failing.

I tried to use the certificate used in the test 
runUploadSslCertSelfSignedWithPassword and other tests in CertServiceTest.java
The following is the api call:

http://10.x.x.x:8096/client/api?command=uploadSslCert&certificate=-BEGIN+CERTIFICATE-%0AMIIDBjCCAe4CCQD5Q6qF5dVV0jANBgkqhkiG9w0BAQUFADBFMQswCQYDVQQGEwJB%0AVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50ZXJuZXQgV2lkZ2l0%0AcyBQdHkgTHRkMB4XDTEzMTAyMTEzNTgwNFoXDTE0MTAyMTEzNTgwNFowRTELMAkG%0AA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0%0AIFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB%0AAN%2F7lJtiEs68IC1ZPxY9NA34z9T4AU4LPS%2FkbQtuxx4X72XOBy%2By0cB%2FqdMD7JNV%0Ah8Mq4URDljhSDyVPdH%2F%2BjQr%2B7kWx2gNe2R%2FDCnd%2FmeVwwU30JJvpGVZXt%2BMTef5N%0AQAbSfDMsuT4FaUY80InbDd24HelrjwunPdY9wwKXO6zL2fLjyDRediiydxcx18Vb%0ADq1cm7DRi4mNkmA3RwBQMhxGp3VsfXJ4Hy2WTRCCCxWHZphAh3EUJGK3idum6%2F7j%0AHbAwpM%2Ft1kNWN8PZiYDZ1HbccgjmqB7Cub10BfB9g1RByiQ%2FC87o5cKtQha3uuXR%0AiBcHISoDydQrgxKgUpiqEF0CAwEAATANBgkqhkiG9w0BAQUFAAOCAQEASvulIaVb%0Azh8z2TysE6RFoYTAYIRXghFrmqCUyyQmUVTvs6vN8iaSXr%2BWMQJcpgXewWcFrDhr%0AmIcyRCvF91ZYb7q6lMZFSpE6u%2FSUGIEtxGUDAfbkbQdKYmrMcbggUUIvSzgUFisO%0

A
Kr0H9PEO4AWtCCrtOJFc7jgu03Sv06wDxn9ghkyiBRnVkbAhoKfKnI179yKruJWR%0AA3ieEj0eFoUbeSH8hDkToj4ynpkAvEGoHjHG9j%2B8FJxy%2FPTjkyVPl1ykTs%2B2Jc1B%0ASnx8f2afdTenPWyyBm3wFuRZjEAJJLUO0kxM7E8hAwhGsr%2BXYanwcr1oA1dz6M3f%0Acq26lpjTH5ITwQ%3D%3D%0A-END+CERTIFICATE-%0A&privatekey=-BEGIN+RSA+PRIVATE+KEY-%0AProc-Type%3A+4%2CENCRYPTED%0ADEK-Info%3A+DES-EDE3-CBC%2CCCA6E4CB4C4039DD%0A%0ATaVCJtB0dE9xTZbX7GOaGJwwGHVAMjU1GbRIHf0jODdP%2BquZvbjklNqsw8Ozlia9%0Aq%2FG%2BUqtRJGlIPPLpce0YCrTo0P3eixZdMs0%2BhioAEJ4OLtL0SAC6b8q%2FgB6HRfAx%0ABvNg%2BumTqeF9YB68Tcuv%2F2g4VGKiaePQACyOzMdf7lGY7ojxoJCYZa1mfKb7jWrg%0AFLwmTtLLhNjb6CnOKo3klIef3A6zdutpgxF1gARzdRyXg4qCA3boYnwEptTOlJFu%0AovxbhDG9iuYYr4gXYSs1pLYptEC8J6iWpG%2Fqzkwfr4l5Cfg5uF00bbxQE5%2BWeRaj%0AYFicvXjB%2FkcoFZuCL7M%2FYRXYxkJ%2FEZ19xI9HZNBQ4L738StkSBKL4OhpF%2FqgYZ2y%0AZLRV6XT4AijUA0Ef7YTuUsTL7Qt9drj09gCtAzXTA7gpZBn5SqT9kWhuwSzY302l%0AKF8DIC6A52igk2QKPLbleM%2FV8eCu6n%2BJ4uF%2B0GwVRROuG7ThxAQiUlJKhoEYrndL%0AnzT7jHVLftjilhVWFu2On62bRf5t1QZuob%2B1AdK0ukvE
I
VsYnN4bnlAkc99Wi6C0%0AZJd9qW5L4A9XAC2gcjr3m0Rzw3RO%2Bk17faR8YfmTuJvGyBf5fnrSFoNkrninXQXp%0Ask0ajRi4PJ4XTswLyxjWRSt3egNsZBSKnVCibca%2FQoDEdZHSKXo2FlYiUYx8JHQX%0ASPUsLl9OQKC1W8%2F%2BReryqBLHCkiGEsvT8gVaXga0uhVaqe%2BPaVur2tbOHl4yCysC%0A%2BZlnKwsC84LQsUvpENdCh%2BD7E1I1Rao9IJMR6q9azKq8Ck63cOJ1fA9xSnxJGoCA%0AIlGLttlXrR32EtzYwEnlqf1nI%2FIqNQrAXQKrP5VPzHsgMFu5uD4OEZa92Q5cVTsz%0Aap%2F1UEqiJVYUt6nuA%2BaqOUlyjC0oNtYL%2FVO4DbHTFcHa8SI2cPSS6ebPMWPGHjUm%0Al9bWa6Q9iyplCYS6hinAVsAaLVjPi1Eu9Pc8rxFCmoiJYJju5NZuGI5UBK64dqcX%0AT6trWl0kB8QY63JtnrZaoStoSPImV5KVseUKDV8TM3Y76h1nLV3MSmAD1ivk9oKs%0AVKeVrDhZBWUq9Dqre%2F%2BlVGO0a2wo5VTR8hfpf8QkODPLeyNZNdfGKzkkFLuXa8V5%0AELhLQJ3FnbEU3NEvMwikV9MhP%2FELPTkZwJr%2FNKv%2B9JLs9eXtwz29I%2FQ8byQVrCCs%0AhAuDl0zHGRnqdpdSImeS2EXGx631zGMwSe8fhKelni5h6hXrXz52asr0k30BxWjf%0AWUn1uTInwVjWGy9B5j3mZlVDotFbvVAZgtR0IoFwihPl4VZd9oS13l%2BhMfrTy1YZ%0A8xFNg8ZqUQ0lSmKfOVqSBT0lP8tM8LuGxgY4cWluhsAQxR5Nl7wkundnqjcwEDDu%0AJz2rD54St1EZYGLDJZSfC7mpG2PgodsdeopQCTyFhHWa8s3caZ40GFOwaR%2B%2F5%2BY
F
%0A1oRvkR1Yr4qIS7KbX4xsaFfAA5b8QfLA74L05PAgDwKofam2GFAlAKHOcI6mexPq%0AaySON9MNdnXBNxs16mBJLzCX5ljQb0ilJildVEI3aVmABptM4ehEiw%3D%3D%0A-END+RSA+PRIVATE+KEY-%0A&password=test


and the api fails with "Invalid Certificate format. Expected X509 certificate"

Since all the tests pass, I am assuming a problem with the api encoding format.
Can someone point to a working api call for the same.

Thanks,
Saksham


-Original Message-
From: Sujaya Maiyya (Intern) [mailto:sujaya.mai...@citrix.com]
Sent: Tuesday, June 3, 2014 2:36 PM
To: dev@cloudstack.apache.org
Cc: Vijay Venkatachalam
Subject: Unable to upload SSL certificate

Hi,
   I am trying to upload an SSL certificate to Cloudstack using uploadSslCert 
API since 4.3 version does not have UI support for the same. And I am getting 
following exception:
 Invalid Certificate format. Expected X509 certificate

The certificate, private key and certificate-chain are URL encoded and sent to 
the Cloudstack using a GET on 8096 port. On debugging, it was found that some 
characters were missing from certificate after it was decoded from the URL 
which is the cause of the exception.

I am unable to figure out the reason, so can you please throw some light on why 
are some characters missing after decoding the certificate from the URL?

Thank you,
Sujaya

KVM + LXC on the same host

[ilya musayev]

We are considering running KVM and LXC on the same host and hopefully 
control both through cloudstack.


I know there are agents involved for each component, i dont know if we 
can have a hybrid of LXC+KVM.


The use case is simple, we would like the end user to pick LXC/Docker 
for performance, or KVM instance if he really needed all bells and 
whistles of dedicated kernel in fully virtualized environment.


Is anyone aware why we should not mix 2 workloads on the same host? Is 
it possible at this point in time to mix LXC, KVM and CloudStack, i 
assume the answer is no, but perhaps there is a hack i can try.


Thanks
ilya

KVM and CloudStack with oVirt/RHEV

[ilya musayev]

We are under impression that CloudStack can fully managed KVM hosts 
without RHEV/oVirt. However, we want to take it a step further and have 
oVirt (open source of RHEV) similar to VmWare vCenter monitor and 
possible perform additional tasks like perfomance metrics and alerting.


Has anyone tried this yet? Any issues you can think of if KVM is managed 
by oVirt and CloudStack.

Build failed in Jenkins: cloudstack-4.3-maven-build #534

[jenkins]

See 

Changes:

[likitha.shetty] CLOUDSTACK-5927. Storage garbage collector is trying to 
destroy the SSVM/CPVM root disk that is in use.

[David Nalley] Added required dependancy to agent setup.

[mike.tutkowski] CLOUDSTACK-5873: [Automation] Failed to attach volume to VM, 
if the vm is created with option startvm=false

[kelveny] CLOUDSTACK-5928: disable host delta sync when new VM sync is enabled

[Alena Prokharchyk] CLOUDSTACK-5930: Changed "authenticate" method to return 
both - result of authentication, and action to perform when authentication 
failed - to the accountManagerImpl. Only if authenicators request 
INCREMENT_INCORRECT_LOGIN_ATTEMPT_COUNT, the incorrect_login_attempts parameter 
will be increased

[kelveny] CLOUDSTACK-5928: Use legacy vmsync logic by default

[Devdeep Singh] CLOUDSTACK-5936: Hyper-V agent should log to the windows event 
log. Changed the default

[koushik] Added Fix for CLOUDSTACK-5875

[Devdeep Singh] CLOUDSTACK-5942: The agent at places logs the password of the 
user. It should mask the

[jessicawang] CLOUDSTACK-5614: UI - Infrastructure > Sockets > listView > (1) 
split "XenServer" into "XenServer 6.2.0" and "XenServer"(prior to 6.2.0).

[htrippaers] Findbugs finding : Incorrect use of equality

[htrippaers] Backport fixed for issues found by Findbugs

[htrippaers] Backport findbugs configuration to 4.3 so we can run a findbugs 
report in jenkins.

[Daan Hoogland] nullpointer dereference guarded

[Daan Hoogland] moved call on static object to synchronized block

[Daan Hoogland] restored imports

[Ian Duffy] Fix findbug issues within LDAP authenticator

[Daan Hoogland] Findbugs issues in ApiResponseHelper fixes

[Daan Hoogland] findbugs fixes for ApiServer, ApiSerializerHelper and 
ApiXmlDocWriter

[Daan Hoogland] findbugs: null check for gateway and netmask instead of gateway 
twice

[Daan Hoogland] findbugs: remove compatible objects from collection

[Daan Hoogland] Revert "findbugs: remove compatible objects from collection"

[Daan Hoogland] findbugs: serialized class serializable

[Daan Hoogland] findbugs: retrieve the objects to remove from the collection(s)

[Daan Hoogland] findbugs: null-checks

[Daan Hoogland] findbugs: byte[].toString -> Arrays.toString(byte[])

[Daan Hoogland] findbugs: removed fields injected in parent

[Daan Hoogland] Findbugs: different issues solved

[Daan Hoogland] findbugs: assign result of string manipulations

[Daan Hoogland] findbugs: nullpointer guards and wrappertype comparisons

[Daan Hoogland] findbugs: throw exceptions when found

[Daan Hoogland] findbugs: removed obfuscating fields

[koushik] CLOUDSTACK-5949: Remove unused field vnc_password from user_vm_view

[min.chen] CLOUDSTACK-5960: Domain admin or user cannot register a template 
using

[likitha.shetty] CLOUDSTACK-5796. [VMware] Size column is not getting updated 
in snapshot_store_ref table when a snapshot is backed up in secondary storage.

[sanjay.tripathi] CS-5950: Wrong storage tags are used for ISO deployed VMs.

[sanjay.tripathi] CLOUDSTACK-5900: Failed to delete template/ISO that failed to 
download.

[jayapal] CLOUDSTACK-5966 Added enable/disable monitoring service in global 
config

[min.chen] CLOUDSTACK-5971:Templates created from a snapshots can't be copied to

[marcus] CLOUDSTACK-5968 create vm.memballoon.disable agent parameter

[marcus] CLOUDSTACK-5968 create vm.memballoon.disable agent parameter

[sanjay.tripathi] Revert "CLOUDSTACK-5900: Failed to delete template/ISO that 
failed to download."

[sanjay.tripathi] CLOUDSTACK-5900: Failed to delete template/ISO that failed to 
download.

[Daan Hoogland] CLOUDSTACK-5979 vlan parsing fixed

[Daan Hoogland] Revert "CLOUDSTACK-5979 vlan parsing fixed"

[Daan Hoogland] check for BroadcastDomainTypes on sourceNatIp(cherry picked 
from commit

[jessicawang] CLOUDSTACK-5970: UI > network menu > guest network section > 
select non-VPC isolated network with SourceNAT enabled > IP Address section > 
select sourceNAT IP > show Configuration tab.

[Alena Prokharchyk] LOUDSTACK-5987: when listTemplates with 
filter=community/featured, get public templates from all domains in the system, 
not just parent/child subdomains of the caller

[sheng.yang] CLOUDSTACK-5986: Make dnsmasq handle dnsmasq.leases when 
dhcp_release is available

[sanjay.tripathi] CLOUDSTACK-5900: Failed to delete template/ISO that failed to 
download.

[jayapal] CLOUDSTACK-5966 Updated service monitoring config to start by default.

[sanjay.tripathi] CLOUDSTACK-5660: Migrate vm live migration succeeds but 
throws error as "Failed to migrate the system vm".

[kawai] Fix mock socket client/server test.

[kawai] Some rework stratosphere ssp plugin

[koushik] CLOUDSTACK-5989: Trying to start a vm while 'vm snapshot' is in 
progress results in inconsistency

[likitha.shetty] CLOUDSTACK-5994. Hitting IndexOutOfBoundsException in 
GetVmStatsCommand after upgrade.

[Daan Hoogland] Revert 

Re: KVM and CloudStack with oVirt/RHEV

[David Nalley]

You should talk to Laszlo.

--David

On Wed, Jun 4, 2014 at 9:23 PM, ilya musayev
 wrote:
> We are under impression that CloudStack can fully managed KVM hosts without
> RHEV/oVirt. However, we want to take it a step further and have oVirt (open
> source of RHEV) similar to VmWare vCenter monitor and possible perform
> additional tasks like perfomance metrics and alerting.
>
> Has anyone tried this yet? Any issues you can think of if KVM is managed by
> oVirt and CloudStack.

Re: [DISCUSS] Increasing VM IOPS by separating golden image in high IOPS partition in Xen Server ?

[Hieu LE]

Mike, Punith,

Please review "Golden Primary Storage" proposal. [1]

Thank you.

[1]:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+Storage


On Wed, Jun 4, 2014 at 10:32 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Daan helped out with this. You should be good to go now.
>
>
> On Tue, Jun 3, 2014 at 8:50 PM, Hieu LE  wrote:
>
> > Hi Mike,
> >
> > Could you please give edit/create permission on ASF Jira/Wiki confluence
> ?
> > I can not add a new Wiki page.
> >
> > My Jira ID: hieulq
> > Wiki: hieulq89
> > Review Board: hieulq
> >
> > Thanks !
> >
> >
> > On Wed, Jun 4, 2014 at 9:17 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com
> > > wrote:
> >
> > > Hi,
> > >
> > > Yes, please feel free to add a new Wiki page for your design.
> > >
> > > Here is a link to applicable design info:
> > >
> > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design
> > >
> > > Also, feel free to ask more questions and have me review your design.
> > >
> > > Thanks!
> > > Mike
> > >
> > >
> > > On Tue, Jun 3, 2014 at 7:29 PM, Hieu LE  wrote:
> > >
> > > > Hi Mike,
> > > >
> > > > You are right, performance will be decreased over time because writes
> > > IOPS
> > > > will always end up on slower storage pool.
> > > >
> > > > In our case, we are using CloudStack integrated in VDI solution to
> > > provived
> > > > pooled VM type[1]. So may be my approach can bring better UX for user
> > > with
> > > > lower bootime ...
> > > >
> > > > A short change in design are followings
> > > > - VM will be deployed with golden primary storage if primary storage
> is
> > > > marked golden and this VM template is also marked as golden.
> > > > - Choosing the best deploy destionation for both golden primary
> storage
> > > and
> > > > normal root volume primary storage. Chosen host can also access both
> > > > storage pools.
> > > > - New Xen Server plug-in for modifying VHD parent id.
> > > >
> > > > Is there some place for me to submit my design and code. Can I write
> a
> > > new
> > > > proposal in CS wiki ?
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> >
> http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-choose-scheme-type-rho.html
> > > >
> > > >
> > > > On Mon, Jun 2, 2014 at 9:04 PM, Mike Tutkowski <
> > > > mike.tutkow...@solidfire.com
> > > > > wrote:
> > > >
> > > > > It is an interesting idea. If the constraints you face at your
> > company
> > > > can
> > > > > be corrected somewhat by implementing this, then you should go for
> > it.
> > > > >
> > > > > It sounds like writes will be placed on the slower storage pool.
> This
> > > > means
> > > > > as you update OS components, those updates will be placed on the
> > slower
> > > > > storage pool. As such, your performance is likely to somewhat
> > decrease
> > > > over
> > > > > time (as more and more writes end up on the slower storage pool).
> > > > >
> > > > > That may be OK for your use case(s), though.
> > > > >
> > > > > You'll have to update the storage-pool orchestration logic to take
> > this
> > > > new
> > > > > scheme into account.
> > > > >
> > > > > Also, we'll have to figure out how this ties into storage tagging
> (if
> > > at
> > > > > all).
> > > > >
> > > > > I'd be happy to review your design and code.
> > > > >
> > > > >
> > > > > On Mon, Jun 2, 2014 at 1:54 AM, Hieu LE 
> wrote:
> > > > >
> > > > > > Thanks Mike and Punith for quick reply.
> > > > > >
> > > > > > Both solutions you gave here are absolutely correct. But as I
> > > mentioned
> > > > > in
> > > > > > the first email, I want another better solution for current
> > > > > infrastructure
> > > > > > at my company.
> > > > > >
> > > > > > Creating a high IOPS primary storage using storage tags is good
> but
> > > it
> > > > > will
> > > > > > be very waste of disk capacity. For example, if I only have 1TB
> SSD
> > > and
> > > > > > deploy 100 VM from a 100GB template.
> > > > > >
> > > > > > So I think about a solution where a high IOPS primary storage can
> > > only
> > > > > > store golden image (master image), and a child image of this VM
> > will
> > > be
> > > > > > stored in another normal (NFS, ISCSI...) storage. In this case,
> > with
> > > > 1TB
> > > > > > SSD Primary Storage I can store as much golden image as I need.
> > > > > >
> > > > > > I have also tested it with 256 GB SSD mounted on Xen Server 6.2.0
> > > with
> > > > > 2TB
> > > > > > local storage 1RPM, 6TB NFS share storage with 1GB network.
> The
> > > > IOPS
> > > > > of
> > > > > > VMs which have golden image (master image) in SSD and child image
> > in
> > > > NFS
> > > > > > increate more than 30-40% compare with VMs which have both golden
> > > image
> > > > > and
> > > > > > child image in NFS. The boot time of each VM is also decrease.
> > > ('cause
> > > > > > golden image in SSD only reduced READ IOPS).
> > > > > >
> > > > > > Do you think this approach OK ?
> > > > > >
> > > > > >
> > > > > > On Mon, Jun 2, 2014 at 12:50 PM, Mike Tutkowski <
> > > >

Re: Need help on the CS First class object hiding feature.

[Girish Chaudhari]

Thanks Nitin for immediate response.

"... I see that some more first class entities have gotten added but
the underlying concept remains the same."

=> Can you please name the newly added first class entities if
possible, or what could be the best way to figure it out.
 Is there any criteria which is used to decided whether particular CS
resource is first class candidate or not. Or every resource can be
taken as first class object and hiding can be applied to it.
Can you please let me know what steps/efforts will be involved in
hiding new CS first class object using this feature?

"I would think that would be a bug. Please file it and I will try and
look into it."

=> I will double check on it and try the same steps with another
mentioned resource. Will file the bug accordingly.

>Also like to check whether Admin can update this feature flags or
>provide the meta data through UI?


"Yes, admin can update the display flag during creation time or using
update apis. Check deployvm and updateVm apis."

-> You mean to say current CS UI(4.3 or upcoming 4.4) has ability to
mark the existing VM as hidden or create new VM with hide flag? I
could try it, using API programatically only.

As well I have follow up extended questions as:

Do this feature only applied to Root Admin vs the users Or even
equally applied to "Any Sub Domain Admin User" vs its non admin users?


Thanks,
Girish

On Wed, Jun 4, 2014 at 8:19 PM, Nitin Mehta  wrote:
>
>
> On 04/06/14 4:52 AM, "Girish Chaudhari" 
> wrote:
>
>>Hi Team,
>>
>>I am looking into the CS first class object hiding feature to verify
>>how the Admin user has better control over the display of CS resources
>>to end users.
>>
>>The only reference link I could find is
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+bet
>>ter+control+over+first+class+objects+in+CS
>>
>>Is there any other documentation available around this feature
>>providing more use cases and examples..etc.
>
> This is the functional spec and should provide you most of the
> information. I see that some more first class entities have gotten added
> but the underlying concept remains the same.
>
>>
>>Whereas I have tried to verify this feature by creating the
>>resources(VM) by Admin and associated it with the account. In usual
>>case Account user as well the admin user can retrieve the VM using the
>>listVMs call. When I am trying to set the display_vm flag as false, as
>>expected the account user don't see the VM. But even the Admin user
>>can't see the VM in list.
>>
>>Not sure whether I am following the right steps or its buggy behavior.
>
> I would think that would be a bug. Please file it and I will try and look
> into it.
>
>
>
>>
>>Also like to check whether Admin can update this feature flags or
>>provide the meta data through UI?
>
> Yes, admin can update the display flag during creation time or using
> update apis. Check deployvm and updateVm apis
>
>>
>>Curious to know whether anyone is using this feature in production and
>>how?
>>
>>Thanks,
>>Girish
>

Re: Review Request 22229: Test case failure in test_iso.py

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On June 4, 2014, 1:25 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9/
> ---
> 
> (Updated June 4, 2014, 1:25 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-6769
> https://issues.apache.org/jira/browse/CLOUDSTACK-6769
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Hi,
> there was a environment issue because of which the test suite was failing at 
> setup. I fixed the env issue,
> now the test suite runs on Xenserver but not on KVM (it fails at setup on 
> KVM).
> 
> Also out of the 5 tests running on xen only 3 are passing. the failed tests 
> are
> integration.smoke.test_iso.TestISO.test_04_extract_Iso
> integration.smoke.test_iso.TestISO.test_06_copy_iso
> 
> So disabling this suite until the above mentioned issues are fixed.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_iso.py a3e42f1 
> 
> Diff: https://reviews.apache.org/r/9/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

[Proposal] NuageVsp Network Plugin

[Suresh Ramamurthy]

Hi Dev Team,

Thanks for allowing us to submit NuageVsp Network Plugin support to
CloudStack.

I have added the design specification in the wiki. Please find the link
below

https://cwiki.apache.org/confluence/display/CLOUDSTACK/NuageVsp+Network+Plugin

Please review it and let me know if I need to provide more information in
the spec.

Could you please point me to any link that describes about the branching
strategy that we need to followed to add our code.

Thanks,
Suresh

Re: [Proposal] NuageVsp Network Plugin

[ilya musayev]

Hi Suresh

Hope all is well,

Are there any plans to support KVM or is it just XEN?

Thanks
ilya
On 6/4/14, 9:08 PM, Suresh Ramamurthy wrote:

Hi Dev Team,

Thanks for allowing us to submit NuageVsp Network Plugin support to
CloudStack.

I have added the design specification in the wiki. Please find the link
below

https://cwiki.apache.org/confluence/display/CLOUDSTACK/NuageVsp+Network+Plugin

Please review it and let me know if I need to provide more information in
the spec.

Could you please point me to any link that describes about the branching
strategy that we need to followed to add our code.

Thanks,
Suresh

Re: KVM and CloudStack with oVirt/RHEV

[Wido den Hollander]

On 06/05/2014 03:23 AM, ilya musayev wrote:

We are under impression that CloudStack can fully managed KVM hosts
without RHEV/oVirt. However, we want to take it a step further and have
oVirt (open source of RHEV) similar to VmWare vCenter monitor and
possible perform additional tasks like perfomance metrics and alerting.

Has anyone tried this yet? Any issues you can think of if KVM is managed
by oVirt and CloudStack.


I haven't tried this, but I see the potential of adding extra layers of 
complexity.


CloudStack manages KVM just fine using libvirt. oVirt doesn't do 
anything different, it also manages KVM using libvirt.


I personally don't see any benefit at this moment.

Wido

Re: KVM and CloudStack with oVirt/RHEV

[ilya musayev]

oVirt for KVM is equivalent of XenCenter and vCenter for Xen and vSphere.

It helps to have another interface that is similar to vCenter or 
XenCenter. Administratively, its a nice to have as it gives you all in 
one view, but its not a must.



On 6/4/14, 9:45 PM, Wido den Hollander wrote:



On 06/05/2014 03:23 AM, ilya musayev wrote:

We are under impression that CloudStack can fully managed KVM hosts
without RHEV/oVirt. However, we want to take it a step further and have
oVirt (open source of RHEV) similar to VmWare vCenter monitor and
possible perform additional tasks like perfomance metrics and alerting.

Has anyone tried this yet? Any issues you can think of if KVM is managed
by oVirt and CloudStack.


I haven't tried this, but I see the potential of adding extra layers 
of complexity.


CloudStack manages KVM just fine using libvirt. oVirt doesn't do 
anything different, it also manages KVM using libvirt.


I personally don't see any benefit at this moment.

Wido

Re: Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py

[ASF Subversion and Git Services]

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


Commit 81bf37f33853d95e7c4137d57a60e719963913c4 in cloudstack's branch 
refs/heads/4.4-forward from Bharat Kumar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=81bf37f ]

CLOUDSTACK-6776: Removed hard coded vlan ids from BVT 
test_non_contiguous_vlan.py


- ASF Subversion and Git Services


On June 3, 2014, 11:45 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22197/
> ---
> 
> (Updated June 3, 2014, 11:45 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6776
> https://issues.apache.org/jira/browse/CLOUDSTACK-6776
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
>  The test case fails whenever hard coded values overlap with already 
> configured VLAN in the physical network. Removed hard code VLAN ids and used 
> the common function to get unused VLAN ids from the physical network 
> dynamically.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_non_contigiousvlan.py 90235ec 
> 
> Diff: https://reviews.apache.org/r/22197/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test to update a physical network and extend its vlan ... === TestName: 
> test_extendPhysicalNetworkVlan | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 15.328s
> 
> OK
> ~
> ~
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 22197: CLOUDSTACK-6776: Removed hard coded vlan ids from BVT test_non_contiguous_vlan.py

[ASF Subversion and Git Services]

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


Commit 96272f4cde4e1012da820264ff91c43a9ec255c4 in cloudstack's branch 
refs/heads/master from Bharat Kumar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=96272f4 ]

CLOUDSTACK-6776: Removed hard coded vlan ids from BVT 
test_non_contiguous_vlan.py

Conflicts:
test/integration/smoke/test_non_contigiousvlan.py


- ASF Subversion and Git Services


On June 3, 2014, 11:45 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22197/
> ---
> 
> (Updated June 3, 2014, 11:45 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6776
> https://issues.apache.org/jira/browse/CLOUDSTACK-6776
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
>  The test case fails whenever hard coded values overlap with already 
> configured VLAN in the physical network. Removed hard code VLAN ids and used 
> the common function to get unused VLAN ids from the physical network 
> dynamically.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_non_contigiousvlan.py 90235ec 
> 
> Diff: https://reviews.apache.org/r/22197/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test to update a physical network and extend its vlan ... === TestName: 
> test_extendPhysicalNetworkVlan | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 15.328s
> 
> OK
> ~
> ~
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: [DISCUSS] Increasing VM IOPS by separating golden image in high IOPS partition in Xen Server ?

[Amit Das]

Hi Hieu,

Will it be good to include bulk operation of this feature? In addition,
does Xen support parallel execution of these operations ?

Regards,
Amit
*CloudByte Inc.* 


On Thu, Jun 5, 2014 at 8:59 AM, Hieu LE  wrote:

> Mike, Punith,
>
> Please review "Golden Primary Storage" proposal. [1]
>
> Thank you.
>
> [1]:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+Storage
>
>
> On Wed, Jun 4, 2014 at 10:32 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Daan helped out with this. You should be good to go now.
>>
>>
>> On Tue, Jun 3, 2014 at 8:50 PM, Hieu LE  wrote:
>>
>> > Hi Mike,
>> >
>> > Could you please give edit/create permission on ASF Jira/Wiki
>> confluence ?
>> > I can not add a new Wiki page.
>> >
>> > My Jira ID: hieulq
>> > Wiki: hieulq89
>> > Review Board: hieulq
>> >
>> > Thanks !
>> >
>> >
>> > On Wed, Jun 4, 2014 at 9:17 AM, Mike Tutkowski <
>> > mike.tutkow...@solidfire.com
>> > > wrote:
>> >
>> > > Hi,
>> > >
>> > > Yes, please feel free to add a new Wiki page for your design.
>> > >
>> > > Here is a link to applicable design info:
>> > >
>> > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Design
>> > >
>> > > Also, feel free to ask more questions and have me review your design.
>> > >
>> > > Thanks!
>> > > Mike
>> > >
>> > >
>> > > On Tue, Jun 3, 2014 at 7:29 PM, Hieu LE  wrote:
>> > >
>> > > > Hi Mike,
>> > > >
>> > > > You are right, performance will be decreased over time because
>> writes
>> > > IOPS
>> > > > will always end up on slower storage pool.
>> > > >
>> > > > In our case, we are using CloudStack integrated in VDI solution to
>> > > provived
>> > > > pooled VM type[1]. So may be my approach can bring better UX for
>> user
>> > > with
>> > > > lower bootime ...
>> > > >
>> > > > A short change in design are followings
>> > > > - VM will be deployed with golden primary storage if primary
>> storage is
>> > > > marked golden and this VM template is also marked as golden.
>> > > > - Choosing the best deploy destionation for both golden primary
>> storage
>> > > and
>> > > > normal root volume primary storage. Chosen host can also access both
>> > > > storage pools.
>> > > > - New Xen Server plug-in for modifying VHD parent id.
>> > > >
>> > > > Is there some place for me to submit my design and code. Can I
>> write a
>> > > new
>> > > > proposal in CS wiki ?
>> > > >
>> > > > [1]:
>> > > >
>> > > >
>> > >
>> >
>> http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-choose-scheme-type-rho.html
>> > > >
>> > > >
>> > > > On Mon, Jun 2, 2014 at 9:04 PM, Mike Tutkowski <
>> > > > mike.tutkow...@solidfire.com
>> > > > > wrote:
>> > > >
>> > > > > It is an interesting idea. If the constraints you face at your
>> > company
>> > > > can
>> > > > > be corrected somewhat by implementing this, then you should go for
>> > it.
>> > > > >
>> > > > > It sounds like writes will be placed on the slower storage pool.
>> This
>> > > > means
>> > > > > as you update OS components, those updates will be placed on the
>> > slower
>> > > > > storage pool. As such, your performance is likely to somewhat
>> > decrease
>> > > > over
>> > > > > time (as more and more writes end up on the slower storage pool).
>> > > > >
>> > > > > That may be OK for your use case(s), though.
>> > > > >
>> > > > > You'll have to update the storage-pool orchestration logic to take
>> > this
>> > > > new
>> > > > > scheme into account.
>> > > > >
>> > > > > Also, we'll have to figure out how this ties into storage tagging
>> (if
>> > > at
>> > > > > all).
>> > > > >
>> > > > > I'd be happy to review your design and code.
>> > > > >
>> > > > >
>> > > > > On Mon, Jun 2, 2014 at 1:54 AM, Hieu LE 
>> wrote:
>> > > > >
>> > > > > > Thanks Mike and Punith for quick reply.
>> > > > > >
>> > > > > > Both solutions you gave here are absolutely correct. But as I
>> > > mentioned
>> > > > > in
>> > > > > > the first email, I want another better solution for current
>> > > > > infrastructure
>> > > > > > at my company.
>> > > > > >
>> > > > > > Creating a high IOPS primary storage using storage tags is good
>> but
>> > > it
>> > > > > will
>> > > > > > be very waste of disk capacity. For example, if I only have 1TB
>> SSD
>> > > and
>> > > > > > deploy 100 VM from a 100GB template.
>> > > > > >
>> > > > > > So I think about a solution where a high IOPS primary storage
>> can
>> > > only
>> > > > > > store golden image (master image), and a child image of this VM
>> > will
>> > > be
>> > > > > > stored in another normal (NFS, ISCSI...) storage. In this case,
>> > with
>> > > > 1TB
>> > > > > > SSD Primary Storage I can store as much golden image as I need.
>> > > > > >
>> > > > > > I have also tested it with 256 GB SSD mounted on Xen Server
>> 6.2.0
>> > > with
>> > > > > 2TB
>> > > > > > local storage 1RPM, 6TB NFS share storage with 1GB network.
>> The
>> > > > IOPS
>> > > > > of
>> > > > > > VMs which have golden image (master image) in SSD and

[GIT] 4.3.0 vs 4.3.0-forward - where to commit?

[ilya musayev]

Looks like few patches that i've backported to 4.3.0-forward have been 
dropped (dont see my commits). i am now under impression i should have 
commited to 4.3.0 branch.


Would someone please clarify the difference between the two and where to 
commit when i need to backport/cherry-pick a patch?


Thanks
ilya

Re: [GIT] 4.3.0 vs 4.3.0-forward - where to commit?

[sebgoa]

On Jun 5, 2014, at 8:14 AM, ilya musayev  wrote:

> Looks like few patches that i've backported to 4.3.0-forward have been 
> dropped (dont see my commits). i am now under impression i should have 
> commited to 4.3.0 branch.
> 
> Would someone please clarify the difference between the two and where to 
> commit when i need to backport/cherry-pick a patch?
> 
> Thanks
> ilya

Ilya, imho those -forward branches should not exist, they create a mess.
If you have something to patch for the 4.3 series, just patch it in the 4.3 
branch. 4.3.0, 4.3.1 etc are tags in that 4.3 branch

Re: [Proposal] NuageVsp Network Plugin

[sebgoa]

On Jun 5, 2014, at 6:08 AM, Suresh Ramamurthy 
 wrote:

> Hi Dev Team,
> 
> Thanks for allowing us to submit NuageVsp Network Plugin support to
> CloudStack.
> 
> I have added the design specification in the wiki. Please find the link
> below
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/NuageVsp+Network+Plugin
> 
> Please review it and let me know if I need to provide more information in
> the spec.
> 
> Could you please point me to any link that describes about the branching
> strategy that we need to followed to add our code.
> 

You will submit your first patch through review board, then when it's accepted 
it will be put in it's own branch.
Then you will work off that branch.
The toughest thing will be to keep your branch rebased with master so that when 
we merge there are no conflicts or very little.
But since you are going to write a network plugin this should be fairly 
isolated and the merge should be easy.

> Thanks,
> Suresh

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

[Meghna Kale]

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.

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 calls for a 5.0 are
> >> >>coming up lately so let's move forward. (changing title)
> >> >>
> >> >>On Wed, May 14, 2014 at 1:53 AM, Min Chen 
> wrote:
> >> >>> Hi All,
> >> >>>
> >> >>> In the past several weeks, QA has done some testing on IAM
> >> >>> feature
> >>and
> >> >>>found
> >> >>> several backward-compatibility issues. Even though Prachi and I
> >> >>>have tried  our best to fix bugs to maintain backward
> >> >>>compatibility, we realized that in  order to support true IAM
> >> >>>model documented in our FS
> >> >>>
> >> >>>
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Ide
> >> nti
> >> >>>t
> >> >>>y+and+Access+Management+%28IAM%29+Plugin,
> >> >>> we will have to make several API changes that will require us to
> >> >>>increment  CloudStack major version.
> >> >>> Therefore we think that IAM feature is not ready for ACS 4.4
> >>release,
> >> >>>and we
> >> >>> would like to propose to disable it in 4.4 branch and re-enable
> >> >>>it later  when community decides to go for 5.x.
> >> >>>
> >> >>> Thanks
> >> >>> -min
> >> >>
> >> >>
> >> >>
> >> >>--
> >> >>Daan
> >> >
> >>
> >>
> >>
>
>
>

Re: New Defects reported by Coverity Scan for cloudstack

[Hugo Trippaers]

Heya,

Thanks for helping out with the coverity configuration.

The coverity builds are run automagically from Jenkins every monday and friday. 
Based on our project size we can submit a maximum of two builds per week. The 
choices for monday and friday are arbitraty so if other days suit our workflow 
better any Jenkins admin can adapt the configuration. 


Cheers,

Hugo

On 5 jun. 2014, at 02:01, Animesh Chaturvedi  
wrote:

> 
> While we should wait for the next run for actual results but I am expecting 
> the defect density as reported by Coverity to drop down from 6.4 to about 3.4 
> after excluding AWSAPI generated code.
> 
> Animesh
> 
>> -Original Message-
>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> Sent: Wednesday, June 04, 2014 3:56 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: New Defects reported by Coverity Scan for cloudstack
>> 
>> Rajani
>> 
>> Thanks for bringing this up, I looked at the analysis settings and I think 
>> the
>> pattern to exclude aws code should have a leading /. I have fixed it and lets
>> check it on the next run. We should see a significant bump up in defect 
>> density.
>> Good job in noticing this.
>> 
>> Thanks
>> Animesh
>> 
>>> -Original Message-
>>> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
>>> Sent: Monday, June 02, 2014 11:48 PM
>>> To: dev
>>> Subject: Re: New Defects reported by Coverity Scan for cloudstack
>>> 
>>> These are the approximate number of defects reported by coverity from
>>> the generated code.
>>> 
 /awsapi/src/com/amazon/ec2 -> around 4300
>>> 
 /awsapi/src/com/amazon/s3 -> around 350
>>> 
>>> 
>>> total defects -> around 6500
>>> 
>>> ~Rajani
>>> 
>>> 
>>> 
>>> On 02-Jun-2014, at 4:57 pm, Rajani Karuturi 
>> wrote:
>>> 
 Hi Hugo,
 
 awsapi-generated-code  is excluded  for the project but I still see 
 issues
>>> reported in them.
 For example for file src/com/amazon/ec2/DeleteTagsResponseType.java
 
 
 Can you check the file exclude pattern? I think .* is missing
 (awsapi/src/com/amazon/.*)
 
 Fixing this might give us a better report as I see lot of them listed in 
 these
>> files.
 
 
 ~Rajani
 
 
 
 On 29-Nov-2013, at 9:28 pm, Hugo Trippaers  wrote:
 
> FYI
> 
> Sent from my iPhone
> 
> Begin forwarded message:
> 
>> From: scan-ad...@coverity.com
>> Date: 29 november 2013 14:39:56 CET
>> Subject: New Defects reported by Coverity Scan for cloudstack
>> 
>> 
>> Hi,
>> 
>> 
>> Please find the latest report on new defect(s) introduced to
>> cloudstack
>>> found with Coverity Scan.
>> 
>> Defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s)
>> 
>> 
>> ** CID 1116269:  Nesting level does not match indentation
>> (NESTING_INDENT_MISMATCH)
>> /awsapi/src/com/cloud/bridge/service/controller/s3/ServiceProvider
>> .j
>> ava: 124 in
>> com.cloud.bridge.service.controller.s3.ServiceProvider.getManageme
>> nt
>> HostId()()
>> 
>> ** CID 1133706:  Dereference after null check  (FORWARD_NULL)
>> /server/src/com/cloud/vm/UserVmManagerImpl.java: 2803 in
>> 
>> com.cloud.vm.UserVmManagerImpl$3.doInTransaction(com.cloud.utils.db.
>> TransactionStatus)()
>> 
>> ** CID 1133705:  Resource leak on an exceptional path
>> (RESOURCE_LEAK)
>> /server/src/com/cloud/server/ConfigurationServerImpl.java: 638 in
>> com.cloud.server.ConfigurationServerImpl.updateSSLKeystore()()
>> 
>> ** CID 1133704:  SS: Unread field should be static
>> (FB.SS_SHOULD_BE_STATIC)
>> /server/src/com/cloud/uuididentity/UUIDManagerImpl.java: 43 in ()
>> 
>> ** CID 1133703:  Dm: Dubious method used
>> (FB.DM_DEFAULT_ENCODING)
>> /plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/co
>> mm
>> and/LdapImportUsersCmd.java: 197 in
>> 
>>> org.apache.cloudstack.api.command.LdapImportUsersCmd.generatePasswor
>> d()()
>> 
>> ** CID 1133702:  DLS: Dead local store  (FB.DLS_DEAD_LOCAL_STORE)
>> /plugins/network-elements/juniper-contrail/src/org/apache/cloudsta
>> ck
>> /network/contrail/model/VirtualMachineModel.java: 119 in
>> org.apache.cloudstack.network.contrail.model.VirtualMachineModel.b
>> ui
>> ldServiceInstance(org.apache.cloudstack.network.contrail.model.Mod
>> el
>> Controller, java.lang.String)()
>> 
>> 
>> 
>> 
>> 
>>> 
>> _
>>> ___
>> 
>> To view the defects in Coverity Scan visit,
>> http://scan.coverity.com
>> 
>> To unsubscribe from the email notification for new defects,
>> http://scan5.coverity.com/cgi-bin/unsubscribe.py
>> 
>> 
>> 
 
>