Re: Review Request 14171: fix test_networks.py to reduce time taken by the tests

[venkata swamy babu budumuru]

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

Ship it!


Ship It!

- venkata swamy babu  budumuru


On Sept. 17, 2013, 10:33 a.m., SrikanteswaraRao Talluri wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14171/
> ---
> 
> (Updated Sept. 17, 2013, 10:33 a.m.)
> 
> 
> Review request for cloudstack, venkata swamy babu  budumuru and Prasanna 
> Santhanam.
> 
> 
> Bugs: CLOUDSTACK-4344
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> pass delay and retries explicitly to remoteSSHclient to reduce time taken by 
> the tests
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_network.py 042ac84 
> 
> Diff: https://reviews.apache.org/r/14171/diff/
> 
> 
> Testing
> ---
> 
> tested
> 
> 
> Thanks,
> 
> SrikanteswaraRao Talluri
> 
>

Re: Virtual Router reachability

[Marcus Sorensen]

In the past, with KVM, the agent doesn't show the router as running until
it can ssh to it. You can watch the agent poll if it is debug logging. Does
this issue not apply to KVM, or is it a regression?
On Sep 29, 2013 11:38 PM, "Girish Shilamkar"  wrote:

> Hello,
>
> Egress rules tests rely on accessing virtual router VR after creating a
> network. I have often seen that VR is not immediately accessible.
> A ssh to VR fails, I think it takes a while for the network to come up and
> VR can be ssh'd. This happens even though the VR is in "Running"
> state.
> So I added a delay before trying to ssh VR. I was wondering what is the
> right amount of delay here. I did not find a param in global settings
> which can be used as wait time.
>
> Please advise.
>
> Regards,
> Girish
>
>

Re: Review Request 14011: CLOUDSTACK-4612: Specified locale keyboard language is not showing as default in consoleView passed during deployVM.

[Rajesh Battala]

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

Ship it!


Looks good to me.

- Rajesh Battala


On Sept. 6, 2013, 8:41 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14011/
> ---
> 
> (Updated Sept. 6, 2013, 8:41 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh, Fang Wang, and Kelven Yang.
> 
> 
> Bugs: CLOUDSTACK-4612
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4612: Specified locale keyboard language is not showing as default 
> in consoleView passed during deployVM.
> 
> While deploying a VM, user passes the "keyboard" parameter to specify the
> default language for that VM but in the consoleView, the default language
> selected is en-us irrespective of the default language of the VM.
> 
> 
> This patch is for 4.2-forward branch. I'll send a seperate patch for master 
> as there are some conflicts with the master branch.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/servlet/ConsoleProxyClientParam.java e420110 
>   server/src/com/cloud/servlet/ConsoleProxyServlet.java f6559a5 
>   services/console-proxy/server/js/ajaxviewer.js 9643204 
>   
> services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxyAjaxHandler.java
>  6cadeca 
>   
> services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxyClientBase.java
>  07a1b6f 
>   
> services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxyClientParam.java
>  8de4955 
>   
> services/console-proxy/server/src/com/cloud/consoleproxy/ConsoleProxyHttpHandlerHelper.java
>  297e711 
> 
> Diff: https://reviews.apache.org/r/14011/diff/
> 
> 
> Testing
> ---
> 
> Verified the fix locally by deploying a VM with keyboard=uk and keyboard=jp.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: Virtual Router reachability

[Jayapal Reddy Uradi]

Girish,

cloudstack shows router status as 'running' before the router booting 
completed. The router is accessible when the cloud-early-config starts the sshd 
in booting.

+1 on santosh suggestion.

Thanks,
Jayapal
 

On 30-Sep-2013, at 11:25 AM, Santhosh Edukulla 
 wrote:

> Girish,
> 
> 1. Using timeout will make it to wait for that many units always and again it 
> may not be fool proof, we may succeed to find ssh daemon on remote machine is 
> up and running  and with this, we again run it few more times to check again 
> if it is not running, so its not much predictable. 
> 
> Instead of  waiting for specified time always. 
> 
> a) poll check  to see if ping to ip is working and then verify ssh port is 
> open for connections on the target, if yes, we are good to go.  This way, we 
> are not waiting for specific time always.
> b)  There is a telnet lib of which you can use either read_until or expect 
> calls with specific max timeout ( worst ) with strings like "connected" etc 
> to check ssh port is available for connections, If we are getting the desired 
> string in the output, then we are ok, or otherwise you may take a call. This 
> way, we wait for max time only during worst cases.  Check the link below link 
> for specific examples: 
> 
> http://docs.python.org/2/library/telnetlib.html
> 
> Regards,
> Santhosh
> 
> From: Girish Shilamkar [gir...@clogeny.com]
> Sent: Monday, September 30, 2013 1:38 AM
> To: dev@cloudstack.apache.org
> Subject: Virtual Router reachability
> 
> Hello,
> 
> Egress rules tests rely on accessing virtual router VR after creating a 
> network. I have often seen that VR is not immediately accessible.
> A ssh to VR fails, I think it takes a while for the network to come up and VR 
> can be ssh'd. This happens even though the VR is in "Running"
> state.
> So I added a delay before trying to ssh VR. I was wondering what is the right 
> amount of delay here. I did not find a param in global settings
> which can be used as wait time.
> 
> Please advise.
> 
> Regards,
> Girish

RE: Virtual Router reachability

[Santhosh Edukulla]

Girish,

1. Using timeout will make it to wait for that many units always and again it 
may not be fool proof, we may succeed to find ssh daemon on remote machine is 
up and running  and with this, we again run it few more times to check again if 
it is not running, so its not much predictable. 

Instead of  waiting for specified time always. 

 a) poll check  to see if ping to ip is working and then verify ssh port is 
open for connections on the target, if yes, we are good to go.  This way, we 
are not waiting for specific time always.
 b)  There is a telnet lib of which you can use either read_until or expect 
calls with specific max timeout ( worst ) with strings like "connected" etc to 
check ssh port is available for connections, If we are getting the desired 
string in the output, then we are ok, or otherwise you may take a call. This 
way, we wait for max time only during worst cases.  Check the link below link 
for specific examples: 

http://docs.python.org/2/library/telnetlib.html

Regards,
Santhosh

From: Girish Shilamkar [gir...@clogeny.com]
Sent: Monday, September 30, 2013 1:38 AM
To: dev@cloudstack.apache.org
Subject: Virtual Router reachability

Hello,

Egress rules tests rely on accessing virtual router VR after creating a 
network. I have often seen that VR is not immediately accessible.
A ssh to VR fails, I think it takes a while for the network to come up and VR 
can be ssh'd. This happens even though the VR is in "Running"
state.
So I added a delay before trying to ssh VR. I was wondering what is the right 
amount of delay here. I did not find a param in global settings
which can be used as wait time.

Please advise.

Regards,
Girish

[PROPOSAL] Support OVA files with multiple disks for templates and uploaded volumes in VMWare

[Likitha Shetty]

Hi,

Currently, Cloudstack only supports Template creation based on OVA files 
containing a single disk. If a user creates a template from a OVA file 
containing more than 1 disk and launches an instance using this template, only 
the first disk is attached to the new instance and other disks are ignored. 
Similarly with uploaded volumes, attaching an uploaded volume that contains 
multiple disks to a VM will result in only one VMDK to being attached to the VM.

This behavior needs to be improved in VMWare to support OVA files with multiple 
disks for both templates and uploaded volumes. For e.g. If a user creates a 
template from a OVA file containing more than 1 disk and launches an instance 
using this template, the first disk should be attached to the new instance as 
the ROOT disk, volumes should be created based on other VMDK disks in the OVA 
file and should be attached to the instance.

I will soon propose a Functional Spec for this improvement.

The corresponding JIRA ticket can be found at 
https://issues.apache.org/jira/browse/CLOUDSTACK-4757 . 

Thanks,
Likitha

RE: [Merge] Minimal Hyper-V Plugin

[Rajesh Battala]

Am looking at building the agent code using mono. 
Will create a wiki after finishing it.

Thanks
Rajesh Battala

-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] 
Sent: Thursday, September 26, 2013 2:55 AM
To: dev@cloudstack.apache.org
Subject: Re: [Merge] Minimal Hyper-V Plugin

+1 to put this into a branch off of master. Can merge into master after
unit tests for the agent API.


On 9/24/13 12:37 PM, "Donal Lafferty"  wrote:

>On paternity leave, so I don't get to these emails right away...
>
>> -Original Message-
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: 20 September 2013 06:40
>> To: dev@cloudstack.apache.org
>> Subject: Re: [Merge] Minimal Hyper-V Plugin
>> 
>> Thanks for the preliminary testing.
>> Questions:
>> 1. More for the community: should the C# code be in a separate repo?
>> According to the merge request, mono and maven can be used to build 
>> the agent.
>
>Silence == acceptance?
>
>> 2. Packaging: how is the C# agent installed?
>
>The agent is implemented to as a self-contained Windows Service, which 
>is the Microsoft Windows equivalent of a Linux daemon.
>
>To make the agent distributable, package the agent and an app.config 
>consistent with your data center in an MSI.  WiX is the preferred tool 
>(http://en.wikipedia.org/wiki/WiX ).  When executed, the MSI will add 
>the agent to set of Windows Services.
>
>To distribute and run this MSI, use Active Directory's GPO (global 
>policy
>object) service.  In typical deployments machines running Hyper-V will 
>be domain joined.  Where machines are not domain joined, look at 
>something like puppet.
>
>> 3. What does minimal mean? What works? What doesn't? Local storage?
>> Shared storage? Networking modes? Are the hypervisors supposed to be 
>> clustered?
>
>Minimal = create / start / stop / destroy a local storage VM in a 
>QuickCloud network offering and CIFS secondary storage.
>
>No clustering required.
>
>> 4. How does one extend the "minimal" plugin?
>
>Each CloudStack command has a corresponding an HTTP URI served by the 
>agent.  These are written in ASP.NET MVC4.  Data received by the agent 
>is kept in a JSON object graph.
>
>E.g.
>
>// POST api/HypervResource/ReadyCommand
>[HttpPost]
>[ActionName(CloudStackTypes.ReadyCommand)]
>public JContainer ReadyCommand([FromBody]dynamic cmd)
>{
>using (log4net.NDC.Push(Guid.NewGuid().ToString()))
>{
>logger.Info(CloudStackTypes.ReadyCommand + 
>cmd.ToString());
>object ansContent = new
>{
>result = true,
>details = (string)null
>};
>return ReturnCloudStackTypedJArray(ansContent,
>CloudStackTypes.ReadyAnswer);
>}
>
>}
>
>Therefore, to extend the plugin, add new HTTP URIs corresponding to 
>missing commands, or extend the capabilities of existing commands.
>
>I can follow up with an explanation in a blog entry.
>
>> 5. Can the unit tests (at least those that test the agent API) be run 
>>in a non-  hyper-v environment?
>
>Unit tests start the agent in a local process.  Provided Mono is 
>installed on your system, the unit tests will run.  However, they will 
>complain of bad output.
>
>> 6. Is the RDP console you had earlier mentioned included in the merge?
>
>Yes, but it serves no purpose at the moment.
>
>If there is an IP clearance protocol to follow for this console, I 
>would prefer to remove the console from the submission.
>
>> 7. Any known issues?
>> 
>
>There seems to be a bug with local paths that include spaces.  I've 
>asked Rajesh to provide a bug report, but it's unclear where to put 
>this.  Can we use JIRA for code not merged, or should the bug appear in the 
>comments.
>
> 
>> On 9/11/13 8:00 AM, "Donal Lafferty"  wrote:
>> 
>> >Hi Rajesh,
>> >
>> >Thanks for spotting this problem with the Hyper-V Agent.  Sounds 
>> >like it should first URL decode the field.
>> >
>> >Can you update the review with details of your testing?
>> >
>> >I would need to know the command and which incoming field is causing 
>> >problems.  Also, can you add a serialised example of the instruction 
>> >that fails?  There should be an example in the agent's log file.  By 
>> >default, the log file is in the same folder as the agent executable.  
>> >I will use this to update the automated tests.
>> >
>> >If you want to go ahead and made the fixes from a git clone, send a 
>> >Pull Request.  As long as there is an appropriate automated test, 
>> >I'll update the feature branch with your changes.
>> >
>> >
>> >DL
>> >
>> >> -Original Message-
>> >> From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
>> >> Sent: 11 September 2013 09:08
>> >> To: dev@cloudstack.apache.org
>> >> Subject: RE: [Merge] Minimal Hyper-V Plugin
>> >>
>> >> Hi Donal,
>> >> I had figured out the issue why "+" is coming in the path value.
>> >> Th

Virtual Router reachability

[Girish Shilamkar]

Hello,
 
Egress rules tests rely on accessing virtual router VR after creating a 
network. I have often seen that VR is not immediately accessible.
A ssh to VR fails, I think it takes a while for the network to come up and VR 
can be ssh'd. This happens even though the VR is in "Running"
state.
So I added a delay before trying to ssh VR. I was wondering what is the right 
amount of delay here. I did not find a param in global settings
which can be used as wait time. 

Please advise.

Regards,
Girish

Re: [ANNOUNCE] New Committer: Darren Shepherd

[Abhinandan Prateek]

Congrats Darren ! 

-abhi

On 28/09/13 5:54 pm, "Chip Childers"  wrote:

>The Project Management Committee (PMC) for Apache CloudStack
>has asked Darren Shepherd 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 Darren!
>
>-chip
>on behalf of the CloudStack PMC

RE: [DISCUSS] UI: New look and feel

[Shiva Teja]

Hi,
Sorry about that. Our ISP seems to be down. I am not sure if it will be
back soon.

Shiva Teja
On Sep 30, 2013 10:04 AM, "Santhosh Edukulla" 
wrote:

> Hi Shiva,
>
> Iam trying to access http://students.iitmandi.ac.in:2, but couldnt.
> It seems there was a name resolution issue. Iam accessing it from my dev
> box and using dns server "10.103.128.16" to resolve the uri in your link,
> which is internal to citrix. May be you can provide the ip to check the
> link directly if it is ok?
>
> BTW, I appreciate your effort, I am ok to join the development effort.
> Though iam not much of a UI guy, one of our product in my earlier
> organization used angular js and moved away from their earlier js
> frameworks, They had very good views on this, it will be a good learning
> for me to see.
>
>
> Thanks!
> Santhosh
> 
> From: Shiva Teja [shivate...@gmail.com]
> Sent: Sunday, September 29, 2013 2:33 PM
> To: dev@cloudstack.apache.org"
> Subject: Re: [DISCUSS] UI: New look and feel
>
> On Fri, Sep 27, 2013 at 5:44 PM, SuichII, Christopher <
> chris.su...@netapp.com> wrote:
>
> >
> > Shiva & Sebastien - What impact would this angular.js project have on UI
> > plugins?
>
>
>
> It would definitely make it easy and offer cleaner code. I'll try to write
> an overview soon. In a brief way :
>
> 1. You don't have to write any API calls. They'll be taken care by the
> resources modules[0].
> 2. You don't have to do any DOM manipulation. Angular's directives[1] that
> we write will take care of them.
> 3. There's no 'listView' or 'detailView'. Each plugin can have its own
> template(s)[2]. These templates must be very small if directives are used
> effectively. 'confirm', 'vm-state-label', 'ng-repeat' are some of the
> directives you can see in the template given at the end for example usage.
>
> Every tab that you see on the side nav bar in this UI is a plugin. So you
> can checkout any plugin to start with.
>
> Demo is running at http://students.iitmandi.ac.in:2/ . It is running
> on
> DevCloud. Feel free to play around. Username and password are the default
> ones: admin-password.
>
> As far as themes are concerned, I used bootstrap. So there are lots of
> bootstrap themes out there which can be easily added to this UI without
> worrying about breaking things.
>
> I am yet to add unit tests, add the functionalities to bring at par with
> the current UI and clean up the designs. Maybe we could have both the UIs
> for some time and then see how things go. If anybody is interested in
> joining the further development, please let me know :)
>
> [0]
>
> https://github.com/shivateja/cloudstack-ui/tree/angular-rawapi/static/js/common/resources
> [1]
>
> https://github.com/shivateja/cloudstack-ui/tree/angular-rawapi/static/js/common/directives
> [2] This is an example template :
>
> https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/app/instances/instances.tpl.html
>
> Thanks,
> Shiva Teja

Re: my two cents on RBAC/authorization

[Min Chen]

Commands.properties will stay as it is for now, acl_api_permission will be
auto-populated based on this commands.properties file. So developers do
not need to update the DB when they add a new api.

-min

On 9/29/13 6:10 PM, "Darren Shepherd"  wrote:

>So this will replace the commands.properties.  If one adds a new api,
>will they need to update the DB?
>
>Darren
>
>On Sep 29, 2013, at 5:15 PM, Min Chen  wrote:
>
>>> 
>>> 
>>> 
>>> One random question, I'm interested in knowing what the relationship
>>> between commands.props and this new rbac thing will be.
>> 
>> We have categorized two types of permission, one is API level permission
>> to work with current ApiChecker (what kind of APIs are allowed to be
>> accessed by a particular role), the other is entity level permission
>>(what
>> access type we want to grant to a group on a particular entity
>>instance).
>> Previous commands.properties will be stored in acl_api_permission table
>>to
>> indicate what APIs can be accessed by a particular role. Out-of-box, we
>> have Admin, DomainAdmin, and User roles to match with current
>>Account_type.
>> 
>> Thanks
>> -min
>> 
>> 
>>> 
>>> Darren
>>> 
 On Sep 29, 2013, at 4:28 PM, Darren Shepherd
  wrote:
 
 I look forward to the proposal.  Based on your short comments and the
 artifacts I've seen so, I'll warn you that I'll probably disagree
 strongly with the implement
 
 Darren
 
> On Sep 29, 2013, at 12:04 PM, Min Chen  wrote:
> 
> RBAC branch was created by Prachi and me to do some quick prototype
>on
> rbac feature we are going to propose in the community soon. Since it
>is
> not ready yet, we haven't proposed and published FS on the ML.
> 
> In this prototype, we have group, accout, role, permission as our
> first class object. Unlike Amazon, cloudstack ACL is mainly done at
> Account level, so our Group will be a collection of accounts instead
>of
> users. Different from Darren suggested here, we didn't extract a
> separate Policy object to
> Group several permissions to a policy, because we didn't see a big
> benefit to store collections of permissions as a Json policy object
> compared to storing each individual permission into a permission
>table.
> Another reason why we store individual permission in db table is to
> facilitate implementing row-level permission filter for list Apis,
> where we have created DB views to determine entities to be returned.
> With a separate permission table, we can potentially join that table
>in
> db view for row filtering in read operation. In terms of integrating
> with third-party RBAC system, I don't see a big difference between
> re-creating policy object using cloudstack defined Json format and
> asking them to define those permissions through cloudstack provided
> permission grant Apis.
> 
> Thanks
> -min
> 
> Sent from my iPhone
> 
>> On Sep 28, 2013, at 8:51 PM, "Darren Shepherd"
>>  wrote:
>> 
>> I've noticed there's a rbac branch and things are being committed
>> there.  I didn't see any documentation about the design or anything
>> (maybe it exists and I looked in the wrong place), so I'm just going
>> to give you my two cents on authorization systems.  Hopefully this
>> falls in line with what is being implemented, if not, at least we'll
>> avoid the awkward conversation when its finish when I say the code
>>is
>> marginally useful and should be rewritten.
>> 
>> When talking about authorization there's a bunch of terms like
>> principal, permission, subject, action, policy, etc.  I want to
>>focus
>> on policy.  Policy is central to an authorization system.  The
>>policy
>> is the collection of permissions that grant or deny access to some
>> resource or action for a given subject.  RBAC is a really just a
>>means
>> to generate a policy.  Once you know the user, group, roles, and the
>> permissions of those entities that aggregation of information forms
>> the policy.  You then take that policy and use it determine if the
>> given resource/action is granted/denied to a particular subject.
>> 
>> It is really important that policy is a first class object in an
>> authorization system.  This is important to understand because
>>usually
>> in a big fat enterprise-y company, they really want you to enforce
>>the
>> policy, but not necessarily maintain it.  For example, you'll go to
>> your fortune 500 company and they'll tell you they need RBAC.  So
>>you
>> go and create an RBAC system.  The problem is that the fortune 500
>> company probably already has a RBAC system, and its probably AD
>>based.
>> So when they said they need RBAC, the really meant you need to
>> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
>> yo

Re: Review Request 14190: Switch to setter injection for extensibility

[Kelven Yang]

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


Daren,

when getGuru() is call in a non-initial phase, it may be involved with 
multi-threaded context, I suggest to make it thread-safe
 

public HypervisorGuru getGuru(HypervisorType hypervisorType) {
58  
return _hvGurus.get(hypervisorType);
60  
HypervisorGuru result = _hvGurus.get(hypervisorType);
61  

62  
if ( result == null ) {
63  
for ( HypervisorGuru guru : _hvGuruList ) {
64  
if ( guru.getHypervisorType() == hypervisorType ) {
65  
_hvGurus.put(hypervisorType, guru);
66  
result = guru;
67  
break;
68  
}
69  
}
70  
}
71  

72  
return result;
59  
}
73  

-Kelven

- Kelven Yang


On Sept. 18, 2013, 3:49 p.m., Darren Shepherd wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14190/
> ---
> 
> (Updated Sept. 18, 2013, 3:49 p.m.)
> 
> 
> Review request for cloudstack, Alex Huang and Kelven Yang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Various classes are using member injection to inject extensible objects.  
> Really those object should come from an AdapterList that is injected in.  
> This patch switches the code to use setter injection that will later allow 
> spring to inject an AdapterList or something similar to allow extensibility
> 
> 
> Diffs
> -
> 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> 24f0795 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
>  204b832 
>   
> plugins/acl/static-role-based/src/org/apache/cloudstack/acl/StaticRoleBasedAPIAccessChecker.java
>  d4d73d1 
>   server/src/com/cloud/api/ApiServer.java 550626f 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 17ef6bf 
>   server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 90273f7 
>   server/src/com/cloud/hypervisor/HypervisorGuruManagerImpl.java 4d1e1b5 
>   server/src/com/cloud/network/NetworkServiceImpl.java eb63fe0 
>   server/src/com/cloud/server/ManagementServerImpl.java c0a52f7 
>   server/src/com/cloud/storage/VolumeApiServiceImpl.java cc99589 
>   server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
> d4463d9 
>   server/src/com/cloud/template/TemplateManagerImpl.java e11ac0d 
> 
> Diff: https://reviews.apache.org/r/14190/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Darren Shepherd
> 
>

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

[Ashutosh Kelkar]

> On Sept. 26, 2013, 1:30 a.m., Sheng Yang wrote:
> > Please test it before submit.
> 
> Ashutosh Kelkar wrote:
> The tests have been tested and run correctly. There is a manual step 
> needed in setup for these tests - Adding host tags to the hosts which is why 
> the tests are skipped when committing.
> 
> Sheng Yang wrote:
> No, looks like the test case added storage tag instead of host tag. Don't 
> know how it could run.

The tests don't add the tags to the host themselves. The host tagging is done 
manually before running the tests. The tests don't create any tags storage or 
host. Could you please point me to where you think this is happening in the 
tests?


- Ashutosh


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


On Sept. 18, 2013, 2:28 p.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14058/
> ---
> 
> (Updated Sept. 18, 2013, 2:28 p.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, venkata swamy babu  
> budumuru, and Sheng Yang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added 10 tests for VPC VM liftcycle on tagged hosts
> 
> New class added  : TestVMLifeCycleDiffHosts
> 
> def test_01_deploy_instance_in_network(self):
> def test_02_stop_instance_in_network(self):
> def test_03_start_instance_in_network(self):
> def test_04_reboot_instance_in_network(self):
> def test_05_destroy_instance_in_network(self):
> def test_06_recover_instance_in_network(self):
> def test_07_migrate_instance_in_network(self):
> def test_08_user_data(self):
> def test_09_meta_data(self):
> def   test_10_expunge_instance_in_network(self):
> 
> This set of tests requires a multi host tagged setup (3 hosts - 2 hosts with 
> tag 'host1' and  1 host with tag 'host2')
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_vpc_vm_life_cycle.py 9844c1f 
> 
> Diff: https://reviews.apache.org/r/14058/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

CS4.2 KVM VM Snapshot not implement yet?

[Jijun]

hi all,

i install CS4.2 from the url : http://cloudstack.apt-get.eu/ubuntu/ ,
then create Basic Zone with KVM host added,then create some vms 
,everything work fine.


create vm snapshot for one stopped vm, the snapshot progress is always 
with state "Creating".


Management Server log :
2013-09-29 09:35:23,600 WARN  [agent.manager.AgentManagerImpl] 
(Job-Executor-2:job-84 = [ 538f1c49-f0fc-425c-a1c8-f2216cfad797 ]) 
Unsupported Command: Unsupported command 
issued:com.cloud.agent.api.CreateVMSnapshotCommand.  Are you sure you 
got the right type of server?


 seem that it is  a bug?


https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots

--
Thanks,
Jijun

Re: my two cents on RBAC/authorization

[Darren Shepherd]

So this will replace the commands.properties.  If one adds a new api, will they 
need to update the DB?

Darren

On Sep 29, 2013, at 5:15 PM, Min Chen  wrote:

>> 
>> 
>> 
>> One random question, I'm interested in knowing what the relationship
>> between commands.props and this new rbac thing will be.
> 
> We have categorized two types of permission, one is API level permission
> to work with current ApiChecker (what kind of APIs are allowed to be
> accessed by a particular role), the other is entity level permission (what
> access type we want to grant to a group on a particular entity instance).
> Previous commands.properties will be stored in acl_api_permission table to
> indicate what APIs can be accessed by a particular role. Out-of-box, we
> have Admin, DomainAdmin, and User roles to match with current Account_type.
> 
> Thanks
> -min
> 
> 
>> 
>> Darren
>> 
>>> On Sep 29, 2013, at 4:28 PM, Darren Shepherd
>>>  wrote:
>>> 
>>> I look forward to the proposal.  Based on your short comments and the
>>> artifacts I've seen so, I'll warn you that I'll probably disagree
>>> strongly with the implement
>>> 
>>> Darren
>>> 
 On Sep 29, 2013, at 12:04 PM, Min Chen  wrote:
 
 RBAC branch was created by Prachi and me to do some quick prototype on
 rbac feature we are going to propose in the community soon. Since it is
 not ready yet, we haven't proposed and published FS on the ML.
 
 In this prototype, we have group, accout, role, permission as our
 first class object. Unlike Amazon, cloudstack ACL is mainly done at
 Account level, so our Group will be a collection of accounts instead of
 users. Different from Darren suggested here, we didn't extract a
 separate Policy object to
 Group several permissions to a policy, because we didn't see a big
 benefit to store collections of permissions as a Json policy object
 compared to storing each individual permission into a permission table.
 Another reason why we store individual permission in db table is to
 facilitate implementing row-level permission filter for list Apis,
 where we have created DB views to determine entities to be returned.
 With a separate permission table, we can potentially join that table in
 db view for row filtering in read operation. In terms of integrating
 with third-party RBAC system, I don't see a big difference between
 re-creating policy object using cloudstack defined Json format and
 asking them to define those permissions through cloudstack provided
 permission grant Apis.
 
 Thanks
 -min
 
 Sent from my iPhone
 
> On Sep 28, 2013, at 8:51 PM, "Darren Shepherd"
>  wrote:
> 
> I've noticed there's a rbac branch and things are being committed
> there.  I didn't see any documentation about the design or anything
> (maybe it exists and I looked in the wrong place), so I'm just going
> to give you my two cents on authorization systems.  Hopefully this
> falls in line with what is being implemented, if not, at least we'll
> avoid the awkward conversation when its finish when I say the code is
> marginally useful and should be rewritten.
> 
> When talking about authorization there's a bunch of terms like
> principal, permission, subject, action, policy, etc.  I want to focus
> on policy.  Policy is central to an authorization system.  The policy
> is the collection of permissions that grant or deny access to some
> resource or action for a given subject.  RBAC is a really just a means
> to generate a policy.  Once you know the user, group, roles, and the
> permissions of those entities that aggregation of information forms
> the policy.  You then take that policy and use it determine if the
> given resource/action is granted/denied to a particular subject.
> 
> It is really important that policy is a first class object in an
> authorization system.  This is important to understand because usually
> in a big fat enterprise-y company, they really want you to enforce the
> policy, but not necessarily maintain it.  For example, you'll go to
> your fortune 500 company and they'll tell you they need RBAC.  So you
> go and create an RBAC system.  The problem is that the fortune 500
> company probably already has a RBAC system, and its probably AD based.
> So when they said they need RBAC, the really meant you need to
> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
> your good, if you implemented RBAC - > Authorization, your kinda
> screwed. Now you need to create a system to sync the two RBACs.  And
> keeping data in two places and trying to sync them is never a good
> idea.  Now if you implemented your system as having a policy as a
> first class object, you can just swap your RBAC for theirs and all is
> still swell.
> 
> So if I was to implement this, this is

Re: my two cents on RBAC/authorization

[Min Chen]

>
>
>
>One random question, I'm interested in knowing what the relationship
>between commands.props and this new rbac thing will be.

We have categorized two types of permission, one is API level permission
to work with current ApiChecker (what kind of APIs are allowed to be
accessed by a particular role), the other is entity level permission (what
access type we want to grant to a group on a particular entity instance).
Previous commands.properties will be stored in acl_api_permission table to
indicate what APIs can be accessed by a particular role. Out-of-box, we
have Admin, DomainAdmin, and User roles to match with current Account_type.

Thanks
-min


>
>Darren
>
>> On Sep 29, 2013, at 4:28 PM, Darren Shepherd
>> wrote:
>> 
>> I look forward to the proposal.  Based on your short comments and the
>>artifacts I've seen so, I'll warn you that I'll probably disagree
>>strongly with the implement
>> 
>> Darren
>> 
>>> On Sep 29, 2013, at 12:04 PM, Min Chen  wrote:
>>> 
>>> RBAC branch was created by Prachi and me to do some quick prototype on
>>>rbac feature we are going to propose in the community soon. Since it is
>>>not ready yet, we haven't proposed and published FS on the ML.
>>> 
>>> In this prototype, we have group, accout, role, permission as our
>>>first class object. Unlike Amazon, cloudstack ACL is mainly done at
>>>Account level, so our Group will be a collection of accounts instead of
>>>users. Different from Darren suggested here, we didn't extract a
>>>separate Policy object to
>>> Group several permissions to a policy, because we didn't see a big
>>>benefit to store collections of permissions as a Json policy object
>>>compared to storing each individual permission into a permission table.
>>>Another reason why we store individual permission in db table is to
>>>facilitate implementing row-level permission filter for list Apis,
>>>where we have created DB views to determine entities to be returned.
>>>With a separate permission table, we can potentially join that table in
>>>db view for row filtering in read operation. In terms of integrating
>>>with third-party RBAC system, I don't see a big difference between
>>>re-creating policy object using cloudstack defined Json format and
>>>asking them to define those permissions through cloudstack provided
>>>permission grant Apis.
>>> 
>>> Thanks
>>> -min
>>> 
>>> Sent from my iPhone
>>> 
 On Sep 28, 2013, at 8:51 PM, "Darren Shepherd"
 wrote:
 
 I've noticed there's a rbac branch and things are being committed
 there.  I didn't see any documentation about the design or anything
 (maybe it exists and I looked in the wrong place), so I'm just going
 to give you my two cents on authorization systems.  Hopefully this
 falls in line with what is being implemented, if not, at least we'll
 avoid the awkward conversation when its finish when I say the code is
 marginally useful and should be rewritten.
 
 When talking about authorization there's a bunch of terms like
 principal, permission, subject, action, policy, etc.  I want to focus
 on policy.  Policy is central to an authorization system.  The policy
 is the collection of permissions that grant or deny access to some
 resource or action for a given subject.  RBAC is a really just a means
 to generate a policy.  Once you know the user, group, roles, and the
 permissions of those entities that aggregation of information forms
 the policy.  You then take that policy and use it determine if the
 given resource/action is granted/denied to a particular subject.
 
 It is really important that policy is a first class object in an
 authorization system.  This is important to understand because usually
 in a big fat enterprise-y company, they really want you to enforce the
 policy, but not necessarily maintain it.  For example, you'll go to
 your fortune 500 company and they'll tell you they need RBAC.  So you
 go and create an RBAC system.  The problem is that the fortune 500
 company probably already has a RBAC system, and its probably AD based.
 So when they said they need RBAC, the really meant you need to
 enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
 your good, if you implemented RBAC - > Authorization, your kinda
 screwed. Now you need to create a system to sync the two RBACs.  And
 keeping data in two places and trying to sync them is never a good
 idea.  Now if you implemented your system as having a policy as a
 first class object, you can just swap your RBAC for theirs and all is
 still swell.
 
 So if I was to implement this, this is how I'd do it.  (And if this
 sounds a lot like IAM, its because it is.  If Amazon got anything
 right, it's IAM).  The authenticator should be able to implement
 another interface that allows it to supply a Policy object during
 authentication.  This is logical in that the authent

Re: my two cents on RBAC/authorization

[Darren Shepherd]

Oops accidentally sent the last email before I finished. 

I'll probably disagree with the implementation.  It sounds like your scope 
right now is very simple and small and thus your are doing a very simple 
approach.  But that in my mind will lead to either 1) you scrap and rewrite the 
thing when requirements get more complex 2) you try to build on it and you'll 
end up with mess.  But I'll wait for the proposal, I could be wrong here. 

One random question, I'm interested in knowing what the relationship between 
commands.props and this new rbac thing will be.

Darren

> On Sep 29, 2013, at 4:28 PM, Darren Shepherd  
> wrote:
> 
> I look forward to the proposal.  Based on your short comments and the 
> artifacts I've seen so, I'll warn you that I'll probably disagree strongly 
> with the implement
> 
> Darren
> 
>> On Sep 29, 2013, at 12:04 PM, Min Chen  wrote:
>> 
>> RBAC branch was created by Prachi and me to do some quick prototype on rbac 
>> feature we are going to propose in the community soon. Since it is not ready 
>> yet, we haven't proposed and published FS on the ML.
>> 
>> In this prototype, we have group, accout, role, permission as our first 
>> class object. Unlike Amazon, cloudstack ACL is mainly done at Account level, 
>> so our Group will be a collection of accounts instead of users. Different 
>> from Darren suggested here, we didn't extract a separate Policy object to
>> 
>> Group several permissions to a policy, because we didn't see a big benefit 
>> to store collections of permissions as a Json policy object compared to 
>> storing each individual permission into a permission table. Another reason 
>> why we store individual permission in db table is to facilitate implementing 
>> row-level permission filter for list Apis, where we have created DB views to 
>> determine entities to be returned. With a separate permission table, we can 
>> potentially join that table in db view for row filtering in read operation. 
>> In terms of integrating with third-party RBAC system, I don't see a big 
>> difference between re-creating policy object using cloudstack defined Json 
>> format and asking them to define those permissions through cloudstack 
>> provided permission grant Apis.
>> 
>> Thanks
>> -min
>> 
>> Sent from my iPhone
>> 
>>> On Sep 28, 2013, at 8:51 PM, "Darren Shepherd" 
>>>  wrote:
>>> 
>>> I've noticed there's a rbac branch and things are being committed
>>> there.  I didn't see any documentation about the design or anything
>>> (maybe it exists and I looked in the wrong place), so I'm just going
>>> to give you my two cents on authorization systems.  Hopefully this
>>> falls in line with what is being implemented, if not, at least we'll
>>> avoid the awkward conversation when its finish when I say the code is
>>> marginally useful and should be rewritten.
>>> 
>>> When talking about authorization there's a bunch of terms like
>>> principal, permission, subject, action, policy, etc.  I want to focus
>>> on policy.  Policy is central to an authorization system.  The policy
>>> is the collection of permissions that grant or deny access to some
>>> resource or action for a given subject.  RBAC is a really just a means
>>> to generate a policy.  Once you know the user, group, roles, and the
>>> permissions of those entities that aggregation of information forms
>>> the policy.  You then take that policy and use it determine if the
>>> given resource/action is granted/denied to a particular subject.
>>> 
>>> It is really important that policy is a first class object in an
>>> authorization system.  This is important to understand because usually
>>> in a big fat enterprise-y company, they really want you to enforce the
>>> policy, but not necessarily maintain it.  For example, you'll go to
>>> your fortune 500 company and they'll tell you they need RBAC.  So you
>>> go and create an RBAC system.  The problem is that the fortune 500
>>> company probably already has a RBAC system, and its probably AD based.
>>> So when they said they need RBAC, the really meant you need to
>>> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
>>> your good, if you implemented RBAC - > Authorization, your kinda
>>> screwed. Now you need to create a system to sync the two RBACs.  And
>>> keeping data in two places and trying to sync them is never a good
>>> idea.  Now if you implemented your system as having a policy as a
>>> first class object, you can just swap your RBAC for theirs and all is
>>> still swell.
>>> 
>>> So if I was to implement this, this is how I'd do it.  (And if this
>>> sounds a lot like IAM, its because it is.  If Amazon got anything
>>> right, it's IAM).  The authenticator should be able to implement
>>> another interface that allows it to supply a Policy object during
>>> authentication.  This is logical in that the authentication systems
>>> quite often hold authorization information too.  If the authenticator
>>> doesn't implement the interface we 

Re: my two cents on RBAC/authorization

[Darren Shepherd]

I look forward to the proposal.  Based on your short comments and the artifacts 
I've seen so, I'll warn you that I'll probably disagree strongly with the 
implement

Darren

> On Sep 29, 2013, at 12:04 PM, Min Chen  wrote:
> 
> RBAC branch was created by Prachi and me to do some quick prototype on rbac 
> feature we are going to propose in the community soon. Since it is not ready 
> yet, we haven't proposed and published FS on the ML.
> 
> In this prototype, we have group, accout, role, permission as our first class 
> object. Unlike Amazon, cloudstack ACL is mainly done at Account level, so our 
> Group will be a collection of accounts instead of users. Different from 
> Darren suggested here, we didn't extract a separate Policy object to
> Group several permissions to a policy, because we didn't see a big benefit to 
> store collections of permissions as a Json policy object compared to storing 
> each individual permission into a permission table. Another reason why we 
> store individual permission in db table is to facilitate implementing 
> row-level permission filter for list Apis, where we have created DB views to 
> determine entities to be returned. With a separate permission table, we can 
> potentially join that table in db view for row filtering in read operation. 
> In terms of integrating with third-party RBAC system, I don't see a big 
> difference between re-creating policy object using cloudstack defined Json 
> format and asking them to define those permissions through cloudstack 
> provided permission grant Apis.
> 
> Thanks
> -min
> 
> Sent from my iPhone
> 
>> On Sep 28, 2013, at 8:51 PM, "Darren Shepherd"  
>> wrote:
>> 
>> I've noticed there's a rbac branch and things are being committed
>> there.  I didn't see any documentation about the design or anything
>> (maybe it exists and I looked in the wrong place), so I'm just going
>> to give you my two cents on authorization systems.  Hopefully this
>> falls in line with what is being implemented, if not, at least we'll
>> avoid the awkward conversation when its finish when I say the code is
>> marginally useful and should be rewritten.
>> 
>> When talking about authorization there's a bunch of terms like
>> principal, permission, subject, action, policy, etc.  I want to focus
>> on policy.  Policy is central to an authorization system.  The policy
>> is the collection of permissions that grant or deny access to some
>> resource or action for a given subject.  RBAC is a really just a means
>> to generate a policy.  Once you know the user, group, roles, and the
>> permissions of those entities that aggregation of information forms
>> the policy.  You then take that policy and use it determine if the
>> given resource/action is granted/denied to a particular subject.
>> 
>> It is really important that policy is a first class object in an
>> authorization system.  This is important to understand because usually
>> in a big fat enterprise-y company, they really want you to enforce the
>> policy, but not necessarily maintain it.  For example, you'll go to
>> your fortune 500 company and they'll tell you they need RBAC.  So you
>> go and create an RBAC system.  The problem is that the fortune 500
>> company probably already has a RBAC system, and its probably AD based.
>> So when they said they need RBAC, the really meant you need to
>> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
>> your good, if you implemented RBAC - > Authorization, your kinda
>> screwed. Now you need to create a system to sync the two RBACs.  And
>> keeping data in two places and trying to sync them is never a good
>> idea.  Now if you implemented your system as having a policy as a
>> first class object, you can just swap your RBAC for theirs and all is
>> still swell.
>> 
>> So if I was to implement this, this is how I'd do it.  (And if this
>> sounds a lot like IAM, its because it is.  If Amazon got anything
>> right, it's IAM).  The authenticator should be able to implement
>> another interface that allows it to supply a Policy object during
>> authentication.  This is logical in that the authentication systems
>> quite often hold authorization information too.  If the authenticator
>> doesn't implement the interface we fall back to generating the policy
>> ourself.  The policy is then consulted to see if the API command and
>> the resulting entities are granted/denied.  So far none of this has
>> anything to do with RBAC.  So the RBAC is implemented in that default
>> fallback implemenation that generates the policy.  You map the current
>> user/account to groups and roles and get the policies of those
>> entities to construct the policy.
>> 
>> Now for storing the policies I wouldn't do it in a traditional
>> normalized form.  All you need is tables for user/group/role and the
>> mappings for each.  The for user, group, and role you can specify a
>> policy JSON blob and that gets stored in the database as a mediumtext
>> field on th

Re: my two cents on RBAC/authorization

[Min Chen]

RBAC branch was created by Prachi and me to do some quick prototype on rbac 
feature we are going to propose in the community soon. Since it is not ready 
yet, we haven't proposed and published FS on the ML.

In this prototype, we have group, accout, role, permission as our first class 
object. Unlike Amazon, cloudstack ACL is mainly done at Account level, so our 
Group will be a collection of accounts instead of users. Different from Darren 
suggested here, we didn't extract a separate Policy object to
Group several permissions to a policy, because we didn't see a big benefit to 
store collections of permissions as a Json policy object compared to storing 
each individual permission into a permission table. Another reason why we store 
individual permission in db table is to facilitate implementing row-level 
permission filter for list Apis, where we have created DB views to determine 
entities to be returned. With a separate permission table, we can potentially 
join that table in db view for row filtering in read operation. In terms of 
integrating with third-party RBAC system, I don't see a big difference between 
re-creating policy object using cloudstack defined Json format and asking them 
to define those permissions through cloudstack provided permission grant Apis.

Thanks
-min

Sent from my iPhone

On Sep 28, 2013, at 8:51 PM, "Darren Shepherd"  
wrote:

> I've noticed there's a rbac branch and things are being committed
> there.  I didn't see any documentation about the design or anything
> (maybe it exists and I looked in the wrong place), so I'm just going
> to give you my two cents on authorization systems.  Hopefully this
> falls in line with what is being implemented, if not, at least we'll
> avoid the awkward conversation when its finish when I say the code is
> marginally useful and should be rewritten.
> 
> When talking about authorization there's a bunch of terms like
> principal, permission, subject, action, policy, etc.  I want to focus
> on policy.  Policy is central to an authorization system.  The policy
> is the collection of permissions that grant or deny access to some
> resource or action for a given subject.  RBAC is a really just a means
> to generate a policy.  Once you know the user, group, roles, and the
> permissions of those entities that aggregation of information forms
> the policy.  You then take that policy and use it determine if the
> given resource/action is granted/denied to a particular subject.
> 
> It is really important that policy is a first class object in an
> authorization system.  This is important to understand because usually
> in a big fat enterprise-y company, they really want you to enforce the
> policy, but not necessarily maintain it.  For example, you'll go to
> your fortune 500 company and they'll tell you they need RBAC.  So you
> go and create an RBAC system.  The problem is that the fortune 500
> company probably already has a RBAC system, and its probably AD based.
> So when they said they need RBAC, the really meant you need to
> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
> your good, if you implemented RBAC - > Authorization, your kinda
> screwed. Now you need to create a system to sync the two RBACs.  And
> keeping data in two places and trying to sync them is never a good
> idea.  Now if you implemented your system as having a policy as a
> first class object, you can just swap your RBAC for theirs and all is
> still swell.
> 
> So if I was to implement this, this is how I'd do it.  (And if this
> sounds a lot like IAM, its because it is.  If Amazon got anything
> right, it's IAM).  The authenticator should be able to implement
> another interface that allows it to supply a Policy object during
> authentication.  This is logical in that the authentication systems
> quite often hold authorization information too.  If the authenticator
> doesn't implement the interface we fall back to generating the policy
> ourself.  The policy is then consulted to see if the API command and
> the resulting entities are granted/denied.  So far none of this has
> anything to do with RBAC.  So the RBAC is implemented in that default
> fallback implemenation that generates the policy.  You map the current
> user/account to groups and roles and get the policies of those
> entities to construct the policy.
> 
> Now for storing the policies I wouldn't do it in a traditional
> normalized form.  All you need is tables for user/group/role and the
> mappings for each.  The for user, group, and role you can specify a
> policy JSON blob and that gets stored in the database as a mediumtext
> field on the user/group/role row.  From an API perspective (just like
> IAM), you just let people upload the JSON blobs for each.
> 
> So if we do it this way, we can have our own simple RBAC but then be
> able to plug into far more complex and powerful authorization systems.
> Hopefully that all made sense.
> 
> Darren

Re: [DISCUSS] UI: New look and feel

[Shiva Teja]

On Fri, Sep 27, 2013 at 5:44 PM, SuichII, Christopher <
chris.su...@netapp.com> wrote:

>
> Shiva & Sebastien - What impact would this angular.js project have on UI
> plugins?



It would definitely make it easy and offer cleaner code. I'll try to write
an overview soon. In a brief way :

1. You don't have to write any API calls. They'll be taken care by the
resources modules[0].
2. You don't have to do any DOM manipulation. Angular's directives[1] that
we write will take care of them.
3. There's no 'listView' or 'detailView'. Each plugin can have its own
template(s)[2]. These templates must be very small if directives are used
effectively. 'confirm', 'vm-state-label', 'ng-repeat' are some of the
directives you can see in the template given at the end for example usage.

Every tab that you see on the side nav bar in this UI is a plugin. So you
can checkout any plugin to start with.

Demo is running at http://students.iitmandi.ac.in:2/ . It is running on
DevCloud. Feel free to play around. Username and password are the default
ones: admin-password.

As far as themes are concerned, I used bootstrap. So there are lots of
bootstrap themes out there which can be easily added to this UI without
worrying about breaking things.

I am yet to add unit tests, add the functionalities to bring at par with
the current UI and clean up the designs. Maybe we could have both the UIs
for some time and then see how things go. If anybody is interested in
joining the further development, please let me know :)

[0]
https://github.com/shivateja/cloudstack-ui/tree/angular-rawapi/static/js/common/resources
[1]
https://github.com/shivateja/cloudstack-ui/tree/angular-rawapi/static/js/common/directives
[2] This is an example template :
https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/app/instances/instances.tpl.html

Thanks,
Shiva Teja

Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Some progress (I think).

Now I get this error message instead:

log4j:WARN No appenders could be found for logger
(org.apache.commons.httpclient.params.DefaultHttpParams).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
Caused by: java.lang.UnsatisfiedLinkError: Can't obtain updateLastError
method for class com.sun.jna.Native
at com.sun.jna.Native.initIDs(Native Method)
at com.sun.jna.Native.(Native.java:139)
at org.libvirt.jna.Libvirt.(Unknown Source)
at org.libvirt.Library.(Unknown Source)
at org.libvirt.Connect.(Unknown Source)
at
com.cloud.hypervisor.kvm.resource.LibvirtConnection.getConnection(LibvirtConnection.java:44)
at
com.cloud.hypervisor.kvm.resource.LibvirtConnection.getConnection(LibvirtConnection.java:37)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:733)
at com.cloud.agent.Agent.(Agent.java:161)
at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:421)
at com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:376)
at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:357)
at com.cloud.agent.AgentShell.start(AgentShell.java:454)
... 5 more
Cannot start daemon
Service exit with a return value of 5


On Sun, Sep 29, 2013 at 4:23 AM, Wido den Hollander  wrote:

>
>
> On 09/29/2013 08:01 AM, Wei ZHOU wrote:
>
>> try backup and remove the jna.jar in /usr/share/java
>>
>>
> I fixed the init scripts, it was still including the old JNA in the
> classpath: https://git-wip-us.apache.org/**repos/asf?p=cloudstack.git;a=**
> commit;h=**e6fd794ca0b10a00f3fc93e5f3e81a**b342f5b860
>
> That should fix it!
>
> Wido
>
>
>  2013/9/29, Mike Tutkowski **:
>>
>>> Hi Wei,
>>>
>>> So, re-installing cloudstack-common allowed cloudstack-agent to install
>>> successfuly. Thanks
>>>
>>> I'm still having what appears to be Libvirt-related issues on Ubuntu
>>> 12.04
>>> with master.
>>>
>>> Any thoughts on this?
>>>
>>> log4j:WARN No appenders could be found for logger
>>> (org.apache.commons.**httpclient.params.**DefaultHttpParams).
>>> log4j:WARN Please initialize the log4j system properly.
>>> log4j:WARN See 
>>> http://logging.apache.org/**log4j/1.2/faq.html#noconfigfor
>>> more info.
>>> java.lang.reflect.**InvocationTargetException
>>> at sun.reflect.**NativeMethodAccessorImpl.**invoke0(Native Method)
>>> at
>>> sun.reflect.**NativeMethodAccessorImpl.**invoke(**
>>> NativeMethodAccessorImpl.java:**57)
>>> at
>>> sun.reflect.**DelegatingMethodAccessorImpl.**invoke(**
>>> DelegatingMethodAccessorImpl.**java:43)
>>> at java.lang.reflect.Method.**invoke(Method.java:606)
>>> at
>>> org.apache.commons.daemon.**support.DaemonLoader.start(**
>>> DaemonLoader.java:243)
>>> Caused by: java.lang.NoSuchMethodError: com.sun.jna.Native.free(J)V
>>> at org.libvirt.Library.free(**Unknown Source)
>>> at org.libvirt.Connect.**getCapabilities(Unknown Source)
>>> at
>>> com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResource.**
>>> IsHVMEnabled(**LibvirtComputingResource.java:**4533)
>>> at
>>> com.cloud.hypervisor.kvm.**resource.**LibvirtComputingResource.**
>>> configure(**LibvirtComputingResource.java:**747)
>>> at com.cloud.agent.Agent.(**Agent.java:161)
>>> at com.cloud.agent.AgentShell.**launchAgent(AgentShell.java:**421)
>>> at com.cloud.agent.AgentShell.**launchAgentFromClassInfo(**
>>> AgentShell.java:376)
>>> at com.cloud.agent.AgentShell.**launchAgent(AgentShell.java:**357)
>>> at com.cloud.agent.AgentShell.**start(AgentShell.java:454)
>>> ... 5 more
>>> Cannot start daemon
>>> Service exit with a return value of 5
>>>
>>>
>>> On Fri, Sep 27, 2013 at 1:45 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
>>>  Looks like listNetworks() is called a couple times in
 cloudstack-agent-upgrade:

 if __name__ == '__main__':
 netlib = networkConfig()
 bridges = netlib.listNetworks()
 bridges = filter(isOldStyleBridge, bridges)
 for br in bridges:
 enslavedDev = netlib.getEnslavedDev(br, 1)
 if enslavedDev is not None:
 upgradeBridgeName(br, enslavedDev)

 bridges = netlib.listNetworks()
 bridges = filter(isOldStyleBridge, bridges)
 if len(bridges) > 0:
 print("Warning: upgrade is not finished, still some bridges have
 the old style name:" + str(bridges))
>

Re: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS service is restarted

[Koushik Das]

Ilya,
Can you check in the MS logs if more than one thread tries to process connect 
for the same host simultaneously? In case of XS I had seen that there is a 
possibility of the vm states getting incorrectly determined (during vm sync) in 
case more than one thread tries to process connect to the host simultaneously. 
The fix for 4636 can be added to the 4.1.x branch but if the root cause turns 
out to be the same.

-Koushik

On 26-Sep-2013, at 9:18 PM, "Musayev, Ilya"  wrote:

> ++Koushik
> 
> Thanks Sowmya
> 
> Koushik 
> 
> Any reason why this is cannot be applied to ACS 4.1?  Since I'm Release 
> Manager for 4.1.x branch, I will work on testing and releasing 4.1.2
> 
> Thanks
> ilya
> 
>> -Original Message-
>> From: Sowmya Krishnan [mailto:sowmya.krish...@citrix.com]
>> Sent: Thursday, September 26, 2013 3:03 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS
>> service is restarted
>> 
>> Ilya,
>> Is this similar to this issue:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-4636
>> Fix for this has gone in 4.2-forward and master. As stated in the bug, this
>> could happen if more than one thread tries to process the same host post
>> MS restart.
>> 
>>> -Original Message-
>>> From: Musayev, Ilya [mailto:imusa...@webmd.net]
>>> Sent: Thursday, September 26, 2013 3:43 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: [MAJOR][BUG] ACS powers off some VMs in vSphere - when
>> MS
>>> service is restarted
>>> 
>>> Sorry if the error log is abit hard to read, as an example, please
>>> track the vmname i-2-262-acs-docs-fc17.
>>> 
>>> 2013-09-25 14:35:49,928 DEBUG [vmware.resource.VmwareResource]
>>> (AgentTaskPool-1:null) Detecting a new state but couldn't find a old
>>> state so adding it to the changes: i-2-262-acs-docs-fc17
>>> 2013-09-25 14:35:53,614 DEBUG [cloud.vm.VirtualMachineManagerImpl]
>>> (AgentTaskPool-1:null) VM i-2-262-acs-docs-fc17: cs state = Running
>>> and realState = Stopped
>>> 2013-09-25 14:35:53,614 DEBUG [cloud.vm.VirtualMachineManagerImpl]
>>> (AgentTaskPool-1:null) VM i-2-262-acs-docs-fc17: cs state = Running
>>> and realState = Stopped
>>> 2013-09-25 14:35:53,614 INFO  [cloud.ha.HighAvailabilityManagerImpl]
>>> (AgentTaskPool-1:null) Skip HA for VMware VM i-2-262-acs-docs-fc17
>>> 2013-09-25 14:35:53,694 DEBUG [agent.transport.Request]
>>> (AgentTaskPool-
>>> 1:null) Seq 11-1418264581: Sending  { Cmd , MgmtId: 345049078181, via:
>>> 11,
>>> Ver: v1, Flags: 100101,
>>> [{"StopCommand":{"isProxy":false,"vmName":"i-2-262-
>>> acs-docs-fc17","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-
>>> 2-
>>> 278-demo01t-ops-
>>> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-281-acs-
>>> appliance","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-28
>>> 3-
>>> vmbld01l-ops-
>> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"
>>> i-2-
>>> 285-ossec01l-ops-08","wait":0}}] }
>>> 2013-09-25 14:35:53,695 DEBUG [agent.transport.Request]
>>> (AgentTaskPool-
>>> 1:null) Seq 11-1418264581: Executing:  { Cmd , MgmtId: 345049078181,
>>> via: 11,
>>> Ver: v1, Flags: 100101,
>>> [{"StopCommand":{"isProxy":false,"vmName":"i-2-262-
>>> acs-docs-fc17","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-
>>> 2-
>>> 278-demo01t-ops-
>>> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-281-acs-
>>> appliance","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-28
>>> 3-
>>> vmbld01l-ops-
>> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"
>>> i-2-
>>> 285-ossec01l-ops-08","wait":0}}] }
>>> 2013-09-25 14:35:53,702 INFO  [vmware.resource.VmwareResource]
>>> (DirectAgent-3:vmha62d-ops-08.portal.webmd.com) Executing resource
>>> StopCommand:
>>> {"isProxy":false,"vmName":"i-2-262-acs-docs-fc17","wait":0}
>>> 2013-09-25 14:35:53,703 DEBUG [vmware.mo.HostMO] (DirectAgent-
>>> 3:vmha62d-ops-08.portal.webmd.com) find VM i-2-262-acs-docs-fc17 on
>>> host
>>> 2013-09-25 14:35:54,753 INFO  [vmware.resource.VmwareResource]
>>> (DirectAgent-3:vmha62d-ops-08.portal.webmd.com) VM
>>> i-2-262-acs-docs-fc17 is already in stopped state
>>> 
 -Original Message-
 From: Musayev, Ilya [mailto:imusa...@webmd.net]
 Sent: Wednesday, September 25, 2013 6:08 PM
 To: dev@cloudstack.apache.org
 Subject: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS
 service is restarted
 
 Hi All,
 
 I'd like to raise an awareness on the issue with ACS 4.1.1 (I assume
 other versions are affected - since I could not find any changes in
 the latest code that would state otherwise).
 
 On MS server start/restart, it checks all the VMs for their state,
 if some reason state is either not found or comes as stopped - which
 is inaccurate, the vms will *power off*.
 
 On todays occurrence, half of my plant  went down because ACS
 invoked StopCommand on the vms that either had no state or for some
 reason agentState 

Re: my two cents on RBAC/authorization

[Koushik Das]

I think it is important to identify what is exclusively for Cloudstack and what 
all can be reused across multiple services.

1. Authentication - Typically enterprises/service providers would like to reuse 
their existing authentication systems. So an easy mechanism needs to be 
provided for integrating with them. A built-in authentication provider can be 
there as it is today.
2. Mapping the user identity to a role - Once the user identity is established, 
it is mapped to a role based on some well defined policies/rules. This is again 
something that can be reused across multiple services and enterprises would 
already have it. So the same thing applies as #1.
3. Authorization - This is something that is specific to a service. Once the 
role is established, it is up to the specific service to determine what kind of 
access control needs to be enforced. The request that comes to Cloudstack will 
have some authorization token with the role information. Now based on this role 
a decision is to be made whether to allow or deny. This needs to be 
customizable.
4. Audit - This is again specific to a service and can be as simple as logging. 
But there needs to be a way to customize this as well to take some specific 
action.

-Koushik


On 29-Sep-2013, at 9:21 AM, Darren Shepherd  wrote:

> I've noticed there's a rbac branch and things are being committed
> there.  I didn't see any documentation about the design or anything
> (maybe it exists and I looked in the wrong place), so I'm just going
> to give you my two cents on authorization systems.  Hopefully this
> falls in line with what is being implemented, if not, at least we'll
> avoid the awkward conversation when its finish when I say the code is
> marginally useful and should be rewritten.
> 
> When talking about authorization there's a bunch of terms like
> principal, permission, subject, action, policy, etc.  I want to focus
> on policy.  Policy is central to an authorization system.  The policy
> is the collection of permissions that grant or deny access to some
> resource or action for a given subject.  RBAC is a really just a means
> to generate a policy.  Once you know the user, group, roles, and the
> permissions of those entities that aggregation of information forms
> the policy.  You then take that policy and use it determine if the
> given resource/action is granted/denied to a particular subject.
> 
> It is really important that policy is a first class object in an
> authorization system.  This is important to understand because usually
> in a big fat enterprise-y company, they really want you to enforce the
> policy, but not necessarily maintain it.  For example, you'll go to
> your fortune 500 company and they'll tell you they need RBAC.  So you
> go and create an RBAC system.  The problem is that the fortune 500
> company probably already has a RBAC system, and its probably AD based.
> So when they said they need RBAC, the really meant you need to
> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
> your good, if you implemented RBAC - > Authorization, your kinda
> screwed. Now you need to create a system to sync the two RBACs.  And
> keeping data in two places and trying to sync them is never a good
> idea.  Now if you implemented your system as having a policy as a
> first class object, you can just swap your RBAC for theirs and all is
> still swell.
> 
> So if I was to implement this, this is how I'd do it.  (And if this
> sounds a lot like IAM, its because it is.  If Amazon got anything
> right, it's IAM).  The authenticator should be able to implement
> another interface that allows it to supply a Policy object during
> authentication.  This is logical in that the authentication systems
> quite often hold authorization information too.  If the authenticator
> doesn't implement the interface we fall back to generating the policy
> ourself.  The policy is then consulted to see if the API command and
> the resulting entities are granted/denied.  So far none of this has
> anything to do with RBAC.  So the RBAC is implemented in that default
> fallback implemenation that generates the policy.  You map the current
> user/account to groups and roles and get the policies of those
> entities to construct the policy.
> 
> Now for storing the policies I wouldn't do it in a traditional
> normalized form.  All you need is tables for user/group/role and the
> mappings for each.  The for user, group, and role you can specify a
> policy JSON blob and that gets stored in the database as a mediumtext
> field on the user/group/role row.  From an API perspective (just like
> IAM), you just let people upload the JSON blobs for each.
> 
> So if we do it this way, we can have our own simple RBAC but then be
> able to plug into far more complex and powerful authorization systems.
> Hopefully that all made sense.
> 
> Darren

Re: Scalable Backup and Recovery

[kel...@backbonetechnology.com]

Even as a simple start it would be nice to have the option to back up/snapshot 
a VM (which means all volumes as a collection) and not just per volume. If I 
have 200 VMs with 3 volumes each, that's 600 snapshots and 400 attach disk 
actions. Now scale that out to your average production environment running 
1000s of VMs.

This becomes a logistical recovery nightmare.

We should have some kind of routine that allows snapping multiple volumes as a 
collection so those same volumes can be restored as a collection.

Just a thought.

Thanks,

-Kelcey

Sent from my HTC

- Reply message -
From: "Darren Shepherd" 
To: "dev@cloudstack.apache.org" 
Subject: Scalable Backup and Recovery
Date: Sat, Sep 28, 2013 9:22 PM

Based on your use cases it sounds like what your asking for is the
ability to create a selection criteria for scheduled snapshots.  So as
long as your VM/Volume matches that criteria it will be backed up at
some given time.  I think that would be useful because a user could
say something like "all volumes in network 'production' should be
backed up every night."

So if such a thing was implemented it seems like if the storage
provider implemented some capability to handle multiple snapshots at
once, then it could be passed all volumes at once and it would do
something intelligent.

Now reading between the lines, it seems like you're looking for some
use case to exploit some functionality in netapp.  I'll tell you what
I'd like to see implemented.  Having ran netapp in the past with CS we
ran into this conundrum.  We would take snapshots on the filter, but
in reality they were pretty useless.  If you ever needed to rollback
to the snapshot, your screwed.  Things have changed since the
snapshot, VMs were created, deleted, VM snapshots had occurred, etc.
So if you rollback the metadata in CS is completely out of sync now.
What I think would be a great feature is to be able to do StoragePool
snapshots.  Now doing the snapshot is simple, the really complex thing
is how to implement the "StoragePool revert to snapshot"
functionality.  If somebody could do that, that would be awesome.

Darren

On Sat, Sep 28, 2013 at 5:41 PM, SuichII, Christopher
 wrote:
> Well, yes, in part. By scalable I mean that if CloudStack is expected to be 
> able to manage such a large number of vms, it should be able to backup and 
> recover those vms with minimal effort. Doing things one at a time does not 
> necessarily scale well when you're talking about a cloud infrastructure.
>
>> Also certain hypervisors have various quirks which stand in the way of an
>> efficient solution.
>
> I absolutely agree. This is where the storage subsystem API comes in. 
> Creating backups for some storage providers can be much faster, easier and 
> more efficient than hypervisor. As the storage subsystem API gains more 
> traction and true backup and recovery becomes available, I think we'll begin 
> to see people asking why things must be done one at a time. The use cases I 
> listed below would help us get ahead of the curve and have these features I 
> predict people will be asking for (and it sounds like Kelcey is asking for it 
> now!).
>
> --
> Chris Suich
> chris.su...@netapp.com
> NetApp Software Engineer
> Data Center Platforms – Cloud Solutions
> Citrix, Cisco & Red Hat
>
> On Sep 27, 2013, at 6:38 PM, Chiradeep Vittal  
> wrote:
>
>> Ah I see. You mean a "scalable user experience".
>>
>> The actual scalability of the snapshot process itself is limited by
>> available disk and network bandwidth.
>> Also certain hypervisors have various quirks which stand in the way of an
>> efficient solution.
>>
>> On 9/27/13 10:27 AM, "SuichII, Christopher"  wrote:
>>
>>> I'd like to start a discussion around the direction of scalable backup
>>> and recovery in CloudStack. Currently, the only want to backup and
>>> recover vms is by setting up a schedule or manually snapshotting up
>>> individual vm disks or manually snapshotting vms. Unfortunately, I don't
>>> believe this is a very scalable solution. What if a user wants all of
>>> their vm disks to be backed up on the same schedule? What if a domain
>>> administrator wants all of the vms in their domain to be backed up on the
>>> same schedule or to manually backup every vm in their domain?
>>>
>>> Here are some use cases I see for helping to scale things up:
>>> -Scheduled and manual backup of 1 to all of a user's vms and vm disks
>>> -Scheduled and manual backup of 1 to all of a domain's vms and vm disks
>>> (by a domain admin)
>>> -Scheduled and manual backup of 1 to all vms and vm disks on primary
>>> storage (by a cloud admin) - this one is tougher to find a valid use case
>>> for
>>> -Backup schedules attached to service offerings
>>>
>>> I know I previously started a discussion about backing up multiple vm
>>> disks at once, but I think these use cases, broken down by user type
>>> (user, domain admin and admin), should help clear things up and show the
>>> utility of being able to b

Re: my outstanding patches on review board

[Sebastien Goasguen]

On 29 Sep 2013, at 06:02, Darren Shepherd  wrote:

> I have a bunch of outstanding patches on review board.  Now that I'm a
> committer I'm going to commit a bunch of then that I consider small
> and non-impacting.  I know this would normally be bad form, so I hope
> you'll excuse me this one time.  I really need to get all those
> committed because they are blocking me from getting all the Spring
> stuff prepared for review.  The longer I wait to get the spring stuff
> in, the more maintenance I have to do as people change stuff (like
> hyper-v, contrail, vxlan).
> 
> Darren

Ditto like Daan, i dont do java, but i know they are pending. As long as it 
doesnt break master go ahead :)

Maybe a jira ticket would allow us to track the changes to announce in the next 
release, even though they are not new features but code improvements.

Sebastien

Re: my two cents on RBAC/authorization

[Sebastien Goasguen]

On 29 Sep 2013, at 05:51, Darren Shepherd  wrote:

> I've noticed there's a rbac branch and things are being committed
> there.  I didn't see any documentation about the design or anything
> (maybe it exists and I looked in the wrong place), so I'm just going
> to give you my two cents on authorization systems.  Hopefully this
> falls in line with what is being implemented, if not, at least we'll
> avoid the awkward conversation when its finish when I say the code is
> marginally useful and should be rewritten.
> 
> When talking about authorization there's a bunch of terms like
> principal, permission, subject, action, policy, etc.  I want to focus
> on policy.  Policy is central to an authorization system.  The policy
> is the collection of permissions that grant or deny access to some
> resource or action for a given subject.  RBAC is a really just a means
> to generate a policy.  Once you know the user, group, roles, and the
> permissions of those entities that aggregation of information forms
> the policy.  You then take that policy and use it determine if the
> given resource/action is granted/denied to a particular subject.
> 
> It is really important that policy is a first class object in an
> authorization system.  This is important to understand because usually
> in a big fat enterprise-y company, they really want you to enforce the
> policy, but not necessarily maintain it.  For example, you'll go to
> your fortune 500 company and they'll tell you they need RBAC.  So you
> go and create an RBAC system.  The problem is that the fortune 500
> company probably already has a RBAC system, and its probably AD based.
> So when they said they need RBAC, the really meant you need to
> enforce RBAC.  If you implemented RBAC -> Policy -> Authorization,
> your good, if you implemented RBAC - > Authorization, your kinda
> screwed. Now you need to create a system to sync the two RBACs.  And
> keeping data in two places and trying to sync them is never a good
> idea.  Now if you implemented your system as having a policy as a
> first class object, you can just swap your RBAC for theirs and all is
> still swell.
> 
> So if I was to implement this, this is how I'd do it.  (And if this
> sounds a lot like IAM, its because it is.  If Amazon got anything
> right, it's IAM).

And it would be nice to implement a IAM interface, its quite neat actually.


>  The authenticator should be able to implement
> another interface that allows it to supply a Policy object during
> authentication.  This is logical in that the authentication systems
> quite often hold authorization information too.  If the authenticator
> doesn't implement the interface we fall back to generating the policy
> ourself.  The policy is then consulted to see if the API command and
> the resulting entities are granted/denied.  So far none of this has
> anything to do with RBAC.  So the RBAC is implemented in that default
> fallback implemenation that generates the policy.  You map the current
> user/account to groups and roles and get the policies of those
> entities to construct the policy.
> 
> Now for storing the policies I wouldn't do it in a traditional
> normalized form.  All you need is tables for user/group/role and the
> mappings for each.  The for user, group, and role you can specify a
> policy JSON blob and that gets stored in the database as a mediumtext
> field on the user/group/role row.  From an API perspective (just like
> IAM), you just let people upload the JSON blobs for each.
> 
> So if we do it this way, we can have our own simple RBAC but then be
> able to plug into far more complex and powerful authorization systems.
> Hopefully that all made sense.
> 
> Darren

Re: [ANNOUNCE] New Committer: Darren Shepherd

[Jayapal Reddy Uradi]

Congrats Darren!

-Jayapal

On 29-Sep-2013, at 10:12 AM, Alena Prokharchyk  
wrote:

> Congrats, Darren!
> 
> -Alena
> 
> From: Chip Childers 
> mailto:chip.child...@sungard.com>>
> Reply-To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Date: Saturday, September 28, 2013 5:24 AM
> To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Subject: [ANNOUNCE] New Committer: Darren Shepherd
> 
> The Project Management Committee (PMC) for Apache CloudStack
> has asked Darren Shepherd 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 Darren!
> 
> -chip
> on behalf of the CloudStack PMC
> 

Re: my outstanding patches on review board

[Daan Hoogland]

H Darren,

I was instructed, when becoming a committer a few weeks ago that low impact
changes are at my discretion. I'd say go ahead. I read some of them and
have no objections. I am not the greatest expert of course but for what its
worth.

regards,
Daan


On Sun, Sep 29, 2013 at 6:02 AM, Darren Shepherd <
darren.s.sheph...@gmail.com> wrote:

> I have a bunch of outstanding patches on review board.  Now that I'm a
> committer I'm going to commit a bunch of then that I consider small
> and non-impacting.  I know this would normally be bad form, so I hope
> you'll excuse me this one time.  I really need to get all those
> committed because they are blocking me from getting all the Spring
> stuff prepared for review.  The longer I wait to get the spring stuff
> in, the more maintenance I have to do as people change stuff (like
> hyper-v, contrail, vxlan).
>
> Darren
>

Re: Libvirt-java 0.5.0 has been released

[Wido den Hollander]

On 09/29/2013 08:01 AM, Wei ZHOU wrote:

try backup and remove the jna.jar in /usr/share/java



I fixed the init scripts, it was still including the old JNA in the 
classpath: 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=e6fd794ca0b10a00f3fc93e5f3e81ab342f5b860


That should fix it!

Wido


2013/9/29, Mike Tutkowski :

Hi Wei,

So, re-installing cloudstack-common allowed cloudstack-agent to install
successfuly. Thanks

I'm still having what appears to be Libvirt-related issues on Ubuntu 12.04
with master.

Any thoughts on this?

log4j:WARN No appenders could be found for logger
(org.apache.commons.httpclient.params.DefaultHttpParams).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
Caused by: java.lang.NoSuchMethodError: com.sun.jna.Native.free(J)V
at org.libvirt.Library.free(Unknown Source)
at org.libvirt.Connect.getCapabilities(Unknown Source)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.IsHVMEnabled(LibvirtComputingResource.java:4533)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:747)
at com.cloud.agent.Agent.(Agent.java:161)
at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:421)
at com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:376)
at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:357)
at com.cloud.agent.AgentShell.start(AgentShell.java:454)
... 5 more
Cannot start daemon
Service exit with a return value of 5


On Fri, Sep 27, 2013 at 1:45 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:


Looks like listNetworks() is called a couple times in
cloudstack-agent-upgrade:

if __name__ == '__main__':
netlib = networkConfig()
bridges = netlib.listNetworks()
bridges = filter(isOldStyleBridge, bridges)
for br in bridges:
enslavedDev = netlib.getEnslavedDev(br, 1)
if enslavedDev is not None:
upgradeBridgeName(br, enslavedDev)

bridges = netlib.listNetworks()
bridges = filter(isOldStyleBridge, bridges)
if len(bridges) > 0:
print("Warning: upgrade is not finished, still some bridges have
the old style name:" + str(bridges))
else:
print("Upgrade succeed")


On Fri, Sep 27, 2013 at 1:43 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:


Kind of made progress here. :) Looks like we have another problem. Is it
possible another item is missing from the scripts?

mtutkowski@ubuntu:~$ sudo apt-get install cloudstack-agent
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
   cloudstack-agent
0 upgraded, 1 newly installed, 0 to remove and 468 not upgraded.
Need to get 39.1 MB of archives.
After this operation, 43.6 MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
   cloudstack-agent
Install these packages without verification [y/N]? y
Get:1 http://localhost/cloudstack/repo/ binary/ cloudstack-agent 4.3.0
[39.1 MB]
Fetched 39.1 MB in 0s (50.5 MB/s)
Selecting previously unselected package cloudstack-agent.
(Reading database ... 168800 files and directories currently installed.)
Unpacking cloudstack-agent (from .../cloudstack-agent_4.3.0_all.deb) ...
Processing triggers for ureadahead ...
Setting up cloudstack-agent (4.3.0) ...
Traceback (most recent call last):
   File "/usr/bin/cloudstack-agent-upgrade", line 51, in 
 bridges = netlib.listNetworks()
AttributeError: networkConfig instance has no attribute 'listNetworks'
dpkg: error processing cloudstack-agent (--configure):
  subprocess installed post-installation script returned error exit
status
1
Errors were encountered while processing:
  cloudstack-agent
E: Sub-process /usr/bin/dpkg returned an error code (1)


On Fri, Sep 27, 2013 at 8:26 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:


Great - thanks, Wei!


On Fri, Sep 27, 2013 at 2:34 AM, Wei ZHOU 
wrote:


Mike,
cloudstack-agent-upgrade is missing in cloudstack-agent installation.
I added it in commit a6bfd9602129d8ae308ba58f36623c04826e15ca

[root@weizhou-centos master(4.2)]# git show
a6bfd9602129d8ae308ba58f36623c04826e15ca
commit a6bfd9602129d8ae308ba58f36623c04826e15ca
Author: Wei Zhou 
Date:   Fri Sep 27 10:31:54 2013 +0200
 add missing cloudstack-agent-upgrade in cloudstack-agent debian
packages
diff --git a/debian/cloudstack-agent.install
b/debian/cloudstack-agent.install
index a3cc869..d708514 100644
--- a/debian/cloudstack-agent.instal

Re: Review Request 14398: NumbersUtil cleanup

[Laszlo Hornyak]

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

(Updated Sept. 29, 2013, 7:24 a.m.)


Review request for cloudstack, daan Hoogland and Hugo Trippaers.


Repository: cloudstack-git


Description
---

- removed methods that were not used
- parseLong, parseInt and parseFloat replaced with the commons-lang NumberUtils 
call
- Test for the remaining methods


Diffs
-

  utils/src/com/cloud/utils/NumbersUtil.java 035239a 
  utils/test/com/cloud/utils/NumbersUtilTest.java f60f58a 

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


Testing
---

tests included


Thanks,

Laszlo Hornyak