Review Request: EC2 REST API: AWS APIs are not getting translated on the CloudStack Management Server and AWS API Installation Problems

[Pradeep Soundararajan]

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

Review request for cloudstack, Chip Childers, Prachi Damle, Likitha Shetty, 
Hugo Trippaers, and Wido den Hollander.


Description
---

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


Diffs
-

  awsapi/src/com/cloud/bridge/util/EncryptionSecretKeyCheckerUtil.java 
0a652212b3eff91fdf950b189681713a7468a0b0 
  packaging/centos63/cloud.spec db37afc475ff95315f4d18a08656a7ce86537487 
  utils/src/com/cloud/utils/crypt/EncryptionSecretKeyChanger.java 
2be274921cce305b1a78513ad405c4ca895fc384 
  utils/src/com/cloud/utils/crypt/EncryptionSecretKeyChecker.java 
5ffa14f30888924a5d26a2e70b23251d474743d5 

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


Testing
---

Tested the build + packaging with this patch.


Thanks,

Pradeep Soundararajan

Re: Review Request: MidoNet Networking Plugin [2/2]

[Hiroaki Kawai]

> On March 14, 2013, 3:59 a.m., Hiroaki Kawai wrote:
> > server/src/com/cloud/network/NetworkManagerImpl.java, line 1773
> > 
> >
> > NetworkElement should be always called after NetworkGuru, isn't it?
> 
> Dave Cahill wrote:
> Looking at NetworkManagerImpl, Element does seem to be called after Guru 
> most of the time - however in destroyNetwork(), the Elements are destroyed 
> before the Guru.
> 
> I'm happy to change the order, but since the order is not always the same 
> in NetworkManagerImpl, do you have any document references / reasons for the 
> suggested order? 
> 
> Since we have tested the current version and it works, I just want to 
> make sure the change makes sense before implementing.
> 
> Hiroaki Kawai wrote:
> I want to see a documentation, too. After reading the code again, I think 
> NetworkElement#release should not be called in the context with 
> NetworkGuru#deallocate . Do you really need this code block here? 
> NetworkElement#release should be called with NetworkGuru#release, and you 
> would be able to do something there.
> 
> 
> Network lifecycle:
> --
> 
> NetworkManagerImpl#implementNetwork
> - NetworkGuru#implement
> - NetworkManagerImpl#implementNetworkElementsAndResources
> -- NetworkElement#implement
> 
> NetworkManagerImpl#restartNetwork
> - NetworkManagerImpl#shutdownNetworkElementsAndResources
> -- NetworkElement#shutdown
> - NetworkManagerImpl#implemetNetworkElementsAndResources
> -- NetworkElement#implement
> 
> NetworkManagerImpl#updateGuestNetwork
> - NetworkManagerImpl#shutdownNetworkElementsAndResource
> -- NetworkElement#shutdown
> - NetworkManagerImpl#implemetNetworkElementsAndResources
> -- NetworkElement#implement
> 
> NetworkManagerImpl#shutdownNetwork
> - NetworkManagerImpl#shutdownNetworkElementsAndResource
> -- NetworkElement#shutdown
> - NetworkGuru#shutdown
> 
> 
> Nic lifecycle:
> --
> NetworkManagerImpl#allocate
> - NetworkManagerImpl#allocateNic
> -- NetworkGuru#allocate
> 
> NetworkManager#prepareNic
> - NetworkGuru#reserve
> - NetworkManager#prepareElement
> -- NetworkElement#prepare
> 
> NetworkManagerImpl#release
> - NetworkManagerImpl#releaseNic
> -- NetworkGuru#release
> -- NetworkElement#release
> 
> NetworkManagerImpl#deallocate
> - NetworkManagerImpl#removeNic
> -- NetworkGuru#deallocate
> 
>
> 
> joe mills wrote:
> NetworkElement#release is being called with NetworkGuru#release, but only 
> for NICs that have the "start" reservation strategy [1].
> 
> The "start" reservation strategy means that the IP address should be 
> assigned on start and released on stop [2].
> 
> However, the NICs on the public network are assigned a reservation 
> strategy of 'Create' which means that they should not be released between 
> starts and stops. There are no other calls to element.release, so the public 
> NIC never gets released.
> 
> This is generally not a problem because with the VirtualRouterElement 
> there are no resources hanging around that NetworkGuru#dealloc and destroying 
> the entire VM won't take care of.
> 
> But with our plugin, we want to handle the Public network and we do 
> allocate resources that will not go away by simply destroying the VM and 
> calling NetworkGuru#dealloc. Therefore we need the corresponding 
> NetworkElement#release call to happen, and this is the code path that gets 
> executed when we destroy the NIC.
> 
> Given that background, do you think any changes are needed?
> 
> [1] 
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=591910b13c63e88d3d831cd584e4e92e0db14eca;hb=HEAD#l1711
> 
> [2] 
> http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201205.mbox/%3cb1df26ecc0458748ac97cece2da98d41011d278da...@sjcpmailbox01.citrite.net%3E

The code seems to mean, NetworkElement/NetworkGuru#release for releasing what 
was reserved. Information about if there was a reserved network resource or 
not, is stored in Nic state (Nic.State.Reserved or Nic.State.Reserving). So the 
flow that NetworkElement#release is not called in NetworkManagerImpl#releaseNic 
is just a BUG, and I think we can put the NetworkElement#release out of the 
scope of Start RervationStrategy.


- Hiroaki


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


On March 25, 2013, 4:02 a.m., Dave Cahill wrote:
> 
> ---
> This is an automatically generated e-

Re: Review Request: (CLOUDSTACK-1325) add password in response of RestoreVM

[Harikrishna Patnala]

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



server/src/com/cloud/vm/UserVmManagerImpl.java


Can you put some log message here, since restore is already completed till 
this point and only password reset is left that user can do by resetting the 
password afterwards if it fails here.


- Harikrishna Patnala


On March 22, 2013, 4:42 a.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9539/
> ---
> 
> (Updated March 22, 2013, 4:42 a.m.)
> 
> 
> Review request for cloudstack, Sateesh Chodapuneedi and Harikrishna Patnala.
> 
> 
> Description
> ---
> 
> In 4.0.1, There is no password field in the respone of RestoreVM.
> Please see https://issues.apache.org/jira/browse/CLOUDSTACK-1325
> 
> This patch add a new password in the response.
> 
> 
> This addresses bug CLOUDSTACK-1325.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/vm/UserVmService.java 6635657 
>   server/src/com/cloud/vm/UserVmManagerImpl.java dbcbeb8 
> 
> Diff: https://reviews.apache.org/r/9539/diff/
> 
> 
> Testing
> ---
> 
> Testing manually ok.
> 
> command=restoreVirtualMachine&response=json&virtualmachineid=1a53a308-c870-452a-9eff-23975919286b
>  public $jobid =>
>  string(36) "7e855ed2-b5ab-4449-a163-5c1af62019ab"
> 
> command=queryAsyncJobResult&response=json&jobid=7e855ed2-b5ab-4449-a163-5c1af62019ab
>  public $password =>
>  string(9) "mD5qkzmdk"
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Re: Review Request: BugFix CLOUDSTACK-1803: Slashes removed from local storage path

[Rohit Yadav]

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


+1 Looks good, should fix the issue. Waiting for Edison to take a final look at 
it and give a ship it.
Will assign the issue to Edison on JIRA.

- Rohit Yadav


On March 25, 2013, 8:41 p.m., Brian Spindler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10124/
> ---
> 
> (Updated March 25, 2013, 8:41 p.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Description
> ---
> 
> Fix for deleting all slashes from the storage path instead of just the first 
> slash.
> 
> 
> This addresses bug CLOUDSTACK-1803.
> 
> 
> Diffs
> -
> 
>   
> plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
>  2991574 
> 
> Diff: https://reviews.apache.org/r/10124/diff/
> 
> 
> Testing
> ---
> 
> Ubuntu 12.04, turned local storage on, added a physical host.
> 
> 
> Thanks,
> 
> Brian Spindler
> 
>

Install CS 4.0.1 On ESXI 5.0

[mahzad]

Hi  I have installed CS 4.0.1  in CentOSBy using  your doc:

Section of 4.4.2. RPM package repository  and
http://cloudstack.apt-get.eu/rhel/4.0/

 

My hypervisor is ESXI. Before setting NFS storage and  After installation
rpms and testing  tomcat and httpd services ,I test UI , But client is not
displayed :

HTTP Status 404 - /client

  _  

type Status report

message /client

description The requested resource (/client) is not available.

 

What is Problem ?is it about VMWare support issues?!!!

 

Re: New committer: Hiroaki Kawai

[Noah Slater]

Congrats!


On 25 March 2013 13:39, David Nalley  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked
> Hiroaki Kawai to become a committer and we are pleased to announce
> that they have 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 Kawai-san
>
> --David
> on behalf of the CloudStack PMC
>



-- 
NS

Re: New committer: Geoff Higginbottom

[Noah Slater]

Grats!


On 25 March 2013 15:25, Chip Childers  wrote:

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



-- 
NS

Re: Review Request: MidoNet Networking Plugin [2/2]

[joe mills]

> On March 14, 2013, 3:59 a.m., Hiroaki Kawai wrote:
> > server/src/com/cloud/network/NetworkManagerImpl.java, line 1773
> > 
> >
> > NetworkElement should be always called after NetworkGuru, isn't it?
> 
> Dave Cahill wrote:
> Looking at NetworkManagerImpl, Element does seem to be called after Guru 
> most of the time - however in destroyNetwork(), the Elements are destroyed 
> before the Guru.
> 
> I'm happy to change the order, but since the order is not always the same 
> in NetworkManagerImpl, do you have any document references / reasons for the 
> suggested order? 
> 
> Since we have tested the current version and it works, I just want to 
> make sure the change makes sense before implementing.
> 
> Hiroaki Kawai wrote:
> I want to see a documentation, too. After reading the code again, I think 
> NetworkElement#release should not be called in the context with 
> NetworkGuru#deallocate . Do you really need this code block here? 
> NetworkElement#release should be called with NetworkGuru#release, and you 
> would be able to do something there.
> 
> 
> Network lifecycle:
> --
> 
> NetworkManagerImpl#implementNetwork
> - NetworkGuru#implement
> - NetworkManagerImpl#implementNetworkElementsAndResources
> -- NetworkElement#implement
> 
> NetworkManagerImpl#restartNetwork
> - NetworkManagerImpl#shutdownNetworkElementsAndResources
> -- NetworkElement#shutdown
> - NetworkManagerImpl#implemetNetworkElementsAndResources
> -- NetworkElement#implement
> 
> NetworkManagerImpl#updateGuestNetwork
> - NetworkManagerImpl#shutdownNetworkElementsAndResource
> -- NetworkElement#shutdown
> - NetworkManagerImpl#implemetNetworkElementsAndResources
> -- NetworkElement#implement
> 
> NetworkManagerImpl#shutdownNetwork
> - NetworkManagerImpl#shutdownNetworkElementsAndResource
> -- NetworkElement#shutdown
> - NetworkGuru#shutdown
> 
> 
> Nic lifecycle:
> --
> NetworkManagerImpl#allocate
> - NetworkManagerImpl#allocateNic
> -- NetworkGuru#allocate
> 
> NetworkManager#prepareNic
> - NetworkGuru#reserve
> - NetworkManager#prepareElement
> -- NetworkElement#prepare
> 
> NetworkManagerImpl#release
> - NetworkManagerImpl#releaseNic
> -- NetworkGuru#release
> -- NetworkElement#release
> 
> NetworkManagerImpl#deallocate
> - NetworkManagerImpl#removeNic
> -- NetworkGuru#deallocate
> 
>
> 
> joe mills wrote:
> NetworkElement#release is being called with NetworkGuru#release, but only 
> for NICs that have the "start" reservation strategy [1].
> 
> The "start" reservation strategy means that the IP address should be 
> assigned on start and released on stop [2].
> 
> However, the NICs on the public network are assigned a reservation 
> strategy of 'Create' which means that they should not be released between 
> starts and stops. There are no other calls to element.release, so the public 
> NIC never gets released.
> 
> This is generally not a problem because with the VirtualRouterElement 
> there are no resources hanging around that NetworkGuru#dealloc and destroying 
> the entire VM won't take care of.
> 
> But with our plugin, we want to handle the Public network and we do 
> allocate resources that will not go away by simply destroying the VM and 
> calling NetworkGuru#dealloc. Therefore we need the corresponding 
> NetworkElement#release call to happen, and this is the code path that gets 
> executed when we destroy the NIC.
> 
> Given that background, do you think any changes are needed?
> 
> [1] 
> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=591910b13c63e88d3d831cd584e4e92e0db14eca;hb=HEAD#l1711
> 
> [2] 
> http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201205.mbox/%3cb1df26ecc0458748ac97cece2da98d41011d278da...@sjcpmailbox01.citrite.net%3E
> 
> Hiroaki Kawai wrote:
> The code seems to mean, NetworkElement/NetworkGuru#release for releasing 
> what was reserved. Information about if there was a reserved network resource 
> or not, is stored in Nic state (Nic.State.Reserved or Nic.State.Reserving). 
> So the flow that NetworkElement#release is not called in 
> NetworkManagerImpl#releaseNic is just a BUG, and I think we can put the 
> NetworkElement#release out of the scope of Start RervationStrategy.

We also thought that the NetworkElement#release call placement was a bug, but 
after trying out a few things, we found that it needs to stay inside that 
'Start' reservation strategy check. This is because when we "stop" Nics with a 
'Create' reservation strategy, we should not call NetworkElement#release. This 
is why the NetworkElement#release call n

Review Request: Add docs for MidoNet networking plugin [CLOUDSTACK-996]

[Dave Cahill]

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

Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.


Description
---

Adding docs for MidoNet networking plugin [CLOUDSTACK-996]

Plugin itself is awaiting review / commit here:
[PATCH 1] https://reviews.apache.org/r/9897/
[PATCH 2] https://reviews.apache.org/r/9898/


This addresses bug CLOUDSTACK-996.


Diffs
-

  docs/en-US/MidoNet_Plugin_Guide.ent PRE-CREATION 
  docs/en-US/MidoNet_Plugin_Guide.xml PRE-CREATION 
  docs/en-US/plugin-midonet-about.xml PRE-CREATION 
  docs/en-US/plugin-midonet-features.xml PRE-CREATION 
  docs/en-US/plugin-midonet-introduction.xml PRE-CREATION 
  docs/en-US/plugin-midonet-preparations.xml PRE-CREATION 
  docs/en-US/plugin-midonet-provider.xml PRE-CREATION 
  docs/en-US/plugin-midonet-revisions.xml PRE-CREATION 
  docs/en-US/plugin-midonet-ui.xml PRE-CREATION 
  docs/en-US/plugin-midonet-usage.xml PRE-CREATION 
  docs/publican-plugin-midonet.cfg PRE-CREATION 

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


Testing
---

Built docs.


Thanks,

Dave Cahill

Re: Review Request: MidoNet Networking Plugin [2/2]

[Hiroaki Kawai]

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



server/src/com/cloud/network/NetworkManagerImpl.java


We must not catch bare Exception because it also catches RuntimeException.


- Hiroaki Kawai


On March 25, 2013, 4:02 a.m., Dave Cahill wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9898/
> ---
> 
> (Updated March 25, 2013, 4:02 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> Feature spec:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Midokura+Networking+Plugin
> 
> Jira ticket:
> https://issues.apache.org/jira/browse/CLOUDSTACK-996
> 
> Notes:
> 
> * Documentation will follow as a separate commit
> 
> * One main difference from existing networking plugins is the lack of a 
> Resource class; we didn't feel it was necessary in this case. As mentioned in 
> Extending CloudStack Networking [1]:
> "Just like managers, resources are not strictly necessary. In theory a 
> Network Element could implement a client for the API of the new controller 
> and therefore be completely self-contained."
> 
> * We allow overriding Public traffic via the MidoNetPublicNetworkGuru. We 
> checked this approach with the list [2] and received no comments, so we're 
> going with it for now.
> 
> [1] https://cwiki.apache.org/CLOUDSTACK/extending-cloudstack-networking.html
> [2] http://markmail.org/message/k5qse63eyylszm3i
> 
> 
> This addresses bug CLOUDSTACK-996.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/Network.java c2ab655 
>   api/src/com/cloud/network/Networks.java e3d2158 
>   api/src/com/cloud/network/PhysicalNetwork.java 343a2b1 
>   api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java 
> bc22804 
>   client/pom.xml 7ad2eff 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtDomainXMLParser.java
>  b622b6d 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
>  c93aeeb 
>   plugins/network-elements/midokura-midonet/pom.xml 7f2e2d3 
>   plugins/network-elements/midonet/pom.xml PRE-CREATION 
>   
> plugins/network-elements/midonet/src/com/cloud/network/element/MidoNetElement.java
>  48833b3 
>   
> plugins/network-elements/midonet/src/com/cloud/network/element/SimpleFirewallRule.java
>  PRE-CREATION 
>   
> plugins/network-elements/midonet/src/com/cloud/network/guru/MidoNetGuestNetworkGuru.java
>  ed0eb3c 
>   
> plugins/network-elements/midonet/src/com/cloud/network/guru/MidoNetPublicNetworkGuru.java
>  PRE-CREATION 
>   
> plugins/network-elements/midonet/src/com/cloud/network/resource/MidoNetVifDriver.java
>  PRE-CREATION 
>   
> plugins/network-elements/midonet/test/com/cloud/network/element/MidoNetElementTest.java
>  PRE-CREATION 
>   plugins/pom.xml 39d9907 
>   server/src/com/cloud/configuration/Config.java 9db7dbd 
>   server/src/com/cloud/network/NetworkManagerImpl.java b1236cc 
>   ui/scripts/system.js c0a5d14 
> 
> Diff: https://reviews.apache.org/r/9898/diff/
> 
> 
> Testing
> ---
> 
> Built and deployed, spun up Advanced Isolated network with two VMs, verified 
> internal and external connectivity via MidoNet.
> 
> 
> Thanks,
> 
> Dave Cahill
> 
>

Re: [DISCUSS] create a general@ mailing list?

[Noah Slater]

This proposal troubles me.

The dev list is supposed to be the single place you can monitor as a
contributor, and be assured that all development activity is happening
there. We should absolutely be minimising the other places people need to
check.

And also, I do not want to have to rely on other people to be doing my
filtering for me. I don't want to have to trust that if a dev-storage
discussion becomes relevant for the general dev list, that it will be moved
there.

Obviously, the idea of general@ has precedent, but at least the concept
seems distinct enough. It's going to be very infrequent that a PMC-level
discussion ends up in a patch review, or vice versa.

If we start splitting out the dev@ list into subjects, we risk fracturing
the community. That's not to say it hasn't been done before. Hadoop do it.
But perhaps there is some reason it works for them.

TL;DR: We need to consider the community impact carefully. :)


On 25 March 2013 23:14, Alex Huang  wrote:

> Then agree to discuss it on dev list.  Doesn't seem very hard to do to me.
>  There's going to be people like you and me who'll be monitoring and
> reminding people that the feature is cross components.
>
> --Alex
>
> > -Original Message-
> > From: Joe Brockmeier [mailto:j...@zonker.net]
> > Sent: Monday, March 25, 2013 3:54 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] create a general@ mailing list?
> >
> > On Mon, Mar 25, 2013, at 05:45 PM, Alex Huang wrote:
> > > To me the dev list is already a general list.  I rather see more topic
> > > oriented lists like: dev-network, dev-storage, dev-hypervisor.
> >
> > What happens if a topic crosses over between storage, networking and
> > hypervisors (or some subset)? I think it would be *very* hard to make
> that
> > workable.
> >
> > Best,
> >
> > jzb
> > --
> > Joe Brockmeier
> > j...@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
>



-- 
NS

Re: [DISCUSS] create a general@ mailing list?

[Noah Slater]

P.S. Chip, I would consider asking on general@hadoop.a.o about this...


On 21 March 2013 03:42, Chip Childers  wrote:

> I've noticed that some of the projects separate discussions between dev
> and general administrative items via a general@ and a dev@ list.  For
> example, the last email I sent was about project meta-data.  It's not
> specifically about developing cloudstack, but about managing our
> community activities.
>
> Does anyone think it makes sense to break that type of discussion out
> into a general@ list?
>



-- 
NS

RE: [DISCUSS] create a general@ mailing list?

[Giles Sirett]

Noah

Isn't that what users@ is for ? - or is that really intended for true, well, 
users (Cloudstack doesn't really have users in the traditional sense)


Kind Regards
Giles

D: +44 20 3603 0541 | M: +44 796 111 2055
giles.sir...@shapeblue.com




-Original Message-
From: Noah Slater [mailto:nsla...@apache.org]
Sent: 26 March 2013 09:51
To: cloudstack
Subject: Re: [DISCUSS] create a general@ mailing list?

P.S. Chip, I would consider asking on general@hadoop.a.o about this...


On 21 March 2013 03:42, Chip Childers  wrote:

> I've noticed that some of the projects separate discussions between
> dev and general administrative items via a general@ and a dev@ list.
> For example, the last email I sent was about project meta-data.  It's
> not specifically about developing cloudstack, but about managing our
> community activities.
>
> Does anyone think it makes sense to break that type of discussion out
> into a general@ list?
>



--
NS
This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is operated under 
license from Shape Blue Ltd. ShapeBlue is a registered trademark.

RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Donal Lafferty]

> -Original Message-
> From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf
> Of Rohit Yadav
> Sent: 26 March 2013 4:02 AM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance
> 
> On Tue, Mar 26, 2013 at 4:31 AM, Donal Lafferty 
> wrote:
> > It makes a lot of sense to write the ServerResourse for Hyper-V in C#,
> because there's a lot of frameworks written in the Microsoft ecosystem with
> C# in mind.
> >
> > If that's the case, then it also makes sense to use the Microsoft compiler 
> > to
> compile the ServerResource.
> 
> This won't get much love, instead of a compiler from the North Atlantic giant,
[Donal Lafferty] 
Northwest Pacific :)
> if you were to use C# anyway why not consider using mono for your
> compiler/build infrastructure? While I would avoid mono and it would be
> difficult for folks to build/develop, if something could be done in C#, could 
> n't
> it be done in Java, Scala or anything that could run on JVM? If this is 
> possible,
> it will save us from nonoss, proprietary build/runtime dependency.
[Donal Lafferty] 
It's a question of what environment is optimal for the ServerResource.  There 
is a lot more material for writing a server resource in C# than there is for 
writing it in Java.

Moreover, the ServerResource concept of a plugin was introduced to allow 
developers a degree of freedom in choosing the environment for code that 
controls data centre resource.  Adopting platform-specific tools seems to flow 
naturally from this definition.  I guess you could call this the multi-lingual 
plugin:  one where the ServerResource and ServerComponent are not homogenous.

What are the barriers to including 'multi-lingual plugins' in CloudStack?

> 
> Cheers.
> 
> >
> > I'm unclear how this impacts contributing the code to Apache CloudStack.
> In particular:
> >
> >
> > 1.   Does dependence on the Microsoft compiler mean that the source
> end up in the non-OSS build?
> >
> > 2.   Is the plugin able to participate in the BVT?
> >
> >

Re: [DISCUSS] create a general@ mailing list?

[Noah Slater]

The users@ list is for users[1]:

"A user is someone that uses our software. They contribute to the Apache
projects by providing feedback to developers in the form of bug reports and
feature suggestions. Users participate in the Apache community by helping
other users on mailing lists and user support forums."

The dev@ list is for committers[2]:

"A committer is a developer that was given write access to the code
repository[...] Not needing to depend on other people for the patches, they
are actually making short-term decisions for the project."

[1] http://www.apache.org/foundation/how-it-works.html#users

[2] http://www.apache.org/foundation/how-it-works.html#committers




On 26 March 2013 09:58, Giles Sirett  wrote:

> Noah
>
> Isn't that what users@ is for ? - or is that really intended for true,
> well, users (Cloudstack doesn't really have users in the traditional sense)
>
>
> Kind Regards
> Giles
>
> D: +44 20 3603 0541 | M: +44 796 111 2055
> giles.sir...@shapeblue.com
>
>
>
>
> -Original Message-
> From: Noah Slater [mailto:nsla...@apache.org]
> Sent: 26 March 2013 09:51
> To: cloudstack
> Subject: Re: [DISCUSS] create a general@ mailing list?
>
> P.S. Chip, I would consider asking on general@hadoop.a.o about this...
>
>
> On 21 March 2013 03:42, Chip Childers  wrote:
>
> > I've noticed that some of the projects separate discussions between
> > dev and general administrative items via a general@ and a dev@ list.
> > For example, the last email I sent was about project meta-data.  It's
> > not specifically about developing cloudstack, but about managing our
> > community activities.
> >
> > Does anyone think it makes sense to break that type of discussion out
> > into a general@ list?
> >
>
>
>
> --
> NS
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is
> operated under license from Shape Blue Ltd. ShapeBlue is a registered
> trademark.
>
>


-- 
NS

Re: [DISCUSS] create a general@ mailing list?

[Rohit Yadav]

Too many lists, avoid maybe?

On Tue, Mar 26, 2013 at 3:43 PM, Noah Slater  wrote:
> The users@ list is for users[1]:
>
> "A user is someone that uses our software. They contribute to the Apache
> projects by providing feedback to developers in the form of bug reports and
> feature suggestions. Users participate in the Apache community by helping
> other users on mailing lists and user support forums."
>
> The dev@ list is for committers[2]:
>
> "A committer is a developer that was given write access to the code
> repository[...] Not needing to depend on other people for the patches, they
> are actually making short-term decisions for the project."
>
> [1] http://www.apache.org/foundation/how-it-works.html#users
>
> [2] http://www.apache.org/foundation/how-it-works.html#committers
>
>
>
>
> On 26 March 2013 09:58, Giles Sirett  wrote:
>
>> Noah
>>
>> Isn't that what users@ is for ? - or is that really intended for true,
>> well, users (Cloudstack doesn't really have users in the traditional sense)
>>
>>
>> Kind Regards
>> Giles
>>
>> D: +44 20 3603 0541 | M: +44 796 111 2055
>> giles.sir...@shapeblue.com
>>
>>
>>
>>
>> -Original Message-
>> From: Noah Slater [mailto:nsla...@apache.org]
>> Sent: 26 March 2013 09:51
>> To: cloudstack
>> Subject: Re: [DISCUSS] create a general@ mailing list?
>>
>> P.S. Chip, I would consider asking on general@hadoop.a.o about this...
>>
>>
>> On 21 March 2013 03:42, Chip Childers  wrote:
>>
>> > I've noticed that some of the projects separate discussions between
>> > dev and general administrative items via a general@ and a dev@ list.
>> > For example, the last email I sent was about project meta-data.  It's
>> > not specifically about developing cloudstack, but about managing our
>> > community activities.
>> >
>> > Does anyone think it makes sense to break that type of discussion out
>> > into a general@ list?
>> >
>>
>>
>>
>> --
>> NS
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. Shape Blue Ltd is a
>> company incorporated in England & Wales. ShapeBlue Services India LLP is
>> operated under license from Shape Blue Ltd. ShapeBlue is a registered
>> trademark.
>>
>>
>
>
> --
> NS

RE: [ACS41] Bugs blocking our 4.1 release

[Pradeep Soundararajan]

Resolved ---  CLOUDSTACK-1719 EC2 REST API: AWS APIs are not getting translated 
on the CloudStack Management Server   Pradeep Soundararajan
Unable to reproduce with the steps I have mentioned in the defect.  Hence, 
dropping from Blocker ---  CLOUDSTACK-1694 Issues to start/access Management 
Server after upgrade from 4.0 to 4.1  Pradeep Soundararajan
Closed by Sangeetha as this is being tracked as part of CLOUDSTACK-1694 --- 
CLOUDSTACK-1802 Upgrade 4.0 -> 4.1 - Not able to strat management server 
becasue of missing /etc/cloudstack/management/tomcat6.conf file.   Pradeep 
Soundararajan

Thanks,
Pradeep S


-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, March 26, 2013 1:45 AM
To: dev@cloudstack.apache.org
Subject: [ACS41] Bugs blocking our 4.1 release

Hi all,

The following bugs need to be either (1) resolved or (2) triaged as not being 
as high a priority as they are now before I cut the RC.  Can folks take a 
moment to review and update / fix accordingly please?

CLOUDSTACK-1694 Issues to start/access Management Server after upgrade from 4.0 
to 4.1  Pradeep Soundararajan
CLOUDSTACK-1719 EC2 REST API: AWS APIs are not getting translated on the 
CloudStack Management Server   Pradeep Soundararajan
CLOUDSTACK-1772 the change in vnc listening port will cause live migration 
doesn't work edison su
CLOUDSTACK-1795 Customize AOP to fully support legacy CloudStack @DB and 
@ActionEvent semantics Kelven Yang
CLOUDSTACK-1664 Action Events are not logged due to spring changes  Kelven Yang
CLOUDSTACK-1673 AWS Regions - Events - User disable event does not include the 
UUID of the user that was disabled.  Murali Reddy
CLOUDSTACK-1740 Failed to view console  Rajesh Battala
CLOUDSTACK-1755 IPv6 - When Vm is part of Dual network , /etc/reslov.conf does 
not have ipv6 router ipaddress and ipv6 external dns.Sheng Yang
CLOUDSTACK-1789 Unable to download templates to Primary Storage if a host is in 
maintenance edison su
CLOUDSTACK-1802 Upgrade 4.0 -> 4.1 - Not able to strat management server 
becasue of missing /etc/cloudstack/management/tomcat6.conf file.   Pradeep 
Soundararajan


I'd also like us to resolve 
https://issues.apache.org/jira/browse/CLOUDSTACK-1796 - which is a Japanese 
docs building issue.  Sebastien, can you please review the latest from 
Transifex (per latest comment from Hiroaki)?

-chip

[ACS41] [PATCH REQUEST] - CLOUDSTACK 1008

[Pranav Saxena]

Hi Chip,

Could you please apply the patch attached to this JIRA ticket - 
https://issues.apache.org/jira/browse/CLOUDSTACK-1008  ? It seems it's specific 
to 4.1 and hence I haven't committed it to master.

Thanks,
Pranav
From e1a9062e1c5d27e5b7a63d4f00c783112a1d3558 Mon Sep 17 00:00:00 2001
From: Pranav Saxena 
Date: Tue, 26 Mar 2013 16:02:19 +0530
Subject: [PATCH] CLOUDSTACK-1008:Egress tab should not be presented in the UI
 for Shared Networks


Signed-off-by: Pranav Saxena 
---
 ui/scripts/network.js |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/ui/scripts/network.js b/ui/scripts/network.js
index 84cc067..9bd0857 100755
--- a/ui/scripts/network.js
+++ b/ui/scripts/network.js
@@ -807,6 +807,7 @@
   var hasSRXFirewall = false;
   var isVPC = false;
   var isAdvancedSGZone = false;
+  var type;
   var hiddenTabs = [];
 
   // Get network offering data
@@ -862,12 +863,24 @@
   isAdvancedSGZone = zone.securitygroupsenabled;
 }
   });
+ 
+   $.ajax({
+ url:createURL('listNetworks'),
+ data:{ id:args.context.networks[0].id },
+ async:false,
+ success:function(json){
+   type = json.listnetworksresponse.network[0].type;
+
+ }
+
+ });
+
 
   if (!networkOfferingHavingELB) {
 hiddenTabs.push("addloadBalancer");
   }
 
-  if (isVPC || isAdvancedSGZone || hasSRXFirewall) {
+  if (isVPC || isAdvancedSGZone || hasSRXFirewall || type="Shared") {
 hiddenTabs.push('egressRules');
}
   
-- 
1.7.5.4

CLOUDSTACK-528

[nicolas.lamirault]

hi
our upgrade from 2.2.14 to 4.0.x is blocked because of this issue :
https://issues.apache.org/jira/browse/CLOUDSTACK-528
does anyone have news about this problem ?
Regards.

--
Nicolas Lamirault

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete 
altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages 
that have been modified, changed or falsified.
Thank you.

RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Koushik Das]

Better to write the C# component doing Hyper-V specific stuff as a standalone 
component and expose a REST API. The ServerResource class is still in java and 
makes REST calls to the C# component.

-Koushik

> -Original Message-
> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> Sent: Tuesday, March 26, 2013 3:29 PM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance
> 
> 
> > -Original Message-
> > From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On
> Behalf
> > Of Rohit Yadav
> > Sent: 26 March 2013 4:02 AM
> > To: dev@cloudstack.apache.org
> > Cc: cloudstack-...@incubator.apache.org
> > Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > Clearance
> >
> > On Tue, Mar 26, 2013 at 4:31 AM, Donal Lafferty
> > 
> > wrote:
> > > It makes a lot of sense to write the ServerResourse for Hyper-V in
> > > C#,
> > because there's a lot of frameworks written in the Microsoft ecosystem
> > with C# in mind.
> > >
> > > If that's the case, then it also makes sense to use the Microsoft
> > > compiler to
> > compile the ServerResource.
> >
> > This won't get much love, instead of a compiler from the North
> > Atlantic giant,
> [Donal Lafferty]
> Northwest Pacific :)
> > if you were to use C# anyway why not consider using mono for your
> > compiler/build infrastructure? While I would avoid mono and it would
> > be difficult for folks to build/develop, if something could be done in
> > C#, could n't it be done in Java, Scala or anything that could run on
> > JVM? If this is possible, it will save us from nonoss, proprietary
> build/runtime dependency.
> [Donal Lafferty]
> It's a question of what environment is optimal for the ServerResource.  There
> is a lot more material for writing a server resource in C# than there is for
> writing it in Java.
> 
> Moreover, the ServerResource concept of a plugin was introduced to allow
> developers a degree of freedom in choosing the environment for code that
> controls data centre resource.  Adopting platform-specific tools seems to
> flow naturally from this definition.  I guess you could call this the 
> multi-lingual
> plugin:  one where the ServerResource and ServerComponent are not
> homogenous.
> 
> What are the barriers to including 'multi-lingual plugins' in CloudStack?
> 
> >
> > Cheers.
> >
> > >
> > > I'm unclear how this impacts contributing the code to Apache CloudStack.
> > In particular:
> > >
> > >
> > > 1.   Does dependence on the Microsoft compiler mean that the source
> > end up in the non-OSS build?
> > >
> > > 2.   Is the plugin able to participate in the BVT?
> > >
> > >

RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Donal Lafferty]

The terminology for plugins has unfortunate overloading when it comes to the 
term 'ServerResource'.  As a Java class, it seems to be used to in the 
implementation both a plugin's ServerComponent and a plugin's ServerResource.  
E.g. the KVM plugin has a 'dummy' ServerResource in the management server, and 
a real ServerResource in the remote agent.

With that in mind, do you mean for the C# component to be accessible over a 
RESTful API from plugin classes loaded into the management server?

DL

> -Original Message-
> From: Koushik Das [mailto:koushik@citrix.com]
> Sent: 26 March 2013 12:52 PM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance
> 
> Better to write the C# component doing Hyper-V specific stuff as a
> standalone component and expose a REST API. The ServerResource class is
> still in java and makes REST calls to the C# component.
> 
> -Koushik
> 
> > -Original Message-
> > From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> > Sent: Tuesday, March 26, 2013 3:29 PM
> > To: dev@cloudstack.apache.org
> > Cc: cloudstack-...@incubator.apache.org
> > Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > Clearance
> >
> >
> > > -Original Message-
> > > From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On
> > Behalf
> > > Of Rohit Yadav
> > > Sent: 26 March 2013 4:02 AM
> > > To: dev@cloudstack.apache.org
> > > Cc: cloudstack-...@incubator.apache.org
> > > Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > > Clearance
> > >
> > > On Tue, Mar 26, 2013 at 4:31 AM, Donal Lafferty
> > > 
> > > wrote:
> > > > It makes a lot of sense to write the ServerResourse for Hyper-V in
> > > > C#,
> > > because there's a lot of frameworks written in the Microsoft
> > > ecosystem with C# in mind.
> > > >
> > > > If that's the case, then it also makes sense to use the Microsoft
> > > > compiler to
> > > compile the ServerResource.
> > >
> > > This won't get much love, instead of a compiler from the North
> > > Atlantic giant,
> > [Donal Lafferty]
> > Northwest Pacific :)
> > > if you were to use C# anyway why not consider using mono for your
> > > compiler/build infrastructure? While I would avoid mono and it would
> > > be difficult for folks to build/develop, if something could be done
> > > in C#, could n't it be done in Java, Scala or anything that could
> > > run on JVM? If this is possible, it will save us from nonoss,
> > > proprietary
> > build/runtime dependency.
> > [Donal Lafferty]
> > It's a question of what environment is optimal for the ServerResource.
> > There is a lot more material for writing a server resource in C# than
> > there is for writing it in Java.
> >
> > Moreover, the ServerResource concept of a plugin was introduced to
> > allow developers a degree of freedom in choosing the environment for
> > code that controls data centre resource.  Adopting platform-specific
> > tools seems to flow naturally from this definition.  I guess you could
> > call this the multi-lingual
> > plugin:  one where the ServerResource and ServerComponent are not
> > homogenous.
> >
> > What are the barriers to including 'multi-lingual plugins' in CloudStack?
> >
> > >
> > > Cheers.
> > >
> > > >
> > > > I'm unclear how this impacts contributing the code to Apache
> CloudStack.
> > > In particular:
> > > >
> > > >
> > > > 1.   Does dependence on the Microsoft compiler mean that the
> source
> > > end up in the non-OSS build?
> > > >
> > > > 2.   Is the plugin able to participate in the BVT?
> > > >
> > > >

Re: Review Request: BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

[ASF Subversion and Git Services]

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


Commit e46601463ca6000408e680003aae6f22951c0029 in branch refs/heads/4.1 from 
Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e466014 ]

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


- ASF Subversion and Git Services


On March 22, 2013, 6:26 a.m., Pradeep Soundararajan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10047/
> ---
> 
> (Updated March 22, 2013, 6:26 a.m.)
> 
> 
> Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den 
> Hollander, and Noa Resare.
> 
> 
> Description
> ---
> 
> BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719
> 
> Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
> Management Server and AWS API Installation Problems.
> This fixes the above two defects and other packaging related issues.
> 
> Signed-off-by: Pradeep 
> 
> 
> Diffs
> -
> 
>   awsapi-setup/setup/cloud-setup-bridge d25072d 
>   packaging/centos63/cloud.spec 16c3602 
>   python/lib/cloudutils/serviceConfigServer.py a08ce02 
> 
> Diff: https://reviews.apache.org/r/10047/diff/
> 
> 
> Testing
> ---
> 
> Packaging went through with the fixes.
> 
> 
> Thanks,
> 
> Pradeep Soundararajan
> 
>

Re: Review Request: BUG-ID: CLOUDSTACK-1713: EC2 REST API: AWS API Installation Problems

[ASF Subversion and Git Services]

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


Commit e46601463ca6000408e680003aae6f22951c0029 in branch refs/heads/4.1 from 
Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e466014 ]

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


- ASF Subversion and Git Services


On March 19, 2013, 10:36 a.m., Pradeep Soundararajan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10007/
> ---
> 
> (Updated March 19, 2013, 10:36 a.m.)
> 
> 
> Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den 
> Hollander, and Noa Resare.
> 
> 
> Description
> ---
> 
> BUG-ID: CLOUDSTACK-1713
> 
> Summary: EC2 REST API: AWS API Installation Problems
> 
> Description: Added the pre run for awsapi where it will create the user 
> 'cloud' during awsapi install and removed the unwanted entries from packaging 
> awsapi.
> 
> Signed-off-by: Pradeep 
> 
> 
> Diffs
> -
> 
>   packaging/centos63/cloud.spec 1b2c9a9633e161081809c3aa25574fdb863d4d0b 
> 
> Diff: https://reviews.apache.org/r/10007/diff/
> 
> 
> Testing
> ---
> 
> Tested with the latest build + packaging.
> 
> 
> Thanks,
> 
> Pradeep Soundararajan
> 
>

Re: Review Request: BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

[ASF Subversion and Git Services]

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


Commit e46601463ca6000408e680003aae6f22951c0029 in branch refs/heads/4.1 from 
Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e466014 ]

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


- ASF Subversion and Git Services


On March 20, 2013, 6:37 p.m., Pradeep Soundararajan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10046/
> ---
> 
> (Updated March 20, 2013, 6:37 p.m.)
> 
> 
> Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den 
> Hollander, and Noa Resare.
> 
> 
> Description
> ---
> 
> BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719
> 
> Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
> Management Server and AWS API Installation Problems.
> This fixes the above two defects and other packaging related issues.
> 
> Signed-off-by: Pradeep 
> 
> 
> Diffs
> -
> 
>   awsapi-setup/setup/cloud-setup-bridge 
> d25072da1eb8ddd49a4d958218daeaac3537ec1b 
>   packaging/centos63/cloud.spec b4aa5199eb2f4f4b154c8fdab20f26600c964d06 
>   python/lib/cloudutils/serviceConfigServer.py 
> a08ce02d76678dc980071dd341037ff4c41eda76 
> 
> Diff: https://reviews.apache.org/r/10046/diff/
> 
> 
> Testing
> ---
> 
> Packaging went through with the fixes.
> 
> 
> Thanks,
> 
> Pradeep Soundararajan
> 
>

Re: Review Request: BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

[ASF Subversion and Git Services]

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


Commit 582f8a0f38f99030bec643ba733a42ee0167f9b4 in branch refs/heads/master 
from Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=582f8a0 ]

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


- ASF Subversion and Git Services


On March 20, 2013, 6:37 p.m., Pradeep Soundararajan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10046/
> ---
> 
> (Updated March 20, 2013, 6:37 p.m.)
> 
> 
> Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den 
> Hollander, and Noa Resare.
> 
> 
> Description
> ---
> 
> BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719
> 
> Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
> Management Server and AWS API Installation Problems.
> This fixes the above two defects and other packaging related issues.
> 
> Signed-off-by: Pradeep 
> 
> 
> Diffs
> -
> 
>   awsapi-setup/setup/cloud-setup-bridge 
> d25072da1eb8ddd49a4d958218daeaac3537ec1b 
>   packaging/centos63/cloud.spec b4aa5199eb2f4f4b154c8fdab20f26600c964d06 
>   python/lib/cloudutils/serviceConfigServer.py 
> a08ce02d76678dc980071dd341037ff4c41eda76 
> 
> Diff: https://reviews.apache.org/r/10046/diff/
> 
> 
> Testing
> ---
> 
> Packaging went through with the fixes.
> 
> 
> Thanks,
> 
> Pradeep Soundararajan
> 
>

Re: Review Request: BUG-ID: CLOUDSTACK-1713: EC2 REST API: AWS API Installation Problems

[ASF Subversion and Git Services]

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


Commit 582f8a0f38f99030bec643ba733a42ee0167f9b4 in branch refs/heads/master 
from Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=582f8a0 ]

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


- ASF Subversion and Git Services


On March 19, 2013, 10:36 a.m., Pradeep Soundararajan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10007/
> ---
> 
> (Updated March 19, 2013, 10:36 a.m.)
> 
> 
> Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den 
> Hollander, and Noa Resare.
> 
> 
> Description
> ---
> 
> BUG-ID: CLOUDSTACK-1713
> 
> Summary: EC2 REST API: AWS API Installation Problems
> 
> Description: Added the pre run for awsapi where it will create the user 
> 'cloud' during awsapi install and removed the unwanted entries from packaging 
> awsapi.
> 
> Signed-off-by: Pradeep 
> 
> 
> Diffs
> -
> 
>   packaging/centos63/cloud.spec 1b2c9a9633e161081809c3aa25574fdb863d4d0b 
> 
> Diff: https://reviews.apache.org/r/10007/diff/
> 
> 
> Testing
> ---
> 
> Tested with the latest build + packaging.
> 
> 
> Thanks,
> 
> Pradeep Soundararajan
> 
>

Re: Review Request: BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

[ASF Subversion and Git Services]

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


Commit 582f8a0f38f99030bec643ba733a42ee0167f9b4 in branch refs/heads/master 
from Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=582f8a0 ]

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


- ASF Subversion and Git Services


On March 22, 2013, 6:26 a.m., Pradeep Soundararajan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10047/
> ---
> 
> (Updated March 22, 2013, 6:26 a.m.)
> 
> 
> Review request for cloudstack, Chip Childers, Hugo Trippaers, Wido den 
> Hollander, and Noa Resare.
> 
> 
> Description
> ---
> 
> BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719
> 
> Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
> Management Server and AWS API Installation Problems.
> This fixes the above two defects and other packaging related issues.
> 
> Signed-off-by: Pradeep 
> 
> 
> Diffs
> -
> 
>   awsapi-setup/setup/cloud-setup-bridge d25072d 
>   packaging/centos63/cloud.spec 16c3602 
>   python/lib/cloudutils/serviceConfigServer.py a08ce02 
> 
> Diff: https://reviews.apache.org/r/10047/diff/
> 
> 
> Testing
> ---
> 
> Packaging went through with the fixes.
> 
> 
> Thanks,
> 
> Pradeep Soundararajan
> 
>

Re: Review Request: EC2 REST API: AWS APIs are not getting translated on the CloudStack Management Server and AWS API Installation Problems

[Chip Childers]

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

Ship it!


Applied to 4.1:

commit e46601463ca6000408e680003aae6f22951c0029
Author: Pradeep Soundararajan 
Date:   Tue Mar 26 13:25:57 2013 +

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the 
CloudStack Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


Applied to master:

commit 582f8a0f38f99030bec643ba733a42ee0167f9b4
Author: Pradeep Soundararajan 
Date:   Tue Mar 26 13:25:57 2013 +

BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719

Summary: EC2 REST API: AWS APIs are not getting translated on the 
CloudStack Management Server and AWS API Installation Problems.

Fixing the class not found exception, key not found and other issues as 
mentioned in the above two defects.

Signed-off-by: Pradeep 


- Chip Childers


On March 26, 2013, 7:41 a.m., Pradeep Soundararajan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10135/
> ---
> 
> (Updated March 26, 2013, 7:41 a.m.)
> 
> 
> Review request for cloudstack, Chip Childers, Prachi Damle, Likitha Shetty, 
> Hugo Trippaers, and Wido den Hollander.
> 
> 
> Description
> ---
> 
> BUG-ID: CLOUDSTACK-1713, CLOUDSTACK-1719
> 
> Summary: EC2 REST API: AWS APIs are not getting translated on the CloudStack 
> Management Server and AWS API Installation Problems.
> 
> Fixing the class not found exception, key not found and other issues as 
> mentioned in the above two defects.
> 
> Signed-off-by: Pradeep 
> 
> 
> Diffs
> -
> 
>   awsapi/src/com/cloud/bridge/util/EncryptionSecretKeyCheckerUtil.java 
> 0a652212b3eff91fdf950b189681713a7468a0b0 
>   packaging/centos63/cloud.spec db37afc475ff95315f4d18a08656a7ce86537487 
>   utils/src/com/cloud/utils/crypt/EncryptionSecretKeyChanger.java 
> 2be274921cce305b1a78513ad405c4ca895fc384 
>   utils/src/com/cloud/utils/crypt/EncryptionSecretKeyChecker.java 
> 5ffa14f30888924a5d26a2e70b23251d474743d5 
> 
> Diff: https://reviews.apache.org/r/10135/diff/
> 
> 
> Testing
> ---
> 
> Tested the build + packaging with this patch.
> 
> 
> Thanks,
> 
> Pradeep Soundararajan
> 
>

RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Koushik Das]

Think of the external C# component as external to CS. It exposes a REST 
endpoint and has independent lifecycle. The server resource running as part of 
Cloudstack MS will connect to this external REST endpoint.

> -Original Message-
> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> Sent: Tuesday, March 26, 2013 6:50 PM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance
> 
> The terminology for plugins has unfortunate overloading when it comes to
> the term 'ServerResource'.  As a Java class, it seems to be used to in the
> implementation both a plugin's ServerComponent and a plugin's
> ServerResource.  E.g. the KVM plugin has a 'dummy' ServerResource in the
> management server, and a real ServerResource in the remote agent.
> 
> With that in mind, do you mean for the C# component to be accessible over a
> RESTful API from plugin classes loaded into the management server?
> 
> DL
> 
> > -Original Message-
> > From: Koushik Das [mailto:koushik@citrix.com]
> > Sent: 26 March 2013 12:52 PM
> > To: dev@cloudstack.apache.org
> > Cc: cloudstack-...@incubator.apache.org
> > Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > Clearance
> >
> > Better to write the C# component doing Hyper-V specific stuff as a
> > standalone component and expose a REST API. The ServerResource class
> > is still in java and makes REST calls to the C# component.
> >
> > -Koushik
> >
> > > -Original Message-
> > > From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> > > Sent: Tuesday, March 26, 2013 3:29 PM
> > > To: dev@cloudstack.apache.org
> > > Cc: cloudstack-...@incubator.apache.org
> > > Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > > Clearance
> > >
> > >
> > > > -Original Message-
> > > > From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On
> > > Behalf
> > > > Of Rohit Yadav
> > > > Sent: 26 March 2013 4:02 AM
> > > > To: dev@cloudstack.apache.org
> > > > Cc: cloudstack-...@incubator.apache.org
> > > > Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > > > Clearance
> > > >
> > > > On Tue, Mar 26, 2013 at 4:31 AM, Donal Lafferty
> > > > 
> > > > wrote:
> > > > > It makes a lot of sense to write the ServerResourse for Hyper-V
> > > > > in C#,
> > > > because there's a lot of frameworks written in the Microsoft
> > > > ecosystem with C# in mind.
> > > > >
> > > > > If that's the case, then it also makes sense to use the
> > > > > Microsoft compiler to
> > > > compile the ServerResource.
> > > >
> > > > This won't get much love, instead of a compiler from the North
> > > > Atlantic giant,
> > > [Donal Lafferty]
> > > Northwest Pacific :)
> > > > if you were to use C# anyway why not consider using mono for your
> > > > compiler/build infrastructure? While I would avoid mono and it
> > > > would be difficult for folks to build/develop, if something could
> > > > be done in C#, could n't it be done in Java, Scala or anything
> > > > that could run on JVM? If this is possible, it will save us from
> > > > nonoss, proprietary
> > > build/runtime dependency.
> > > [Donal Lafferty]
> > > It's a question of what environment is optimal for the ServerResource.
> > > There is a lot more material for writing a server resource in C#
> > > than there is for writing it in Java.
> > >
> > > Moreover, the ServerResource concept of a plugin was introduced to
> > > allow developers a degree of freedom in choosing the environment for
> > > code that controls data centre resource.  Adopting platform-specific
> > > tools seems to flow naturally from this definition.  I guess you
> > > could call this the multi-lingual
> > > plugin:  one where the ServerResource and ServerComponent are not
> > > homogenous.
> > >
> > > What are the barriers to including 'multi-lingual plugins' in CloudStack?
> > >
> > > >
> > > > Cheers.
> > > >
> > > > >
> > > > > I'm unclear how this impacts contributing the code to Apache
> > CloudStack.
> > > > In particular:
> > > > >
> > > > >
> > > > > 1.   Does dependence on the Microsoft compiler mean that the
> > source
> > > > end up in the non-OSS build?
> > > > >
> > > > > 2.   Is the plugin able to participate in the BVT?
> > > > >
> > > > >

RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Donal Lafferty]

I think this split is already accounted for in the existing plugin 
architecture.  The external C# component you mention fits the definition of the 
plugin's "ServerResource".  The bit in the management server that talks to it 
would be a "ServerComponent".  See slide #7 of [1].

I agree with your proposal to use a RESTful API to link the two halves of the 
plugin. See [2] 

The problem is how best to add the C# component.  Does it suffice that the code 
and build project are donated, and users left to build their own?

DL


[1] 
http://www.slideshare.net/DonalLafferty/2013-0219cloud-platformpluginsfinaldistro
[2] http://markmail.org/thread/q2qhbtk2ipny3r2t 



> -Original Message-
> From: Koushik Das [mailto:koushik@citrix.com]
> Sent: 26 March 2013 2:07 PM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance
> 
> Think of the external C# component as external to CS. It exposes a REST
> endpoint and has independent lifecycle. The server resource running as part
> of Cloudstack MS will connect to this external REST endpoint.
> 
> > -Original Message-
> > From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> > Sent: Tuesday, March 26, 2013 6:50 PM
> > To: dev@cloudstack.apache.org
> > Cc: cloudstack-...@incubator.apache.org
> > Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > Clearance
> >
> > The terminology for plugins has unfortunate overloading when it comes
> > to the term 'ServerResource'.  As a Java class, it seems to be used to
> > in the implementation both a plugin's ServerComponent and a plugin's
> > ServerResource.  E.g. the KVM plugin has a 'dummy' ServerResource in
> > the management server, and a real ServerResource in the remote agent.
> >
> > With that in mind, do you mean for the C# component to be accessible
> > over a RESTful API from plugin classes loaded into the management server?
> >
> > DL
> >
> > > -Original Message-
> > > From: Koushik Das [mailto:koushik@citrix.com]
> > > Sent: 26 March 2013 12:52 PM
> > > To: dev@cloudstack.apache.org
> > > Cc: cloudstack-...@incubator.apache.org
> > > Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > > Clearance
> > >
> > > Better to write the C# component doing Hyper-V specific stuff as a
> > > standalone component and expose a REST API. The ServerResource class
> > > is still in java and makes REST calls to the C# component.
> > >
> > > -Koushik
> > >
> > > > -Original Message-
> > > > From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> > > > Sent: Tuesday, March 26, 2013 3:29 PM
> > > > To: dev@cloudstack.apache.org
> > > > Cc: cloudstack-...@incubator.apache.org
> > > > Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > > > Clearance
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On
> > > > Behalf
> > > > > Of Rohit Yadav
> > > > > Sent: 26 March 2013 4:02 AM
> > > > > To: dev@cloudstack.apache.org
> > > > > Cc: cloudstack-...@incubator.apache.org
> > > > > Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > > > > Clearance
> > > > >
> > > > > On Tue, Mar 26, 2013 at 4:31 AM, Donal Lafferty
> > > > > 
> > > > > wrote:
> > > > > > It makes a lot of sense to write the ServerResourse for
> > > > > > Hyper-V in C#,
> > > > > because there's a lot of frameworks written in the Microsoft
> > > > > ecosystem with C# in mind.
> > > > > >
> > > > > > If that's the case, then it also makes sense to use the
> > > > > > Microsoft compiler to
> > > > > compile the ServerResource.
> > > > >
> > > > > This won't get much love, instead of a compiler from the North
> > > > > Atlantic giant,
> > > > [Donal Lafferty]
> > > > Northwest Pacific :)
> > > > > if you were to use C# anyway why not consider using mono for
> > > > > your compiler/build infrastructure? While I would avoid mono and
> > > > > it would be difficult for folks to build/develop, if something
> > > > > could be done in C#, could n't it be done in Java, Scala or
> > > > > anything that could run on JVM? If this is possible, it will
> > > > > save us from nonoss, proprietary
> > > > build/runtime dependency.
> > > > [Donal Lafferty]
> > > > It's a question of what environment is optimal for the ServerResource.
> > > > There is a lot more material for writing a server resource in C#
> > > > than there is for writing it in Java.
> > > >
> > > > Moreover, the ServerResource concept of a plugin was introduced to
> > > > allow developers a degree of freedom in choosing the environment
> > > > for code that controls data centre resource.  Adopting
> > > > platform-specific tools seems to flow naturally from this
> > > > definition.  I guess you could call this the multi-lingual
> > > > plugin:  one where the ServerResource and ServerComponent are not
> > > > homogenous.
> > > >
> > > > What are the barriers to i

Re: [ACS41] [PATCH REQUEST] - CLOUDSTACK 1008

[Chip Childers]

On Tue, Mar 26, 2013 at 10:46:38AM +, Pranav Saxena wrote:
> 
> Hi Chip,
> 
> Could you please apply the patch attached to this JIRA ticket - 
> https://issues.apache.org/jira/browse/CLOUDSTACK-1008  ? It seems it's 
> specific to 4.1 and hence I haven't committed it to master.
> 
> Thanks,
> Pranav

Done! Thanks Pranav.

> From e1a9062e1c5d27e5b7a63d4f00c783112a1d3558 Mon Sep 17 00:00:00 2001
> From: Pranav Saxena 
> Date: Tue, 26 Mar 2013 16:02:19 +0530
> Subject: [PATCH] CLOUDSTACK-1008:Egress tab should not be presented in the UI
>  for Shared Networks
> 
> 
> Signed-off-by: Pranav Saxena 
> ---
>  ui/scripts/network.js |   15 ++-
>  1 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/ui/scripts/network.js b/ui/scripts/network.js
> index 84cc067..9bd0857 100755
> --- a/ui/scripts/network.js
> +++ b/ui/scripts/network.js
> @@ -807,6 +807,7 @@
>var hasSRXFirewall = false;
>var isVPC = false;
>var isAdvancedSGZone = false;
> +  var type;
>var hiddenTabs = [];
>  
>// Get network offering data
> @@ -862,12 +863,24 @@
>isAdvancedSGZone = zone.securitygroupsenabled;
>  }
>});
> + 
> +   $.ajax({
> + url:createURL('listNetworks'),
> + data:{ id:args.context.networks[0].id },
> + async:false,
> + success:function(json){
> +   type = json.listnetworksresponse.network[0].type;
> +
> + }
> +
> + });
> +
>  
>if (!networkOfferingHavingELB) {
>  hiddenTabs.push("addloadBalancer");
>}
>  
> -  if (isVPC || isAdvancedSGZone || hasSRXFirewall) {
> +  if (isVPC || isAdvancedSGZone || hasSRXFirewall || 
> type="Shared") {
>  hiddenTabs.push('egressRules');
> }
>
> -- 
> 1.7.5.4
> 

Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Sebastien Goasguen]

On Mar 26, 2013, at 10:22 AM, Donal Lafferty  wrote:

> I think this split is already accounted for in the existing plugin 
> architecture.  The external C# component you mention fits the definition of 
> the plugin's "ServerResource".  The bit in the management server that talks 
> to it would be a "ServerComponent".  See slide #7 of [1].
> 
> I agree with your proposal to use a RESTful API to link the two halves of the 
> plugin. See [2] 
> 
> The problem is how best to add the C# component.  Does it suffice that the 
> code and build project are donated, and users left to build their own?
> 

I missing some of the context here. I thought that you could talk directly from 
the MS to the provided WMI API over the network.  
If not then why not just using the Python WMI module, expose a REST API from 
there and get done with it ?


> DL
> 
> 
> [1] 
> http://www.slideshare.net/DonalLafferty/2013-0219cloud-platformpluginsfinaldistro
> [2] http://markmail.org/thread/q2qhbtk2ipny3r2t 
> 
> 
> 
>> -Original Message-
>> From: Koushik Das [mailto:koushik@citrix.com]
>> Sent: 26 March 2013 2:07 PM
>> To: dev@cloudstack.apache.org
>> Cc: cloudstack-...@incubator.apache.org
>> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance
>> 
>> Think of the external C# component as external to CS. It exposes a REST
>> endpoint and has independent lifecycle. The server resource running as part
>> of Cloudstack MS will connect to this external REST endpoint.
>> 
>>> -Original Message-
>>> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
>>> Sent: Tuesday, March 26, 2013 6:50 PM
>>> To: dev@cloudstack.apache.org
>>> Cc: cloudstack-...@incubator.apache.org
>>> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
>>> Clearance
>>> 
>>> The terminology for plugins has unfortunate overloading when it comes
>>> to the term 'ServerResource'.  As a Java class, it seems to be used to
>>> in the implementation both a plugin's ServerComponent and a plugin's
>>> ServerResource.  E.g. the KVM plugin has a 'dummy' ServerResource in
>>> the management server, and a real ServerResource in the remote agent.
>>> 
>>> With that in mind, do you mean for the C# component to be accessible
>>> over a RESTful API from plugin classes loaded into the management server?
>>> 
>>> DL
>>> 
 -Original Message-
 From: Koushik Das [mailto:koushik@citrix.com]
 Sent: 26 March 2013 12:52 PM
 To: dev@cloudstack.apache.org
 Cc: cloudstack-...@incubator.apache.org
 Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
 Clearance
 
 Better to write the C# component doing Hyper-V specific stuff as a
 standalone component and expose a REST API. The ServerResource class
 is still in java and makes REST calls to the C# component.
 
 -Koushik
 
> -Original Message-
> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> Sent: Tuesday, March 26, 2013 3:29 PM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> Clearance
> 
> 
>> -Original Message-
>> From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On
> Behalf
>> Of Rohit Yadav
>> Sent: 26 March 2013 4:02 AM
>> To: dev@cloudstack.apache.org
>> Cc: cloudstack-...@incubator.apache.org
>> Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
>> Clearance
>> 
>> On Tue, Mar 26, 2013 at 4:31 AM, Donal Lafferty
>> 
>> wrote:
>>> It makes a lot of sense to write the ServerResourse for
>>> Hyper-V in C#,
>> because there's a lot of frameworks written in the Microsoft
>> ecosystem with C# in mind.
>>> 
>>> If that's the case, then it also makes sense to use the
>>> Microsoft compiler to
>> compile the ServerResource.
>> 
>> This won't get much love, instead of a compiler from the North
>> Atlantic giant,
> [Donal Lafferty]
> Northwest Pacific :)
>> if you were to use C# anyway why not consider using mono for
>> your compiler/build infrastructure? While I would avoid mono and
>> it would be difficult for folks to build/develop, if something
>> could be done in C#, could n't it be done in Java, Scala or
>> anything that could run on JVM? If this is possible, it will
>> save us from nonoss, proprietary
> build/runtime dependency.
> [Donal Lafferty]
> It's a question of what environment is optimal for the ServerResource.
> There is a lot more material for writing a server resource in C#
> than there is for writing it in Java.
> 
> Moreover, the ServerResource concept of a plugin was introduced to
> allow developers a degree of freedom in choosing the environment
> for code that controls data centre resource.  Adopting
> platform-specific tools seems to flow naturally fr

Re: [PROPOSAL] EIP across zones

[Adam Grochowski]

Hi,
So I'm curious - what is the proposed method to move a single IP
across zones (presuming these zones span regions).  As Chiradeep
mentioned earlier, /24 is the largest block that will be advertised,
so it would necessitate moving (or advertising in two locations, and
back hauling back to one)  an entire class C to accomplish this (or
some black magic like LISP).

My other question revolves around the actual usefulness of EIP across
regions, and whether or not the problem can be solved simply with DNS
changes / global load balancing.

On Fri, Mar 22, 2013 at 4:34 AM, Murali Reddy  wrote:
> On 22/03/13 9:37 AM, "Manan Shah"  wrote:
>
>>My assumption is that EIP for VPC should work exactly the same as EIP for
>>Isolated Networks since EIP is like another Public IP except that it can
>>be moved across zones. Also, we do support static NAT in VPC as well as
>>Isolated. So, my thinking is that it might just work with minimal effort.
>
> It might not just work. I can think of questions like, can I move the EIP
> across the tiers in VPC? Since cloudStack can not have tier's of VPC in
> multiple zones, question of moving across zones does not arise? Does EIP
> service provider and 'public gateway' need to be same? Does network ACL's
> has any impact? Etc.
>
> It would take significant time to think through the scenarios, tweak the
> existing VPC functionality to adapt to EIP, write unit test, marvin test.
> Also QA effort for EIP in isolated network won't be same for VPC.
>
>>
>>Regards,
>>Manan Shah
>
>
>



-- 
Adam Grochowski ** SunGard Availability Services ** 401 N. Broad
Street - Mezzanine ** Philadelphia, PA 19108 ** 215-446-2679 **
adam.grochow...@sungard.com

RE: [ACS41] [PATCH REQUEST] - CLOUDSTACK 1008

[Pranav Saxena]

Thanks Chip!

Regards,
Pranav

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, March 26, 2013 7:56 PM
To: Pranav Saxena
Cc: cloudstack-...@incubator.apache.org
Subject: Re: [ACS41] [PATCH REQUEST] - CLOUDSTACK 1008

On Tue, Mar 26, 2013 at 10:46:38AM +, Pranav Saxena wrote:
> 
> Hi Chip,
> 
> Could you please apply the patch attached to this JIRA ticket - 
> https://issues.apache.org/jira/browse/CLOUDSTACK-1008  ? It seems it's 
> specific to 4.1 and hence I haven't committed it to master.
> 
> Thanks,
> Pranav

Done! Thanks Pranav.

> From e1a9062e1c5d27e5b7a63d4f00c783112a1d3558 Mon Sep 17 00:00:00 2001
> From: Pranav Saxena 
> Date: Tue, 26 Mar 2013 16:02:19 +0530
> Subject: [PATCH] CLOUDSTACK-1008:Egress tab should not be presented in 
> the UI  for Shared Networks
> 
> 
> Signed-off-by: Pranav Saxena 
> ---
>  ui/scripts/network.js |   15 ++-
>  1 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/ui/scripts/network.js b/ui/scripts/network.js index 
> 84cc067..9bd0857 100755
> --- a/ui/scripts/network.js
> +++ b/ui/scripts/network.js
> @@ -807,6 +807,7 @@
>var hasSRXFirewall = false;
>var isVPC = false;
>var isAdvancedSGZone = false;
> +  var type;
>var hiddenTabs = [];
>  
>// Get network offering data @@ -862,12 +863,24 @@
>isAdvancedSGZone = zone.securitygroupsenabled;
>  }
>});
> + 
> +   $.ajax({
> + url:createURL('listNetworks'),
> + data:{ id:args.context.networks[0].id },
> + async:false,
> + success:function(json){
> +   type = json.listnetworksresponse.network[0].type;
> +
> + }
> +
> + });
> +
>  
>if (!networkOfferingHavingELB) {
>  hiddenTabs.push("addloadBalancer");
>}
>  
> -  if (isVPC || isAdvancedSGZone || hasSRXFirewall) {
> +  if (isVPC || isAdvancedSGZone || hasSRXFirewall || 
> + type="Shared") {
>  hiddenTabs.push('egressRules');
> }
>
> --
> 1.7.5.4
> 

UCS Jar

[Francois Gaudreault]

Hi,

Trying to build 4.1, it fails on the UCS module jar not being in the 
online 4.1.0 snapshot.  Where this file is located now?


Downloading: 
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/maven-metadata.xml
Downloading: 
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.pom
[WARNING] The POM for 
org.apache.cloudstack:cloud-plugin-hypervisor-ucs:jar:4.1.0-SNAPSHOT is 
missing, no dependency information available
Downloading: 
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.jar


Thanks!

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

Re: [PROPOSAL] "Internal Load Balancing between VPC tiers"

[Alena Prokharchyk]

Marcus is right. The LB VM resides just on one tier (App in my FS
example). To manage the access from Web Tier to the App tier, Network ACLs
will be used.

-Alena.

On 3/25/13 7:55 PM, "Marcus Sorensen"  wrote:

>I assume, and it seems this way from the spec, that the load balancer VM
>just lives in the same network as the VMS you want to balance and
>redirects
>traffic to them. It has a link local nic plus 1 nic.
>
>That's why I was thinking it would be easy to just create a static Nat
>rule
>to the internal load balancer for public load balancing on any network
>tier.
>On Mar 25, 2013 8:46 PM, "Vijay Venkatachalam" <
>vijay.venkatacha...@citrix.com> wrote:
>
>> If the services are provided by a LBVM, it should have access to both
>> networks, one NIC in the web tier (the guest network where the VIP is
>> present) and one NIC in the App Tier (the guest network where the server
>> vms are present), would that understanding be right? So when
>>provisioning
>> the LB VM the user has to specify these 2 networks?
>>
>> On the similar lines, if an external LB Appliance is providing the
>> service,  it has to be wired to both the VIP network  and the server vm
>> network.
>>
>> Thanks,
>> Vijay V.
>>
>> > -Original Message-
>> > From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
>> > Sent: Saturday, March 23, 2013 4:28 AM
>> > To: cloudstack-...@incubator.apache.org
>> > Cc: Alex Huang; Chiradeep Vittal
>> > Subject: [PROPOSAL] "Internal Load Balancing between VPC tiers"
>> >
>> > I would like to propose a new feature - "Internal Load Balancing
>>between
>> > VPC tiers".  With the feature support, you can set up the Load
>>Balancer
>> inside
>> > the VPC without facing the public network side. It will allow to
>>balance
>> > internal traffic between tiers inside the VPC - for example, traffic
>> coming
>> > from Web Tier to the App tier.
>> >
>> >
>> > Please review the firs draft of FS and provide your comments and
>> feedback.
>> > If you feel like some details are missing, let me know and I'll
>>update it
>> > promptly.
>> >
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+B
>> > alanc
>> > ing+between+VPC+tiers
>> >
>> >
>> > Alex/Chiradeep, would appreciate your reviewal as you were the
>>original
>> > contributors for the majority of cloudStack Networking code.
>> >
>> >
>> > Thank you,
>> > -Alena.
>>
>>
>

RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Donal Lafferty]

Comments inline

> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: 26 March 2013 2:37 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance
> 
> 
> On Mar 26, 2013, at 10:22 AM, Donal Lafferty 
> wrote:
> 
> > I think this split is already accounted for in the existing plugin 
> > architecture.
> The external C# component you mention fits the definition of the plugin's
> "ServerResource".  The bit in the management server that talks to it would
> be a "ServerComponent".  See slide #7 of [1].
> >
> > I agree with your proposal to use a RESTful API to link the two halves
> > of the plugin. See [2]
> >
> > The problem is how best to add the C# component.  Does it suffice that the
> code and build project are donated, and users left to build their own?
> >
> 
> I missing some of the context here. I thought that you could talk directly 
> from
> the MS to the provided WMI API over the network.
[Donal Lafferty] 
Good question.  Using WS-Man in a Java environment isn't a great starting 
point.  The Java WS-Man Microsoft had evaluated still had minor problems, 
Alessandro Politi (Hyper-V developer) pointed out that WS-Man will be slow, and 
finally, WS-Man does not offer a flexible means for supporting image motion for 
template download.  An agent running on Hyper-V overcomes these problems.

> If not then why not just using the Python WMI module, expose a REST API
> from there and get done with it ?
[Donal Lafferty] 
The C# ecosystem allows me to focus on the REST API.  Tools and frameworks take 
care of background noise such as the web framework, HTTP server, and execution 
as a daemon.  

An all Python solution (python/django/apache) can come later as a Phase 3 or 
KVM port of a working example.  Alternatively, a Google Summer of Code project 
could be created for a student who wants to apply Python technologies with a 
specific goal in mind.

> 
> 
> > DL
> >
> >
> > [1]
> > http://www.slideshare.net/DonalLafferty/2013-0219cloud-platformplugins
> > finaldistro [2] http://markmail.org/thread/q2qhbtk2ipny3r2t
> >
> >
> >
> >> -Original Message-
> >> From: Koushik Das [mailto:koushik@citrix.com]
> >> Sent: 26 March 2013 2:07 PM
> >> To: dev@cloudstack.apache.org
> >> Cc: cloudstack-...@incubator.apache.org
> >> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> >> Clearance
> >>
> >> Think of the external C# component as external to CS. It exposes a
> >> REST endpoint and has independent lifecycle. The server resource
> >> running as part of Cloudstack MS will connect to this external REST
> endpoint.
> >>
> >>> -Original Message-
> >>> From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> >>> Sent: Tuesday, March 26, 2013 6:50 PM
> >>> To: dev@cloudstack.apache.org
> >>> Cc: cloudstack-...@incubator.apache.org
> >>> Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> >>> Clearance
> >>>
> >>> The terminology for plugins has unfortunate overloading when it
> >>> comes to the term 'ServerResource'.  As a Java class, it seems to be
> >>> used to in the implementation both a plugin's ServerComponent and a
> >>> plugin's ServerResource.  E.g. the KVM plugin has a 'dummy'
> >>> ServerResource in the management server, and a real ServerResource in
> the remote agent.
> >>>
> >>> With that in mind, do you mean for the C# component to be accessible
> >>> over a RESTful API from plugin classes loaded into the management
> server?
> >>>
> >>> DL
> >>>
>  -Original Message-
>  From: Koushik Das [mailto:koushik@citrix.com]
>  Sent: 26 March 2013 12:52 PM
>  To: dev@cloudstack.apache.org
>  Cc: cloudstack-...@incubator.apache.org
>  Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
>  Clearance
> 
>  Better to write the C# component doing Hyper-V specific stuff as a
>  standalone component and expose a REST API. The ServerResource
>  class is still in java and makes REST calls to the C# component.
> 
>  -Koushik
> 
> > -Original Message-
> > From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
> > Sent: Tuesday, March 26, 2013 3:29 PM
> > To: dev@cloudstack.apache.org
> > Cc: cloudstack-...@incubator.apache.org
> > Subject: RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> > Clearance
> >
> >
> >> -Original Message-
> >> From: rohityada...@gmail.com [mailto:rohityada...@gmail.com]
> On
> > Behalf
> >> Of Rohit Yadav
> >> Sent: 26 March 2013 4:02 AM
> >> To: dev@cloudstack.apache.org
> >> Cc: cloudstack-...@incubator.apache.org
> >> Subject: Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP
> >> Clearance
> >>
> >> On Tue, Mar 26, 2013 at 4:31 AM, Donal Lafferty
> >> 
> >> wrote:
> >>> It makes a lot of sense to write the ServerResourse for Hyper-V
> >>> in C#,
> >> bec

Question about changing characteristics of a VM or data disk

[Mike Tutkowski]

Hi,

Just a quick question here.

Once you've spun up a VM or created a data disk, is it possible to change
the characteristics of said VM or data disk (like give more RAM to the VM,
increase the size of the volume, etc.)?

Thanks!

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

RE: Question about changing characteristics of a VM or data disk

[Giles Sirett]

Mike

I think you need to stop the  instance, you can then change the service 
offering that its attached to

Kind Regards
Giles

D: +44 20 3603 0541 | M: +44 796 111 2055
giles.sir...@shapeblue.com




-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: 26 March 2013 16:09
To: cloudstack-...@incubator.apache.org
Subject: Question about changing characteristics of a VM or data disk

Hi,

Just a quick question here.

Once you've spun up a VM or created a data disk, is it possible to change the 
characteristics of said VM or data disk (like give more RAM to the VM, increase 
the size of the volume, etc.)?

Thanks!

--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*
This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is operated under 
license from Shape Blue Ltd. ShapeBlue is a registered trademark.

RE: Question about changing characteristics of a VM or data disk

[Pranav Saxena]

Hey Mike , 

You don't have to necessarily stop the VM in case you want to scale up the CPU 
and RAM. With the introduction of this new feature in 4.2  
(https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM
 ) , you can scale them up while the VMs are in the running state.

Regards,
Pranav

-Original Message-
From: Giles Sirett [mailto:giles.sir...@shapeblue.com] 
Sent: Tuesday, March 26, 2013 9:47 PM
To: dev@cloudstack.apache.org
Subject: RE: Question about changing characteristics of a VM or data disk

Mike

I think you need to stop the  instance, you can then change the service 
offering that its attached to

Kind Regards
Giles

D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com




-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: 26 March 2013 16:09
To: cloudstack-...@incubator.apache.org
Subject: Question about changing characteristics of a VM or data disk

Hi,

Just a quick question here.

Once you've spun up a VM or created a data disk, is it possible to change the 
characteristics of said VM or data disk (like give more RAM to the VM, increase 
the size of the volume, etc.)?

Thanks!

--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*
This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is operated under 
license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Question about changing characteristics of a VM or data disk

[Mike Tutkowski]

Thanks, guys!

By the way, before 4.2, can you explain how one changes these
characteristics?  Is the VM I spun up still tied to the compute offering I
used?  Do I just go into the compute offering I used to spin up the VM,
change it, then re-start my VM?  What if the compute offering has been
deleted?

Thanks again!


On Tue, Mar 26, 2013 at 10:20 AM, Pranav Saxena wrote:

> Hey Mike ,
>
> You don't have to necessarily stop the VM in case you want to scale up the
> CPU and RAM. With the introduction of this new feature in 4.2  (
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM)
>  , you can scale them up while the VMs are in the running state.
>
> Regards,
> Pranav
>
> -Original Message-
> From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
> Sent: Tuesday, March 26, 2013 9:47 PM
> To: dev@cloudstack.apache.org
> Subject: RE: Question about changing characteristics of a VM or data disk
>
> Mike
>
> I think you need to stop the  instance, you can then change the service
> offering that its attached to
>
> Kind Regards
> Giles
>
> D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com
>
>
>
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: 26 March 2013 16:09
> To: cloudstack-...@incubator.apache.org
> Subject: Question about changing characteristics of a VM or data disk
>
> Hi,
>
> Just a quick question here.
>
> Once you've spun up a VM or created a data disk, is it possible to change
> the characteristics of said VM or data disk (like give more RAM to the VM,
> increase the size of the volume, etc.)?
>
> Thanks!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is
> operated under license from Shape Blue Ltd. ShapeBlue is a registered
> trademark.
>
>


-- 
*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] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Alex Huang]

> 1.   Does dependence on the Microsoft compiler mean that the source end
> up in the non-OSS build?

I don't think so.

> 
> 2.   Is the plugin able to participate in the BVT?
> 
BVT must be able to accommodate this.  We need to figure out a way for the 
build system to accommodate for this as well.  Can you get in touch with 
Pradeep (build) and Prasanna (bvt) on this?

--Alex

Re: Question about changing characteristics of a VM or data disk

[Kelceydamage@bbits]

Sent from my iPhone

On Mar 26, 2013, at 9:25 AM, Mike Tutkowski  
wrote:

> Thanks, guys!
> 
> By the way, before 4.2, can you explain how one changes these
> characteristics?  Is the VM I spun up still tied to the compute offering I
> used?  Do I just go into the compute offering I used to spin up the VM,
> change it, then re-start my VM?  What if the compute offering has been
> deleted?
> 
> Thanks again!
> 
> 
> On Tue, Mar 26, 2013 at 10:20 AM, Pranav Saxena 
> wrote:
> 
>> Hey Mike ,
>> 
>> You don't have to necessarily stop the VM in case you want to scale up the
>> CPU and RAM. With the introduction of this new feature in 4.2  (
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM)
>>  , you can scale them up while the VMs are in the running state.
>> 
>> Regards,
>> Pranav
>> 
>> -Original Message-
>> From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
>> Sent: Tuesday, March 26, 2013 9:47 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: Question about changing characteristics of a VM or data disk
>> 
>> Mike
>> 
>> I think you need to stop the  instance, you can then change the service
>> offering that its attached to
>> 
>> Kind Regards
>> Giles
>> 
>> D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 26 March 2013 16:09
>> To: cloudstack-...@incubator.apache.org
>> Subject: Question about changing characteristics of a VM or data disk
>> 
>> Hi,
>> 
>> Just a quick question here.
>> 
>> Once you've spun up a VM or created a data disk, is it possible to change
>> the characteristics of said VM or data disk (like give more RAM to the VM,
>> increase the size of the volume, etc.)?
>> 
>> Thanks!
>> 
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud
>> *(tm)*
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. Shape Blue Ltd is a
>> company incorporated in England & Wales. ShapeBlue Services India LLP is
>> operated under license from Shape Blue Ltd. ShapeBlue is a registered
>> trademark.
>> 
>> 
> 
> 
> -- 
> *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: Question about changing characteristics of a VM or data disk

[Kelceydamage@bbits]

Currently the vm needs to be off. There is a dangerous DB hack to do in-place 
resource changes, but most simply turn off the vm before adjusting the compute 
offering as allowed by the GUI.

Hope that helps.

Sent from my iPhone

On Mar 26, 2013, at 9:25 AM, Mike Tutkowski  
wrote:

> Thanks, guys!
> 
> By the way, before 4.2, can you explain how one changes these
> characteristics?  Is the VM I spun up still tied to the compute offering I
> used?  Do I just go into the compute offering I used to spin up the VM,
> change it, then re-start my VM?  What if the compute offering has been
> deleted?
> 
> Thanks again!
> 
> 
> On Tue, Mar 26, 2013 at 10:20 AM, Pranav Saxena 
> wrote:
> 
>> Hey Mike ,
>> 
>> You don't have to necessarily stop the VM in case you want to scale up the
>> CPU and RAM. With the introduction of this new feature in 4.2  (
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM)
>>  , you can scale them up while the VMs are in the running state.
>> 
>> Regards,
>> Pranav
>> 
>> -Original Message-
>> From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
>> Sent: Tuesday, March 26, 2013 9:47 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: Question about changing characteristics of a VM or data disk
>> 
>> Mike
>> 
>> I think you need to stop the  instance, you can then change the service
>> offering that its attached to
>> 
>> Kind Regards
>> Giles
>> 
>> D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 26 March 2013 16:09
>> To: cloudstack-...@incubator.apache.org
>> Subject: Question about changing characteristics of a VM or data disk
>> 
>> Hi,
>> 
>> Just a quick question here.
>> 
>> Once you've spun up a VM or created a data disk, is it possible to change
>> the characteristics of said VM or data disk (like give more RAM to the VM,
>> increase the size of the volume, etc.)?
>> 
>> Thanks!
>> 
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud
>> *(tm)*
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. Shape Blue Ltd is a
>> company incorporated in England & Wales. ShapeBlue Services India LLP is
>> operated under license from Shape Blue Ltd. ShapeBlue is a registered
>> trademark.
>> 
>> 
> 
> 
> -- 
> *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] Commit email notifications

[Noah Slater]

Okay, thanks guys. Lazy consensus established.

I am going to put in the following request now:

Old: "git commit: %(subject)s"

New: "git commit: updated %(branch)s to %(branch_newsha)s"



On 21 March 2013 19:19, Paul Davis  wrote:

> I added some basic documentation on the specification and the
> available variables for use here:
>
> https://git-wip-us.apache.org/docs/commit-emails.html
>
> If you guys decide on a new format throw it in a JIRA ticket and I'll
> make the switch.
>
> On Thu, Mar 21, 2013 at 8:37 AM, Noah Slater  wrote:
> > Hey CloudStack devs,
> >
> > A bit of potential cross pollination here...
> >
> > I take it you've all noticed the
> > screen-full-of-emails-generated-by-a-Git-push thing we have going on?
> Well,
> > Paul Davis has figured out a way to get all those commits wrapped up
> into a
> > single thread in mail clients that support threading. (See the forwarded
> > message.)
> >
> > Is this something we're interested in switching to?
> >
> > Thanks,
> >
> >
> > -- Forwarded message --
> > From: Paul Davis 
> > Date: 20 March 2013 09:13
> > Subject: Commit email notifications
> > To: d...@couchdb.apache.org
> >
> >
> > First off, apologies for the commit spam. But hopefully I've managed
> > to find a decent combination of useful information and helpful
> > threading for most email clients.
> >
> > I got caught in the wind playing with email headers trying to set the
> > Message-Id and In-Reply-To/References headers to get threading to work
> > for the git email notifications. Then I remembered that GMail
> > basically ignores those. So I've gone and also changed the subject
> > formatting so that GMail does play nicely with threads.
> >
> > Basically, I've switched between these two email styles for commit
> > notifications:
> >
> > Old Style:
> >
> > [1/4] git commit: test commit 1/3
> >
> > New Style:
> >
> > [1/4] git commit: updated refs/heads/testing-email-notifications to
> > 51293df
> >
> > The first one has the benefit of showing what the actual commit was
> > about (this same information is repeated in the body) but the downside
> > is that GMail does terrible thing in conversation view with these. I
> > added a few things to the subject formatting and then set the format
> > CouchDB uses to the style shown. This style has the benefit that each
> > "push" to the repo should generate unique GMail conversations for each
> > branch updated and also gives us a bit of a log on individual updates
> > (a more thorough log is available via a URL I'm too lazy to lookup at
> > 4am).
> >
> > One of the major thorns I've been chewing on for awhile is when we
> > make an identical commit to more than one version branch and push all
> > of those updated branches in one go. The old version would group them
> > into a single GMail conversation which is a bit misleading and
> > sometimes hard to pick apart. The new format should avoid that but at
> > the loss of reading the "git log --oneline" history type log (that's
> > really out of order so not totally useful).
> >
> > So if I'm crazy and people really like the "single push fills your
> > inbox" approach let me know and I'll revert it and be more formal
> > about the change. Though hopefully this new behavior is a net positive
> > for everyone involved as my 4am brain seems to think is reasonable
> > which means I've probably pissed off a whole bunch of people.
> >
> >
> >
> > --
> > NS
>



-- 
NS

Re: [DISCUSS] Commit email notifications

[Noah Slater]

Here we go Paul: https://issues.apache.org/jira/browse/INFRA-6063


On 21 March 2013 19:19, Paul Davis  wrote:

> I added some basic documentation on the specification and the
> available variables for use here:
>
> https://git-wip-us.apache.org/docs/commit-emails.html
>
> If you guys decide on a new format throw it in a JIRA ticket and I'll
> make the switch.
>
> On Thu, Mar 21, 2013 at 8:37 AM, Noah Slater  wrote:
> > Hey CloudStack devs,
> >
> > A bit of potential cross pollination here...
> >
> > I take it you've all noticed the
> > screen-full-of-emails-generated-by-a-Git-push thing we have going on?
> Well,
> > Paul Davis has figured out a way to get all those commits wrapped up
> into a
> > single thread in mail clients that support threading. (See the forwarded
> > message.)
> >
> > Is this something we're interested in switching to?
> >
> > Thanks,
> >
> >
> > -- Forwarded message --
> > From: Paul Davis 
> > Date: 20 March 2013 09:13
> > Subject: Commit email notifications
> > To: d...@couchdb.apache.org
> >
> >
> > First off, apologies for the commit spam. But hopefully I've managed
> > to find a decent combination of useful information and helpful
> > threading for most email clients.
> >
> > I got caught in the wind playing with email headers trying to set the
> > Message-Id and In-Reply-To/References headers to get threading to work
> > for the git email notifications. Then I remembered that GMail
> > basically ignores those. So I've gone and also changed the subject
> > formatting so that GMail does play nicely with threads.
> >
> > Basically, I've switched between these two email styles for commit
> > notifications:
> >
> > Old Style:
> >
> > [1/4] git commit: test commit 1/3
> >
> > New Style:
> >
> > [1/4] git commit: updated refs/heads/testing-email-notifications to
> > 51293df
> >
> > The first one has the benefit of showing what the actual commit was
> > about (this same information is repeated in the body) but the downside
> > is that GMail does terrible thing in conversation view with these. I
> > added a few things to the subject formatting and then set the format
> > CouchDB uses to the style shown. This style has the benefit that each
> > "push" to the repo should generate unique GMail conversations for each
> > branch updated and also gives us a bit of a log on individual updates
> > (a more thorough log is available via a URL I'm too lazy to lookup at
> > 4am).
> >
> > One of the major thorns I've been chewing on for awhile is when we
> > make an identical commit to more than one version branch and push all
> > of those updated branches in one go. The old version would group them
> > into a single GMail conversation which is a bit misleading and
> > sometimes hard to pick apart. The new format should avoid that but at
> > the loss of reading the "git log --oneline" history type log (that's
> > really out of order so not totally useful).
> >
> > So if I'm crazy and people really like the "single push fills your
> > inbox" approach let me know and I'll revert it and be more formal
> > about the change. Though hopefully this new behavior is a net positive
> > for everyone involved as my 4am brain seems to think is reasonable
> > which means I've probably pissed off a whole bunch of people.
> >
> >
> >
> > --
> > NS
>



-- 
NS

Re: Question about changing characteristics of a VM or data disk

[Mike Tutkowski]

That does help, thanks.

So, not to belabor this point (I just want to make sure that I understand
correctly), once a VM is spun up from a compute offering, it is still tied
to this compute offering.  If you shut the VM down, change the compute
offering it was created from, then start it back up, it will take on the
new characteristics of the compute offering we changed?

Assuming what I wrote above is accurately describing what you guys are
saying, then what happens if the compute offering the VM was spawned from
has been deleted?  Does that mean you can no longer change the
characteristics of that VM?

Thanks!!


On Tue, Mar 26, 2013 at 10:33 AM, Kelceydamage@bbits wrote:

> Currently the vm needs to be off. There is a dangerous DB hack to do
> in-place resource changes, but most simply turn off the vm before adjusting
> the compute offering as allowed by the GUI.
>
> Hope that helps.
>
> Sent from my iPhone
>
> On Mar 26, 2013, at 9:25 AM, Mike Tutkowski 
> wrote:
>
> > Thanks, guys!
> >
> > By the way, before 4.2, can you explain how one changes these
> > characteristics?  Is the VM I spun up still tied to the compute offering
> I
> > used?  Do I just go into the compute offering I used to spin up the VM,
> > change it, then re-start my VM?  What if the compute offering has been
> > deleted?
> >
> > Thanks again!
> >
> >
> > On Tue, Mar 26, 2013 at 10:20 AM, Pranav Saxena <
> pranav.sax...@citrix.com>wrote:
> >
> >> Hey Mike ,
> >>
> >> You don't have to necessarily stop the VM in case you want to scale up
> the
> >> CPU and RAM. With the introduction of this new feature in 4.2  (
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM)
> , you can scale them up while the VMs are in the running state.
> >>
> >> Regards,
> >> Pranav
> >>
> >> -Original Message-
> >> From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
> >> Sent: Tuesday, March 26, 2013 9:47 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: Question about changing characteristics of a VM or data
> disk
> >>
> >> Mike
> >>
> >> I think you need to stop the  instance, you can then change the service
> >> offering that its attached to
> >>
> >> Kind Regards
> >> Giles
> >>
> >> D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com
> >>
> >>
> >>
> >>
> >> -Original Message-
> >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> >> Sent: 26 March 2013 16:09
> >> To: cloudstack-...@incubator.apache.org
> >> Subject: Question about changing characteristics of a VM or data disk
> >>
> >> Hi,
> >>
> >> Just a quick question here.
> >>
> >> Once you've spun up a VM or created a data disk, is it possible to
> change
> >> the characteristics of said VM or data disk (like give more RAM to the
> VM,
> >> increase the size of the volume, etc.)?
> >>
> >> Thanks!
> >>
> >> --
> >> *Mike Tutkowski*
> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> e: mike.tutkow...@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the
> >> cloud
> >> *(tm)*
> >> This email and any attachments to it may be confidential and are
> intended
> >> solely for the use of the individual to whom it is addressed. Any views
> or
> >> opinions expressed are solely those of the author and do not necessarily
> >> represent those of Shape Blue Ltd or related companies. If you are not
> the
> >> intended recipient of this email, you must neither take any action based
> >> upon its contents, nor copy or show it to anyone. Please contact the
> sender
> >> if you believe you have received this email in error. Shape Blue Ltd is
> a
> >> company incorporated in England & Wales. ShapeBlue Services India LLP is
> >> operated under license from Shape Blue Ltd. ShapeBlue is a registered
> >> trademark.
> >>
> >>
> >
> >
> > --
> > *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: Question about changing characteristics of a VM or data disk

[Kelceydamage@bbits]

You sir are correct :)

Really it's just an FK column in the DB

Sent from my iPhone

On Mar 26, 2013, at 9:47 AM, Mike Tutkowski  
wrote:

> That does help, thanks.
> 
> So, not to belabor this point (I just want to make sure that I understand
> correctly), once a VM is spun up from a compute offering, it is still tied
> to this compute offering.  If you shut the VM down, change the compute
> offering it was created from, then start it back up, it will take on the
> new characteristics of the compute offering we changed?
> 
> Assuming what I wrote above is accurately describing what you guys are
> saying, then what happens if the compute offering the VM was spawned from
> has been deleted?  Does that mean you can no longer change the
> characteristics of that VM?
> 
> Thanks!!
> 
> 
> On Tue, Mar 26, 2013 at 10:33 AM, Kelceydamage@bbits wrote:
> 
>> Currently the vm needs to be off. There is a dangerous DB hack to do
>> in-place resource changes, but most simply turn off the vm before adjusting
>> the compute offering as allowed by the GUI.
>> 
>> Hope that helps.
>> 
>> Sent from my iPhone
>> 
>> On Mar 26, 2013, at 9:25 AM, Mike Tutkowski 
>> wrote:
>> 
>>> Thanks, guys!
>>> 
>>> By the way, before 4.2, can you explain how one changes these
>>> characteristics?  Is the VM I spun up still tied to the compute offering
>> I
>>> used?  Do I just go into the compute offering I used to spin up the VM,
>>> change it, then re-start my VM?  What if the compute offering has been
>>> deleted?
>>> 
>>> Thanks again!
>>> 
>>> 
>>> On Tue, Mar 26, 2013 at 10:20 AM, Pranav Saxena <
>> pranav.sax...@citrix.com>wrote:
>>> 
 Hey Mike ,
 
 You don't have to necessarily stop the VM in case you want to scale up
>> the
 CPU and RAM. With the introduction of this new feature in 4.2  (
 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM)
>> , you can scale them up while the VMs are in the running state.
 
 Regards,
 Pranav
 
 -Original Message-
 From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
 Sent: Tuesday, March 26, 2013 9:47 PM
 To: dev@cloudstack.apache.org
 Subject: RE: Question about changing characteristics of a VM or data
>> disk
 
 Mike
 
 I think you need to stop the  instance, you can then change the service
 offering that its attached to
 
 Kind Regards
 Giles
 
 D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com
 
 
 
 
 -Original Message-
 From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
 Sent: 26 March 2013 16:09
 To: cloudstack-...@incubator.apache.org
 Subject: Question about changing characteristics of a VM or data disk
 
 Hi,
 
 Just a quick question here.
 
 Once you've spun up a VM or created a data disk, is it possible to
>> change
 the characteristics of said VM or data disk (like give more RAM to the
>> VM,
 increase the size of the volume, etc.)?
 
 Thanks!
 
 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the
 cloud
 *(tm)*
 This email and any attachments to it may be confidential and are
>> intended
 solely for the use of the individual to whom it is addressed. Any views
>> or
 opinions expressed are solely those of the author and do not necessarily
 represent those of Shape Blue Ltd or related companies. If you are not
>> the
 intended recipient of this email, you must neither take any action based
 upon its contents, nor copy or show it to anyone. Please contact the
>> sender
 if you believe you have received this email in error. Shape Blue Ltd is
>> a
 company incorporated in England & Wales. ShapeBlue Services India LLP is
 operated under license from Shape Blue Ltd. ShapeBlue is a registered
 trademark.
 
 
>>> 
>>> 
>>> --
>>> *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] create a general@ mailing list?

[Kelcey Damage (BT)]

I agree completely with your statement David.

-kd


>-Original Message-
>From: David Nalley [mailto:da...@gnsa.us]
>Sent: Monday, March 25, 2013 3:36 PM
>To: cloudstack-...@incubator.apache.org
>Subject: Re: [DISCUSS] create a general@ mailing list?
>
>On Wed, Mar 20, 2013 at 11:42 PM, Chip Childers
> wrote:
>> I've noticed that some of the projects separate discussions between
>> dev and general administrative items via a general@ and a dev@ list.
>> For example, the last email I sent was about project meta-data.  It's
>> not specifically about developing cloudstack, but about managing our
>> community activities.
>>
>> Does anyone think it makes sense to break that type of discussion out
>> into a general@ list?
>
>So I unclear on this.
>
>All committers are expected to be on -dev.
>
>Now, because administrivia is happening on general@ all committers will
also
>need to be on that list. So I don't see a lot of benefit to moving that
traffic off of
>dev@. I also don't see adminitrstrative stuff taking up that much
bandwidth. I
>understand marketing being separate, though I think we've seen a number of
>'missed messages'
>already from that. Dev@ is where contributors 'live' - so metadata about
the
>project seems a fit there - or am I missing something?
>
>--David

RE: UCS Jar

[Vijayendra Bhamidipati]

Hi Francois,

The UCS modules were temporarily disabled in bug CS-1773. The problem you are 
seeing could be caused by that - I'll take a look and get back to you at the 
earliest.

Regards,
Vijay

From: Francois Gaudreault [fgaudrea...@cloudops.com]
Sent: Tuesday, March 26, 2013 8:55 AM
To: dev@cloudstack.apache.org
Subject: UCS Jar

Hi,

Trying to build 4.1, it fails on the UCS module jar not being in the
online 4.1.0 snapshot.  Where this file is located now?

Downloading:
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/maven-metadata.xml
Downloading:
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.pom
[WARNING] The POM for
org.apache.cloudstack:cloud-plugin-hypervisor-ucs:jar:4.1.0-SNAPSHOT is
missing, no dependency information available
Downloading:
http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.jar

Thanks!

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

Re: UCS Jar

[Francois Gaudreault]

Cool! Keep us posted :)

Thanks Vijay!


On Tue, Mar 26, 2013 at 1:09 PM, Vijayendra Bhamidipati <
vijayendra.bhamidip...@citrix.com> wrote:

> Hi Francois,
>
> The UCS modules were temporarily disabled in bug CS-1773. The problem you
> are seeing could be caused by that - I'll take a look and get back to you
> at the earliest.
>
> Regards,
> Vijay
> 
> From: Francois Gaudreault [fgaudrea...@cloudops.com]
> Sent: Tuesday, March 26, 2013 8:55 AM
> To: dev@cloudstack.apache.org
> Subject: UCS Jar
>
> Hi,
>
> Trying to build 4.1, it fails on the UCS module jar not being in the
> online 4.1.0 snapshot.  Where this file is located now?
>
> Downloading:
>
> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/maven-metadata.xml
> Downloading:
>
> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.pom
> [WARNING] The POM for
> org.apache.cloudstack:cloud-plugin-hypervisor-ucs:jar:4.1.0-SNAPSHOT is
> missing, no dependency information available
> Downloading:
>
> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.jar
>
> Thanks!
>
> --
> Francois Gaudreault
> Architecte de Solution Cloud | Cloud Solutions Architect
> fgaudrea...@cloudops.com
> 514-629-6775
> - - -
> CloudOps
> 420 rue Guy
> Montréal QC  H3J 1S6
> www.cloudops.com
> @CloudOps_
>
>

[REMINDER] Weekly IRC Meeting Tomorrow

[Joe Brockmeier]

Weekly IRC meeting tomorrow at 17:00 UTC in #cloudstack-meeting on
Freenode. 

That's 10:00 a.m. PDT, 1:00 p.m. EDT. 

Standard agenda can be found here:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/IRC+Meetings+%28Logs+and+Minutes%29

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DISCUSS] Commit email notifications

[Paul Davis]

Done.

On Tue, Mar 26, 2013 at 11:43 AM, Noah Slater  wrote:
> Here we go Paul: https://issues.apache.org/jira/browse/INFRA-6063
>
>
> On 21 March 2013 19:19, Paul Davis  wrote:
>>
>> I added some basic documentation on the specification and the
>> available variables for use here:
>>
>> https://git-wip-us.apache.org/docs/commit-emails.html
>>
>> If you guys decide on a new format throw it in a JIRA ticket and I'll
>> make the switch.
>>
>> On Thu, Mar 21, 2013 at 8:37 AM, Noah Slater  wrote:
>> > Hey CloudStack devs,
>> >
>> > A bit of potential cross pollination here...
>> >
>> > I take it you've all noticed the
>> > screen-full-of-emails-generated-by-a-Git-push thing we have going on?
>> > Well,
>> > Paul Davis has figured out a way to get all those commits wrapped up
>> > into a
>> > single thread in mail clients that support threading. (See the forwarded
>> > message.)
>> >
>> > Is this something we're interested in switching to?
>> >
>> > Thanks,
>> >
>> >
>> > -- Forwarded message --
>> > From: Paul Davis 
>> > Date: 20 March 2013 09:13
>> > Subject: Commit email notifications
>> > To: d...@couchdb.apache.org
>> >
>> >
>> > First off, apologies for the commit spam. But hopefully I've managed
>> > to find a decent combination of useful information and helpful
>> > threading for most email clients.
>> >
>> > I got caught in the wind playing with email headers trying to set the
>> > Message-Id and In-Reply-To/References headers to get threading to work
>> > for the git email notifications. Then I remembered that GMail
>> > basically ignores those. So I've gone and also changed the subject
>> > formatting so that GMail does play nicely with threads.
>> >
>> > Basically, I've switched between these two email styles for commit
>> > notifications:
>> >
>> > Old Style:
>> >
>> > [1/4] git commit: test commit 1/3
>> >
>> > New Style:
>> >
>> > [1/4] git commit: updated refs/heads/testing-email-notifications to
>> > 51293df
>> >
>> > The first one has the benefit of showing what the actual commit was
>> > about (this same information is repeated in the body) but the downside
>> > is that GMail does terrible thing in conversation view with these. I
>> > added a few things to the subject formatting and then set the format
>> > CouchDB uses to the style shown. This style has the benefit that each
>> > "push" to the repo should generate unique GMail conversations for each
>> > branch updated and also gives us a bit of a log on individual updates
>> > (a more thorough log is available via a URL I'm too lazy to lookup at
>> > 4am).
>> >
>> > One of the major thorns I've been chewing on for awhile is when we
>> > make an identical commit to more than one version branch and push all
>> > of those updated branches in one go. The old version would group them
>> > into a single GMail conversation which is a bit misleading and
>> > sometimes hard to pick apart. The new format should avoid that but at
>> > the loss of reading the "git log --oneline" history type log (that's
>> > really out of order so not totally useful).
>> >
>> > So if I'm crazy and people really like the "single push fills your
>> > inbox" approach let me know and I'll revert it and be more formal
>> > about the change. Though hopefully this new behavior is a net positive
>> > for everyone involved as my 4am brain seems to think is reasonable
>> > which means I've probably pissed off a whole bunch of people.
>> >
>> >
>> >
>> > --
>> > NS
>
>
>
>
> --
> NS

Re: UCS Jar

[Francois Gaudreault]

Vijay,

For now, I extended the comment in client/pom.xml to include the ucs module
so the compile passes.  I guess that should be sufficient for me, but I
don't know if the dependency is required for something else.

Francois


On Tue, Mar 26, 2013 at 1:12 PM, Francois Gaudreault <
fgaudrea...@cloudops.com> wrote:

> Cool! Keep us posted :)
>
> Thanks Vijay!
>
>
> On Tue, Mar 26, 2013 at 1:09 PM, Vijayendra Bhamidipati <
> vijayendra.bhamidip...@citrix.com> wrote:
>
>> Hi Francois,
>>
>> The UCS modules were temporarily disabled in bug CS-1773. The problem you
>> are seeing could be caused by that - I'll take a look and get back to you
>> at the earliest.
>>
>> Regards,
>> Vijay
>> 
>> From: Francois Gaudreault [fgaudrea...@cloudops.com]
>> Sent: Tuesday, March 26, 2013 8:55 AM
>> To: dev@cloudstack.apache.org
>> Subject: UCS Jar
>>
>> Hi,
>>
>> Trying to build 4.1, it fails on the UCS module jar not being in the
>> online 4.1.0 snapshot.  Where this file is located now?
>>
>> Downloading:
>>
>> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/maven-metadata.xml
>> Downloading:
>>
>> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.pom
>> [WARNING] The POM for
>> org.apache.cloudstack:cloud-plugin-hypervisor-ucs:jar:4.1.0-SNAPSHOT is
>> missing, no dependency information available
>> Downloading:
>>
>> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.jar
>>
>> Thanks!
>>
>> --
>> Francois Gaudreault
>> Architecte de Solution Cloud | Cloud Solutions Architect
>> fgaudrea...@cloudops.com
>> 514-629-6775
>> - - -
>> CloudOps
>> 420 rue Guy
>> Montréal QC  H3J 1S6
>> www.cloudops.com
>> @CloudOps_
>>
>>
>

Re: [DISCUSS] Commit email notifications

[Noah Slater]

Let the good times roll! Thanks Paul.


On 26 March 2013 17:36, Paul Davis  wrote:

> Done.
>
> On Tue, Mar 26, 2013 at 11:43 AM, Noah Slater  wrote:
> > Here we go Paul: https://issues.apache.org/jira/browse/INFRA-6063
> >
> >
> > On 21 March 2013 19:19, Paul Davis  wrote:
> >>
> >> I added some basic documentation on the specification and the
> >> available variables for use here:
> >>
> >> https://git-wip-us.apache.org/docs/commit-emails.html
> >>
> >> If you guys decide on a new format throw it in a JIRA ticket and I'll
> >> make the switch.
> >>
> >> On Thu, Mar 21, 2013 at 8:37 AM, Noah Slater 
> wrote:
> >> > Hey CloudStack devs,
> >> >
> >> > A bit of potential cross pollination here...
> >> >
> >> > I take it you've all noticed the
> >> > screen-full-of-emails-generated-by-a-Git-push thing we have going on?
> >> > Well,
> >> > Paul Davis has figured out a way to get all those commits wrapped up
> >> > into a
> >> > single thread in mail clients that support threading. (See the
> forwarded
> >> > message.)
> >> >
> >> > Is this something we're interested in switching to?
> >> >
> >> > Thanks,
> >> >
> >> >
> >> > -- Forwarded message --
> >> > From: Paul Davis 
> >> > Date: 20 March 2013 09:13
> >> > Subject: Commit email notifications
> >> > To: d...@couchdb.apache.org
> >> >
> >> >
> >> > First off, apologies for the commit spam. But hopefully I've managed
> >> > to find a decent combination of useful information and helpful
> >> > threading for most email clients.
> >> >
> >> > I got caught in the wind playing with email headers trying to set the
> >> > Message-Id and In-Reply-To/References headers to get threading to work
> >> > for the git email notifications. Then I remembered that GMail
> >> > basically ignores those. So I've gone and also changed the subject
> >> > formatting so that GMail does play nicely with threads.
> >> >
> >> > Basically, I've switched between these two email styles for commit
> >> > notifications:
> >> >
> >> > Old Style:
> >> >
> >> > [1/4] git commit: test commit 1/3
> >> >
> >> > New Style:
> >> >
> >> > [1/4] git commit: updated refs/heads/testing-email-notifications
> to
> >> > 51293df
> >> >
> >> > The first one has the benefit of showing what the actual commit was
> >> > about (this same information is repeated in the body) but the downside
> >> > is that GMail does terrible thing in conversation view with these. I
> >> > added a few things to the subject formatting and then set the format
> >> > CouchDB uses to the style shown. This style has the benefit that each
> >> > "push" to the repo should generate unique GMail conversations for each
> >> > branch updated and also gives us a bit of a log on individual updates
> >> > (a more thorough log is available via a URL I'm too lazy to lookup at
> >> > 4am).
> >> >
> >> > One of the major thorns I've been chewing on for awhile is when we
> >> > make an identical commit to more than one version branch and push all
> >> > of those updated branches in one go. The old version would group them
> >> > into a single GMail conversation which is a bit misleading and
> >> > sometimes hard to pick apart. The new format should avoid that but at
> >> > the loss of reading the "git log --oneline" history type log (that's
> >> > really out of order so not totally useful).
> >> >
> >> > So if I'm crazy and people really like the "single push fills your
> >> > inbox" approach let me know and I'll revert it and be more formal
> >> > about the change. Though hopefully this new behavior is a net positive
> >> > for everyone involved as my 4am brain seems to think is reasonable
> >> > which means I've probably pissed off a whole bunch of people.
> >> >
> >> >
> >> >
> >> > --
> >> > NS
> >
> >
> >
> >
> > --
> > NS
>



-- 
NS

Re: Question about changing characteristics of a VM or data disk

[Mike Tutkowski]

OK, cool - thanks!

Piecing together more and more of how CloudStack works daily. :)

For volumes, I don't see any reference in the GUI to the Disk Offering they
were created from.  That must be in the DB, but not exposed to end users?


On Tue, Mar 26, 2013 at 10:54 AM, Kelceydamage@bbits wrote:

> You sir are correct :)
>
> Really it's just an FK column in the DB
>
> Sent from my iPhone
>
> On Mar 26, 2013, at 9:47 AM, Mike Tutkowski 
> wrote:
>
> > That does help, thanks.
> >
> > So, not to belabor this point (I just want to make sure that I understand
> > correctly), once a VM is spun up from a compute offering, it is still
> tied
> > to this compute offering.  If you shut the VM down, change the compute
> > offering it was created from, then start it back up, it will take on the
> > new characteristics of the compute offering we changed?
> >
> > Assuming what I wrote above is accurately describing what you guys are
> > saying, then what happens if the compute offering the VM was spawned from
> > has been deleted?  Does that mean you can no longer change the
> > characteristics of that VM?
> >
> > Thanks!!
> >
> >
> > On Tue, Mar 26, 2013 at 10:33 AM, Kelceydamage@bbits  >wrote:
> >
> >> Currently the vm needs to be off. There is a dangerous DB hack to do
> >> in-place resource changes, but most simply turn off the vm before
> adjusting
> >> the compute offering as allowed by the GUI.
> >>
> >> Hope that helps.
> >>
> >> Sent from my iPhone
> >>
> >> On Mar 26, 2013, at 9:25 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com>
> >> wrote:
> >>
> >>> Thanks, guys!
> >>>
> >>> By the way, before 4.2, can you explain how one changes these
> >>> characteristics?  Is the VM I spun up still tied to the compute
> offering
> >> I
> >>> used?  Do I just go into the compute offering I used to spin up the VM,
> >>> change it, then re-start my VM?  What if the compute offering has been
> >>> deleted?
> >>>
> >>> Thanks again!
> >>>
> >>>
> >>> On Tue, Mar 26, 2013 at 10:20 AM, Pranav Saxena <
> >> pranav.sax...@citrix.com>wrote:
> >>>
>  Hey Mike ,
> 
>  You don't have to necessarily stop the VM in case you want to scale up
> >> the
>  CPU and RAM. With the introduction of this new feature in 4.2  (
> 
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM
> )
> >> , you can scale them up while the VMs are in the running state.
> 
>  Regards,
>  Pranav
> 
>  -Original Message-
>  From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
>  Sent: Tuesday, March 26, 2013 9:47 PM
>  To: dev@cloudstack.apache.org
>  Subject: RE: Question about changing characteristics of a VM or data
> >> disk
> 
>  Mike
> 
>  I think you need to stop the  instance, you can then change the
> service
>  offering that its attached to
> 
>  Kind Regards
>  Giles
> 
>  D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com
> 
> 
> 
> 
>  -Original Message-
>  From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>  Sent: 26 March 2013 16:09
>  To: cloudstack-...@incubator.apache.org
>  Subject: Question about changing characteristics of a VM or data disk
> 
>  Hi,
> 
>  Just a quick question here.
> 
>  Once you've spun up a VM or created a data disk, is it possible to
> >> change
>  the characteristics of said VM or data disk (like give more RAM to the
> >> VM,
>  increase the size of the volume, etc.)?
> 
>  Thanks!
> 
>  --
>  *Mike Tutkowski*
>  *Senior CloudStack Developer, SolidFire Inc.*
>  e: mike.tutkow...@solidfire.com
>  o: 303.746.7302
>  Advancing the way the world uses the
>  cloud
>  *(tm)*
>  This email and any attachments to it may be confidential and are
> >> intended
>  solely for the use of the individual to whom it is addressed. Any
> views
> >> or
>  opinions expressed are solely those of the author and do not
> necessarily
>  represent those of Shape Blue Ltd or related companies. If you are not
> >> the
>  intended recipient of this email, you must neither take any action
> based
>  upon its contents, nor copy or show it to anyone. Please contact the
> >> sender
>  if you believe you have received this email in error. Shape Blue Ltd
> is
> >> a
>  company incorporated in England & Wales. ShapeBlue Services India LLP
> is
>  operated under license from Shape Blue Ltd. ShapeBlue is a registered
>  trademark.
> 
> 
> >>>
> >>>
> >>> --
> >>> *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 CloudSta

Re: CLOUDSTACK-528

[Chiradeep Vittal]

The bug suggests a work around?

On 3/26/13 4:12 AM, "nicolas.lamira...@orange.com"
 wrote:

>hi
>our upgrade from 2.2.14 to 4.0.x is blocked because of this issue :
>https://issues.apache.org/jira/browse/CLOUDSTACK-528
>does anyone have news about this problem ?
>Regards.
>
>-- 
>Nicolas Lamirault
>
>__
>___
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>France Telecom - Orange decline toute responsabilite si ce message a ete
>altere, deforme ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, France Telecom - Orange is not liable for
>messages that have been modified, changed or falsified.
>Thank you.
>

Re: [ACS41] Bugs blocking our 4.1 release

[Sheng Yang]

CLOUDSTACK-1755 IPv6 - When Vm is part of Dual network ,
/etc/reslov.conf does not have ipv6 router ipaddress and ipv6 external
dns.

This bug's fix version is 4.2...

--Sheng

On Tue, Mar 26, 2013 at 3:32 AM, Pradeep Soundararajan
 wrote:
> Resolved ---  CLOUDSTACK-1719 EC2 REST API: AWS APIs are not getting 
> translated on the CloudStack Management Server   Pradeep Soundararajan
> Unable to reproduce with the steps I have mentioned in the defect.  Hence, 
> dropping from Blocker ---  CLOUDSTACK-1694 Issues to start/access Management 
> Server after upgrade from 4.0 to 4.1  Pradeep Soundararajan
> Closed by Sangeetha as this is being tracked as part of CLOUDSTACK-1694 --- 
> CLOUDSTACK-1802 Upgrade 4.0 -> 4.1 - Not able to strat management server 
> becasue of missing /etc/cloudstack/management/tomcat6.conf file.   Pradeep 
> Soundararajan
>
> Thanks,
> Pradeep S
>
>
> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, March 26, 2013 1:45 AM
> To: dev@cloudstack.apache.org
> Subject: [ACS41] Bugs blocking our 4.1 release
>
> Hi all,
>
> The following bugs need to be either (1) resolved or (2) triaged as not being 
> as high a priority as they are now before I cut the RC.  Can folks take a 
> moment to review and update / fix accordingly please?
>
> CLOUDSTACK-1694 Issues to start/access Management Server after upgrade from 
> 4.0 to 4.1  Pradeep Soundararajan
> CLOUDSTACK-1719 EC2 REST API: AWS APIs are not getting translated on the 
> CloudStack Management Server   Pradeep Soundararajan
> CLOUDSTACK-1772 the change in vnc listening port will cause live migration 
> doesn't work edison su
> CLOUDSTACK-1795 Customize AOP to fully support legacy CloudStack @DB and 
> @ActionEvent semantics Kelven Yang
> CLOUDSTACK-1664 Action Events are not logged due to spring changes  Kelven 
> Yang
> CLOUDSTACK-1673 AWS Regions - Events - User disable event does not include 
> the UUID of the user that was disabled.  Murali Reddy
> CLOUDSTACK-1740 Failed to view console  Rajesh Battala
> CLOUDSTACK-1755 IPv6 - When Vm is part of Dual network , /etc/reslov.conf 
> does not have ipv6 router ipaddress and ipv6 external dns.Sheng Yang
> CLOUDSTACK-1789 Unable to download templates to Primary Storage if a host is 
> in maintenance edison su
> CLOUDSTACK-1802 Upgrade 4.0 -> 4.1 - Not able to strat management server 
> becasue of missing /etc/cloudstack/management/tomcat6.conf file.   Pradeep 
> Soundararajan
>
>
> I'd also like us to resolve 
> https://issues.apache.org/jira/browse/CLOUDSTACK-1796 - which is a Japanese 
> docs building issue.  Sebastien, can you please review the latest from 
> Transifex (per latest comment from Hiroaki)?
>
> -chip

Re: Install CS 4.0.1 On ESXI 5.0

[Ahmad Emneina]

you will probably need to post logs from your vmops.log file in order to
get concise help. Else we'll be stabbing in the dark, as to what the issue
is.


On Mon, Mar 25, 2013 at 11:08 PM, mahzad  wrote:

> Hi  I have installed CS 4.0.1  in CentOSBy using  your doc:
>
> Section of 4.4.2. RPM package repository  and
> http://cloudstack.apt-get.eu/rhel/4.0/
>
>
>
> My hypervisor is ESXI. Before setting NFS storage and  After installation
> rpms and testing  tomcat and httpd services ,I test UI , But client is not
> displayed :
>
> HTTP Status 404 - /client
>
>   _
>
> type Status report
>
> message /client
>
> description The requested resource (/client) is not available.
>
>
>
> What is Problem ?is it about VMWare support issues?!!!
>
>
>
>

Re: The Apache Software Foundation Announces Apache CloudStack™ as a Top-Level Project

[Jessica Tomechak]

Happy birthday.

Jessica T.

On Mon, Mar 25, 2013 at 7:30 AM, Wido den Hollander  wrote:

> On 03/25/2013 03:20 PM, Radhika Puthiyetath wrote:
>
>> Party time...
>>
>>
> Indeed! I'll open a beer on this awesome news tonight!
>
> Great work again everybody, let's keep making CloudStack better and better!
>
> Wido
>
>
>  -Original Message-
>> From: Joe Brockmeier [mailto:j...@zonker.net]
>> Sent: Monday, March 25, 2013 7:45 PM
>> To: dev@cloudstack.apache.org
>> Subject: The Apache Software Foundation Announces Apache CloudStack™ as a
>> Top-Level Project
>>
>> Sending to dev@ - it's now officially official: Please spread the word!
>> Thanks!
>>
>> Mature, Open Source turn-key platform widely used for delivering
>> scalable, full-featured Infrastructure-as-a-Service (IaaS) clouds.
>>
>> Forest Hill, MD –25 March 2013– The Apache Software Foundation (ASF), the
>> all-volunteer developers, stewards, and incubators of nearly 150 Open
>> Source projects and initiatives, today announced that Apache CloudStack has
>> graduated from the Apache Incubator to become a Top-Level Project (TLP),
>> signifying that the Project's community and products have been
>> well-governed under the ASF's meritocratic process and principles.
>>
>> "When CloudStack first became an Apache Incubator project, it was a
>> well-established cloud management platform with a mature codebase," said
>> Chip Childers, Vice President of Apache CloudStack. "Our work in the
>> Incubator has focused on growing a really strong community around the code
>> and establishing the governance practices expected of a top-level project
>> within The Apache Software Foundation."
>>
>> Widely used in production by many organizations, CloudStack is formerly
>> the product of Cloud.com, which was acquired by Citrix in 2011, and was
>> submitted to the Apache Incubator by Citrix in April 2012.
>>
>> Apache CloudStack is a complete software suite for creating
>> Infrastructure-as-a-Service (IaaS) cloud computing in private-, public-,
>> and hybrid cloud environments. It has been proven to be both stable and
>> highly scalable, underpinning production clouds with more than 30,000
>> physical nodes, in geo-distributed environments.
>>
>> "Becoming a TLP is an important step in the project's evolution and
>> growth," added Childers. "CloudStack had the advantage of having many
>> long-term, large deployments which had proven the stability and scalability
>> of the technology. This helped us concentrate on adopting the 'Apache Way'
>> of governance, which is well understood and open, delivering so many great
>> pieces of software over the years."
>>
>> CloudStack's target environments include service providers and
>> enterprises; it is used by many service providers to set up an on-demand,
>> elastic cloud computing services and by enterprises to set up a private
>> cloud for use by their own employees. Apache CloudStack is also available
>> to individuals and organizations that wish to study and implement an IaaS
>> for personal, educational, and/or production use.
>>
>> "We believe that Infrastructure-as-a-Service is the next generation of IT
>> infrastructure, and that people will demand open standards and open
>> governance for such an important layer in their IT stack," explained
>> Childers. That is why having the CloudStack project meet the rigorous
>> standards of ASF governance is so significant."
>>
>> Underscoring the ASF's edict of "Community over Code", Childers said:
>> "we've managed to build a diverse, friendly and very open community
>> around CloudStack. New participants receive a really warm welcome and we
>> make sure that all contributors are on an equal footing, whether they are
>> writing code or helping with any other aspect of the project.
>> Anybody thinking of getting involved in the project would quickly find
>> what a great community we are. In addition to online involvement, we've
>> already had a global collaboration conference and there are many CloudStack
>> groups established in many different countries."
>>
>> Availability and Oversight
>> Apache CloudStack software is released under the Apache License v2.0, and
>> is overseen by a self-selected team of active contributors to the project.
>> A Project Management Committee (PMC) guides the Project's day-to-day
>> operations, including community development and product releases. Apache
>> CloudStack source code, documentation, mailing lists, and related resources
>> are available at http://cloudstack.apache.org/.
>>
>> About the Apache Incubator
>> The Apache Incubator is the entry path for projects and codebases wishing
>> to become part of the efforts at The Apache Software Foundation.
>> All code donations from external organizations and existing external
>> projects wishing to join the ASF enter through the Incubator to: 1) ensure
>> all donations are in accordance with the ASF legal standards; and
>> 2) develop new communities that adhere to our guiding principles.
>> Incu

Re: Storage Subsystem 2.0 plugin docs

[Jessica Tomechak]

There is a bug filed to track documentation for this feature. It's
currently unassigned. Looks like a lot of good information is going past in
this email thread. Please consider this a friendly invitation to pull any
useful conclusions and use cases out of here and put them in the doc bug
comments, or update the FS, or create a wiki page and link to it from the
doc bug, so that the info is easy to find for whoever ends up fixing the
bug.

https://issues.apache.org/jira/browse/CLOUDSTACK-885

Thanks,
Jessica T.

On Mon, Mar 25, 2013 at 10:10 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Exactly, John ... All of what you said, plus - for example - it really puts
> the onus on the plug-in developer to update the plug in whenever we add
> support for a new hypervisor (say, HyperV).
>
> I'm happy to help out with this effort to extract hypervisor knowledge away
> from these plug-ins, so - if we go this route - please feel free to bring
> me in.
>
> Let's see what Edison thinks.
>
>
> On Mon, Mar 25, 2013 at 11:02 PM, John Burwell  wrote:
>
> > Mike,
> >
> > +1 .. If storage plugins have to understand each hypervisor, the
> > support matrix becomes unmaintainably complex.  We have a variety of
> > abstractions commonly understood by hypervisors (e.g. LUNs, I/O
> > streams, sockets, files, etc) that a storage can either be yielded or
> > manipulated by a storage plugin that it is possible to decouple
> > hypervisors and storage entities.
> >
> > Thanks,
> > -John
> >
> >
> >
> >
> > On Mar 25, 2013, at 5:37 PM, Mike Tutkowski
> >  wrote:
> >
> > > Hey Edison,
> > >
> > > So...if you think my understanding is correct (please check out the
> > e-mail
> > > below), then I have a question.
> > >
> > > Do we really want to have the storage plug-ins taking on the
> > responsibility
> > > of talking to the hypervisors to hook up the storage that they just
> > created=
> > > ?
> > >
> > > I'm a bit familiar with how OpenStack does this and it seems that it
> only
> > > has its storage plug-ins create a volume (LUN, whatever) and then the
> > > framework handles the process of dealing with the hypervisor in
> question
> > to
> > > hook up the storage.
> > >
> > > It seems like otherwise we'd need to create a utility for all storage
> > > plug-ins to share otherwise they'd be duplicating efforts in talking to
> > > hypervisors.
> > >
> > > What do you think?
> > >
> > >
> > > On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com> wrote:
> > >
> > >> Hi Edison,
> > >>
> > >> I believe I understand the requirements for the plug-in better now.
> > >>
> > >> It sounds like the flow will be as such:
> > >>
> > >> * The user executes a Compute or Disk Offering that is tied via a
> > storage
> > >> tag to a Primary Storage that is associated with a plug-in.
> > >>
> > >> * The storage framework will ask the plug-in to create a volume.  The
> > >> plug-in will create a volume and hook the volume up to the appropriate
> > >> hypervisor.  For VMware, this means the plug-in will create a
> Datastore.
> > >> For XenServer, this means the plug-in will create a Storage
> Repository.
> > >> (So on and so forth for other hypervisors.)
> > >>
> > >> * The VM or data disk is then deployed to the hypervisor.
> > >>
> > >> Does that sound correct, Edison?
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> On Thu, Mar 21, 2013 at 5:44 PM, Edison Su 
> > wrote:
> > >>
> > >>> ** **
> > >>>
> > >>> ** **
> > >>>
> > >>> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > >>> *Sent:* Thursday, March 21, 2013 4:18 PM
> > >>> *To:* Edison Su
> > >>> *Subject:* Re: Storage Subsystem 2.0 plugin docs
> > >>>
> > >>> ** **
> > >>>
> > >>> Hi Edison,
> > >>>
> > >>> ** **
> > >>>
> > >>> I wanted to dive into these comments a bit more:
> > >>>
> > >>> ** **
> > >>>
> > >>> [Edison] plugin=92s driver->createasync will be called when mgt
> server
> > w=
> > > ant
> > >>> to create a volume on the storage. In the driver=92s implementation,
> > it =
> > > can
> > >>> directly call storage box=92s api, or send a command to hypervisor
> > host,=
> > > then
> > >>> call storage box=92s api to create an iscsi.
> > >>>
> > >>> Then create a datastore(for vmware), SR(for xenserver), or storage
> > >>> pool(for KVM) on hypervisor host, based on the iscsi iqn.
> > >>>
> > >>> If the volume is created from a template(for root disk), need to
> find a
> > >>> way to import that template(which is nfs based currently, it will be
> > jus=
> > > t a
> > >>> plain http url the future) into the root disk.
> > >>>
> > >>> The part about creating a datastore or a storage repository...is that
> > >>> something the plug-in will be responsible for doing or will the
> storage
> > >>> framework cover that piece?  I'm thinking the storage framework will
> > sin=
> > > ce
> > >>> all sorts of plug-ins would seem to need that ability (to have their
> > >>> storage hooked up to a datastore or a storage reposito

[QA] Test Plan for Ability to delete-Archive Alerts and Events

[Parth Jagirdar]

All,

Test Plan for Ability to delete-Archive Alerts and 
Events.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+delete-Archive+Alerts+and+Events+Test+Plan


…Parth

Re: UCS Jar

[Francois Gaudreault]

Couple other stuff, is it possible that those changes also impacted the
"Hypervisor" selection when you create a Zone? I don't see the VMWare
choice anymore, and the Public icon is gone on the physical network step.


On Tue, Mar 26, 2013 at 1:39 PM, Francois Gaudreault <
fgaudrea...@cloudops.com> wrote:

> Vijay,
>
> For now, I extended the comment in client/pom.xml to include the ucs
> module so the compile passes.  I guess that should be sufficient for me,
> but I don't know if the dependency is required for something else.
>
> Francois
>
>
> On Tue, Mar 26, 2013 at 1:12 PM, Francois Gaudreault <
> fgaudrea...@cloudops.com> wrote:
>
>> Cool! Keep us posted :)
>>
>> Thanks Vijay!
>>
>>
>> On Tue, Mar 26, 2013 at 1:09 PM, Vijayendra Bhamidipati <
>> vijayendra.bhamidip...@citrix.com> wrote:
>>
>>> Hi Francois,
>>>
>>> The UCS modules were temporarily disabled in bug CS-1773. The problem
>>> you are seeing could be caused by that - I'll take a look and get back to
>>> you at the earliest.
>>>
>>> Regards,
>>> Vijay
>>> 
>>> From: Francois Gaudreault [fgaudrea...@cloudops.com]
>>> Sent: Tuesday, March 26, 2013 8:55 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: UCS Jar
>>>
>>> Hi,
>>>
>>> Trying to build 4.1, it fails on the UCS module jar not being in the
>>> online 4.1.0 snapshot.  Where this file is located now?
>>>
>>> Downloading:
>>>
>>> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/maven-metadata.xml
>>> Downloading:
>>>
>>> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.pom
>>> [WARNING] The POM for
>>> org.apache.cloudstack:cloud-plugin-hypervisor-ucs:jar:4.1.0-SNAPSHOT is
>>> missing, no dependency information available
>>> Downloading:
>>>
>>> http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.jar
>>>
>>> Thanks!
>>>
>>> --
>>> Francois Gaudreault
>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>> fgaudrea...@cloudops.com
>>> 514-629-6775
>>> - - -
>>> CloudOps
>>> 420 rue Guy
>>> Montréal QC  H3J 1S6
>>> www.cloudops.com
>>> @CloudOps_
>>>
>>>
>>
>

Re: UCS Jar

[Francois Gaudreault]

I feel like polluting the list, we had security groups option selected, and
apparently this is only supported on KVM... that another story I believe.
 I apologize!


On Tue, Mar 26, 2013 at 3:16 PM, Francois Gaudreault <
fgaudrea...@cloudops.com> wrote:

> Couple other stuff, is it possible that those changes also impacted the
> "Hypervisor" selection when you create a Zone? I don't see the VMWare
> choice anymore, and the Public icon is gone on the physical network step.
>
>
> On Tue, Mar 26, 2013 at 1:39 PM, Francois Gaudreault <
> fgaudrea...@cloudops.com> wrote:
>
>> Vijay,
>>
>> For now, I extended the comment in client/pom.xml to include the ucs
>> module so the compile passes.  I guess that should be sufficient for me,
>> but I don't know if the dependency is required for something else.
>>
>> Francois
>>
>>
>> On Tue, Mar 26, 2013 at 1:12 PM, Francois Gaudreault <
>> fgaudrea...@cloudops.com> wrote:
>>
>>> Cool! Keep us posted :)
>>>
>>> Thanks Vijay!
>>>
>>>
>>> On Tue, Mar 26, 2013 at 1:09 PM, Vijayendra Bhamidipati <
>>> vijayendra.bhamidip...@citrix.com> wrote:
>>>
 Hi Francois,

 The UCS modules were temporarily disabled in bug CS-1773. The problem
 you are seeing could be caused by that - I'll take a look and get back to
 you at the earliest.

 Regards,
 Vijay
 
 From: Francois Gaudreault [fgaudrea...@cloudops.com]
 Sent: Tuesday, March 26, 2013 8:55 AM
 To: dev@cloudstack.apache.org
 Subject: UCS Jar

 Hi,

 Trying to build 4.1, it fails on the UCS module jar not being in the
 online 4.1.0 snapshot.  Where this file is located now?

 Downloading:

 http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/maven-metadata.xml
 Downloading:

 http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.pom
 [WARNING] The POM for
 org.apache.cloudstack:cloud-plugin-hypervisor-ucs:jar:4.1.0-SNAPSHOT is
 missing, no dependency information available
 Downloading:

 http://repository.apache.org/snapshots/org/apache/cloudstack/cloud-plugin-hypervisor-ucs/4.1.0-SNAPSHOT/cloud-plugin-hypervisor-ucs-4.1.0-SNAPSHOT.jar

 Thanks!

 --
 Francois Gaudreault
 Architecte de Solution Cloud | Cloud Solutions Architect
 fgaudrea...@cloudops.com
 514-629-6775
 - - -
 CloudOps
 420 rue Guy
 Montréal QC  H3J 1S6
 www.cloudops.com
 @CloudOps_


>>>
>>
>

Re: Storage Subsystem 2.0 plugin docs

[Mike Tutkowski]

Thanks for that bug link, Jessica.

I went ahead and added a comment with content drawn from this e-mail thread.

I believe we'll have to wait for Edison to get back to us to see when the
feature will be documented (at the moment, Vladimir and I are both
interested in creating plug-ins, but will not more info to do so).  Also,
we have (as you can see in this thread) a pending question related to what
the framework should do versus what the storage plug-ins should do.

Thanks again!


On Tue, Mar 26, 2013 at 12:58 PM, Jessica Tomechak <
jessica.tomec...@gmail.com> wrote:

> There is a bug filed to track documentation for this feature. It's
> currently unassigned. Looks like a lot of good information is going past in
> this email thread. Please consider this a friendly invitation to pull any
> useful conclusions and use cases out of here and put them in the doc bug
> comments, or update the FS, or create a wiki page and link to it from the
> doc bug, so that the info is easy to find for whoever ends up fixing the
> bug.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-885
>
> Thanks,
> Jessica T.
>
> On Mon, Mar 25, 2013 at 10:10 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Exactly, John ... All of what you said, plus - for example - it really
> puts
> > the onus on the plug-in developer to update the plug in whenever we add
> > support for a new hypervisor (say, HyperV).
> >
> > I'm happy to help out with this effort to extract hypervisor knowledge
> away
> > from these plug-ins, so - if we go this route - please feel free to bring
> > me in.
> >
> > Let's see what Edison thinks.
> >
> >
> > On Mon, Mar 25, 2013 at 11:02 PM, John Burwell 
> wrote:
> >
> > > Mike,
> > >
> > > +1 .. If storage plugins have to understand each hypervisor, the
> > > support matrix becomes unmaintainably complex.  We have a variety of
> > > abstractions commonly understood by hypervisors (e.g. LUNs, I/O
> > > streams, sockets, files, etc) that a storage can either be yielded or
> > > manipulated by a storage plugin that it is possible to decouple
> > > hypervisors and storage entities.
> > >
> > > Thanks,
> > > -John
> > >
> > >
> > >
> > >
> > > On Mar 25, 2013, at 5:37 PM, Mike Tutkowski
> > >  wrote:
> > >
> > > > Hey Edison,
> > > >
> > > > So...if you think my understanding is correct (please check out the
> > > e-mail
> > > > below), then I have a question.
> > > >
> > > > Do we really want to have the storage plug-ins taking on the
> > > responsibility
> > > > of talking to the hypervisors to hook up the storage that they just
> > > created=
> > > > ?
> > > >
> > > > I'm a bit familiar with how OpenStack does this and it seems that it
> > only
> > > > has its storage plug-ins create a volume (LUN, whatever) and then the
> > > > framework handles the process of dealing with the hypervisor in
> > question
> > > to
> > > > hook up the storage.
> > > >
> > > > It seems like otherwise we'd need to create a utility for all storage
> > > > plug-ins to share otherwise they'd be duplicating efforts in talking
> to
> > > > hypervisors.
> > > >
> > > > What do you think?
> > > >
> > > >
> > > > On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski <
> > > > mike.tutkow...@solidfire.com> wrote:
> > > >
> > > >> Hi Edison,
> > > >>
> > > >> I believe I understand the requirements for the plug-in better now.
> > > >>
> > > >> It sounds like the flow will be as such:
> > > >>
> > > >> * The user executes a Compute or Disk Offering that is tied via a
> > > storage
> > > >> tag to a Primary Storage that is associated with a plug-in.
> > > >>
> > > >> * The storage framework will ask the plug-in to create a volume.
>  The
> > > >> plug-in will create a volume and hook the volume up to the
> appropriate
> > > >> hypervisor.  For VMware, this means the plug-in will create a
> > Datastore.
> > > >> For XenServer, this means the plug-in will create a Storage
> > Repository.
> > > >> (So on and so forth for other hypervisors.)
> > > >>
> > > >> * The VM or data disk is then deployed to the hypervisor.
> > > >>
> > > >> Does that sound correct, Edison?
> > > >>
> > > >> Thanks!
> > > >>
> > > >>
> > > >> On Thu, Mar 21, 2013 at 5:44 PM, Edison Su 
> > > wrote:
> > > >>
> > > >>> ** **
> > > >>>
> > > >>> ** **
> > > >>>
> > > >>> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > >>> *Sent:* Thursday, March 21, 2013 4:18 PM
> > > >>> *To:* Edison Su
> > > >>> *Subject:* Re: Storage Subsystem 2.0 plugin docs
> > > >>>
> > > >>> ** **
> > > >>>
> > > >>> Hi Edison,
> > > >>>
> > > >>> ** **
> > > >>>
> > > >>> I wanted to dive into these comments a bit more:
> > > >>>
> > > >>> ** **
> > > >>>
> > > >>> [Edison] plugin=92s driver->createasync will be called when mgt
> > server
> > > w=
> > > > ant
> > > >>> to create a volume on the storage. In the driver=92s
> implementation,
> > > it =
> > > > can
> > > >>> directly call storage box=92s api, or send a command to hypervisor
> > > host,=
> > > > then
>

Re: Review Request: Make SHA256Salt the default password encoding and authentication mechanism for cloudstack

[Jessica Tomechak]

Vijay,
I have opened that Doc bug for you, and added you to the bug as a Watcher.

https://issues.apache.org/jira/browse/CLOUDSTACK-1815

Jessica T.

On Thu, Mar 21, 2013 at 1:27 AM, Vijayendra Bhamidipati <
vijayendra.bhamidip...@citrix.com> wrote:

> Hi Prasanna,
>
> True, as of now the mechanism isn't configurable via the UI. The rationale
> was that the encoding and authentication choices are seldom changed once
> put in place, and that it would be better to not expose this as a
> configurable option via the UI. The list properties introduced must be
> documented as part of a doc bug associated with this change - I'll log one
> for this on jira if it isn't already there, we should have it documented in
> the admin guide.
>
> Earlier the client was required to md5 hash the password and send it over
> in applicable API calls, but since this was recently changed so that the
> client is now expected to pass the clear text password (which would be best
> passed using https and thus leveraging the encryption mechanism that the
> SSL handshake chooses, to protect against on the wire snooping), a cipher
> needn't be applied anymore on the client side, so it doesn't need to know
> about an encoding mechanism or ordering. The api signing process will stay
> the same since the signature generated would basically be determined by the
> supplied secret/api key pair as long as the other parameters stay the
> same.. the signing is independent of this change..
>
> I didn't put in an API call to list the authenticators'/encoders' current
> ordering given the above situation.. any idea of other uses of having APIs
> to retrieve these two lists?? I can put them in if they'll be useful..
>
> If adding a new adapter, these would be a few tests to carry out:
>
> 1. Keep the lists as is, and verify that encoding/authentication work as
> expected.
> 2. Add the new bean id of the new adapter to the lists.
> 3. Make the new bean id the first in the encoder list, restart the mgmt
> server, add a user, and verify by select password from cloud.user; for that
> user, that the password was generated using this new encoding adapter.
> 4. Next, if the same class implements both the encoder and authenticator,
> put the same bean id anywhere in the authenticator list, and if a different
> class implements the authenticator, put that new bean id in the
> authenticator list, and restart the mgmt server. A login of the new user
> should succeed eventually when it gets authenticated by the new adapter.
> 5. Next, remove the bean from the authenticator list, restart the mgmt
> server, and retry the user login, and it should fail.
>
> Regards,
> Vijay
>
> 
> From: srivatsav.prasa...@gmail.com [srivatsav.prasa...@gmail.com] On
> Behalf Of prasanna [t...@apache.org]
> Sent: Wednesday, March 20, 2013 10:09 PM
> To: cloudstack-...@incubator.apache.org
> Subject: Re: Review Request: Make SHA256Salt the default password encoding
> and authentication mechanism for cloudstack
>
> On 20 March 2013 23:56, Vijayendra Bhamidipati
>  wrote:
> > Hi Chip, Prasanna,
> >
> > Yes, the change is pretty straightforward, the reasoning is to make
> default password encoding more secure because the SHA256salted
> authenticator recently added by Hugo salts the passwords while the existing
> MD5 authenticator doesn't, and is the default. This change gives the CS
> admin the flexibility to choose the ordering of the
> encoders/authenticators. No new authenticator/encoder classes needed to be
> added, the existing ones are simply used better.
> >
> > Upgrade scenarios were considered and these changes will have no effect
> on upgrades. Only new users and updated users will have their passwords
> encoded by the first valid encoder in the UserPasswordEncoder list.
> Existing users will still get authenticated as before since authentication
> passes through all the authenticators available in the UserAuthenticator
> list until one of them succeeds or all fail.
> >
>
> Thanks Vijay, I'm just wondering how does someone not dealing with the
> UI know the auth mechanism to use? When login happens, when account
> creation happens, or when api signing happens (unaffected?)? Is there
> an API call that lists the authenticators in use on the deployment? So
> the appropriate cipher can be applied at client side?
>
> Also - could you list out a few tests that can be taken up to ensure
> the feature is smoke tested. By that I mean - tests that will ensure
> this feature isn't broken say when a new authenticator is used. I'm
> looking to put them down as marvin tests.
>

RE: Storage Subsystem 2.0 plugin docs

[Edison Su]

Yes, code is welcome!!! Currently Only the interface at the management server 
side is defined. At the hypervisor resource side, we may need some kind of 
utility library or another plugin framework, as John proposed few months ago.

From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Monday, March 25, 2013 2:37 PM
To: Edison Su; cloudstack-...@incubator.apache.org; Vladimir Popovski
Subject: Re: Storage Subsystem 2.0 plugin docs

Hey Edison,

So...if you think my understanding is correct (please check out the e-mail 
below), then I have a question.

Do we really want to have the storage plug-ins taking on the responsibility of 
talking to the hypervisors to hook up the storage that they just created?

I'm a bit familiar with how OpenStack does this and it seems that it only has 
its storage plug-ins create a volume (LUN, whatever) and then the framework 
handles the process of dealing with the hypervisor in question to hook up the 
storage.

It seems like otherwise we'd need to create a utility for all storage plug-ins 
to share otherwise they'd be duplicating efforts in talking to hypervisors.

What do you think?

On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>> wrote:
Hi Edison,

I believe I understand the requirements for the plug-in better now.

It sounds like the flow will be as such:

* The user executes a Compute or Disk Offering that is tied via a storage tag 
to a Primary Storage that is associated with a plug-in.

* The storage framework will ask the plug-in to create a volume.  The plug-in 
will create a volume and hook the volume up to the appropriate hypervisor.  For 
VMware, this means the plug-in will create a Datastore.  For XenServer, this 
means the plug-in will create a Storage Repository.  (So on and so forth for 
other hypervisors.)

* The VM or data disk is then deployed to the hypervisor.

Does that sound correct, Edison?

Thanks!

On Thu, Mar 21, 2013 at 5:44 PM, Edison Su 
mailto:edison...@citrix.com>> wrote:


From: Mike Tutkowski 
[mailto:mike.tutkow...@solidfire.com]
Sent: Thursday, March 21, 2013 4:18 PM
To: Edison Su
Subject: Re: Storage Subsystem 2.0 plugin docs

Hi Edison,

I wanted to dive into these comments a bit more:


[Edison] plugin's driver->createasync will be called when mgt server want to 
create a volume on the storage. In the driver's implementation, it can directly 
call storage box's api, or send a command to hypervisor host, then call storage 
box's api to create an iscsi.

Then create a datastore(for vmware), SR(for xenserver), or storage pool(for 
KVM) on hypervisor host, based on the iscsi iqn.

If the volume is created from a template(for root disk), need to find a way to 
import that template(which is nfs based currently, it will be just a plain http 
url the future) into the root disk.
The part about creating a datastore or a storage repository...is that something 
the plug-in will be responsible for doing or will the storage framework cover 
that piece?  I'm thinking the storage framework will since all sorts of 
plug-ins would seem to need that ability (to have their storage hooked up to a 
datastore or a storage repository).

[Edison] It's a specific requirement for per volume per LUN case, and specific 
for certain hypervisors(seems KVM doesn't need to create a storage pool when 
using iscsi LUN), so the storage framework will not deal with it right now.


Thanks for your time, Edison! :)

On Thu, Mar 21, 2013 at 4:45 PM, Edison Su 
mailto:edison...@citrix.com>> wrote:
Feedback/comments are appreciated, need to know your input from storage vendor 
point of view.

From: Vladimir Popovski 
[mailto:vladi...@zadarastorage.com]
Sent: Thursday, March 21, 2013 11:52 AM
To: Edison Su; cloudstack

Cc: mike.tutkow...@solidfire.com
Subject: RE: Storage Subsystem 2.0 plugin docs

Hi Edison,

Thank you for the reply. We will check it out.

Regards,
-Vladimir


From: Edison Su [mailto:edison...@citrix.com]
Sent: Thursday, March 21, 2013 11:36 AM
To: 'Vladimir Popovski'; cloudstack
Cc: mike.tutkow...@solidfire.com
Subject: RE: Storage Subsystem 2.0 plugin docs



From: Vladimir Popovski [mailto:vladi...@zadarastorage.com]
Sent: Wednesday, March 20, 2013 9:05 AM
To: cloudstack
Cc: mike.tutkow...@solidfire.com; Edison Su
Subject: Storage Subsystem 2.0 plugin docs

Hi All,

Thank you for a great work on CloudStack! We are interested in integrating CS 
with our storage system and started to look at your documentation and 
storage-related code. I see that Mike from SolidFire started working on 
something similar some time ago and Edison even created an empty plugin for it 
(in Nov'12?).

We have couple of questions related to that:

-  Is there any documentation about plugins (except of 
https://cwiki.

Re: Storage Subsystem 2.0 plugin docs

[Mike Tutkowski]

Hi Edison,

Sounds good.

I already have code to create a XenServer Storage Repository (and
optionally use CHAP credentials) and I'm working right now on creating a
vSphere Datastore.

When I have this working and in a nicer state, I can check in with you to
review it and provide comments.

Once those two hypervisors are handled, I'll move on to KVM and OVM.

Thanks!


On Tue, Mar 26, 2013 at 2:33 PM, Edison Su  wrote:

> Yes, code is welcome!!! Currently Only the interface at the management
> server side is defined. At the hypervisor resource side, we may need some
> kind of utility library or another plugin framework, as John proposed few
> months ago.
>
> ** **
>
> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> *Sent:* Monday, March 25, 2013 2:37 PM
> *To:* Edison Su; cloudstack-...@incubator.apache.org; Vladimir Popovski
>
> *Subject:* Re: Storage Subsystem 2.0 plugin docs
>
> ** **
>
> Hey Edison,
>
> ** **
>
> So...if you think my understanding is correct (please check out the e-mail
> below), then I have a question.
>
> ** **
>
> Do we really want to have the storage plug-ins taking on the
> responsibility of talking to the hypervisors to hook up the storage that
> they just created?
>
> ** **
>
> I'm a bit familiar with how OpenStack does this and it seems that it only
> has its storage plug-ins create a volume (LUN, whatever) and then the
> framework handles the process of dealing with the hypervisor in question to
> hook up the storage.
>
> ** **
>
> It seems like otherwise we'd need to create a utility for all storage
> plug-ins to share otherwise they'd be duplicating efforts in talking to
> hypervisors.
>
> ** **
>
> What do you think?
>
> ** **
>
> On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> Hi Edison,
>
> ** **
>
> I believe I understand the requirements for the plug-in better now.
>
> ** **
>
> It sounds like the flow will be as such:
>
> ** **
>
> * The user executes a Compute or Disk Offering that is tied via a storage
> tag to a Primary Storage that is associated with a plug-in.
>
> ** **
>
> * The storage framework will ask the plug-in to create a volume.  The
> plug-in will create a volume and hook the volume up to the appropriate
> hypervisor.  For VMware, this means the plug-in will create a Datastore.
>  For XenServer, this means the plug-in will create a Storage Repository.
>  (So on and so forth for other hypervisors.)
>
> ** **
>
> * The VM or data disk is then deployed to the hypervisor.
>
> ** **
>
> Does that sound correct, Edison?
>
> ** **
>
> Thanks!
>
> ** **
>
> On Thu, Mar 21, 2013 at 5:44 PM, Edison Su  wrote:**
> **
>
>  
>
>  
>
> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> *Sent:* Thursday, March 21, 2013 4:18 PM
> *To:* Edison Su
> *Subject:* Re: Storage Subsystem 2.0 plugin docs
>
>  
>
> Hi Edison,
>
>  
>
> I wanted to dive into these comments a bit more:
>
>  
>
> [Edison] plugin’s driver->createasync will be called when mgt server want
> to create a volume on the storage. In the driver’s implementation, it can
> directly call storage box’s api, or send a command to hypervisor host, then
> call storage box’s api to create an iscsi.
>
> Then create a datastore(for vmware), SR(for xenserver), or storage
> pool(for KVM) on hypervisor host, based on the iscsi iqn.
>
> If the volume is created from a template(for root disk), need to find a
> way to import that template(which is nfs based currently, it will be just a
> plain http url the future) into the root disk.
>
> The part about creating a datastore or a storage repository...is that
> something the plug-in will be responsible for doing or will the storage
> framework cover that piece?  I'm thinking the storage framework will since
> all sorts of plug-ins would seem to need that ability (to have their
> storage hooked up to a datastore or a storage repository).
>
>  
>
> [Edison] It’s a specific requirement for per volume per LUN case, and
> specific for certain hypervisors(seems KVM doesn’t need to create a storage
> pool when using iscsi LUN), so the storage framework will not deal with it
> right now.
>
>  
>
>  
>
> Thanks for your time, Edison! :)
>
>  
>
> On Thu, Mar 21, 2013 at 4:45 PM, Edison Su  wrote:**
> **
>
> Feedback/comments are appreciated, need to know your input from storage
> vendor point of view.
>
>  
>
> *From:* Vladimir Popovski [mailto:vladi...@zadarastorage.com]
> *Sent:* Thursday, March 21, 2013 11:52 AM
> *To:* Edison Su; cloudstack
>
>
> *Cc:* mike.tutkow...@solidfire.com
> *Subject:* RE: Storage Subsystem 2.0 plugin docs
>
>  
>
> Hi Edison,
>
>  
>
> Thank you for the reply. We will check it out.
>
>  
>
> Regards,
>
> -Vladimir
>
>  
>
>  
>
> *From:* Edison Su [mailto:edison...@citrix.com]
> *Sent:* Thursday, M

Re: Storage Subsystem 2.0 plugin docs

[Mike Tutkowski]

Oh, just to be clear, what I'm working on specifically is code to enable
each of the hypervisors we support to make use of an iSCSI target.  For
example, creating an iSCSI-based SR for XenServer, an iSCSI-based DS for
VMware, etc.

Once this code is ready, I can ask Edison to review it.  We can then decide
if we want to place it in a (possibly new) utility class used by the
plug-ins or if it should become part of the framework.

Once I complete writing code to create a new DS for VMware, we should look
into where we want to place this VMware and XenServer logic so that plug-in
developers (including myself :) ) can start writing our plug-ins, too.


On Tue, Mar 26, 2013 at 2:51 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi Edison,
>
> Sounds good.
>
> I already have code to create a XenServer Storage Repository (and
> optionally use CHAP credentials) and I'm working right now on creating a
> vSphere Datastore.
>
> When I have this working and in a nicer state, I can check in with you to
> review it and provide comments.
>
> Once those two hypervisors are handled, I'll move on to KVM and OVM.
>
> Thanks!
>
>
> On Tue, Mar 26, 2013 at 2:33 PM, Edison Su  wrote:
>
>> Yes, code is welcome!!! Currently Only the interface at the management
>> server side is defined. At the hypervisor resource side, we may need some
>> kind of utility library or another plugin framework, as John proposed few
>> months ago.
>>
>> ** **
>>
>> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> *Sent:* Monday, March 25, 2013 2:37 PM
>> *To:* Edison Su; cloudstack-...@incubator.apache.org; Vladimir Popovski
>>
>> *Subject:* Re: Storage Subsystem 2.0 plugin docs
>>
>> ** **
>>
>> Hey Edison,
>>
>> ** **
>>
>> So...if you think my understanding is correct (please check out the
>> e-mail below), then I have a question.
>>
>> ** **
>>
>> Do we really want to have the storage plug-ins taking on the
>> responsibility of talking to the hypervisors to hook up the storage that
>> they just created?
>>
>> ** **
>>
>> I'm a bit familiar with how OpenStack does this and it seems that it only
>> has its storage plug-ins create a volume (LUN, whatever) and then the
>> framework handles the process of dealing with the hypervisor in question to
>> hook up the storage.
>>
>> ** **
>>
>> It seems like otherwise we'd need to create a utility for all storage
>> plug-ins to share otherwise they'd be duplicating efforts in talking to
>> hypervisors.
>>
>> ** **
>>
>> What do you think?
>>
>> ** **
>>
>> On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> Hi Edison,
>>
>> ** **
>>
>> I believe I understand the requirements for the plug-in better now.
>>
>> ** **
>>
>> It sounds like the flow will be as such:
>>
>> ** **
>>
>> * The user executes a Compute or Disk Offering that is tied via a storage
>> tag to a Primary Storage that is associated with a plug-in.
>>
>> ** **
>>
>> * The storage framework will ask the plug-in to create a volume.  The
>> plug-in will create a volume and hook the volume up to the appropriate
>> hypervisor.  For VMware, this means the plug-in will create a Datastore.
>>  For XenServer, this means the plug-in will create a Storage Repository.
>>  (So on and so forth for other hypervisors.)
>>
>> ** **
>>
>> * The VM or data disk is then deployed to the hypervisor.
>>
>> ** **
>>
>> Does that sound correct, Edison?
>>
>> ** **
>>
>> Thanks!
>>
>> ** **
>>
>> On Thu, Mar 21, 2013 at 5:44 PM, Edison Su  wrote:*
>> ***
>>
>>  
>>
>>  
>>
>> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> *Sent:* Thursday, March 21, 2013 4:18 PM
>> *To:* Edison Su
>> *Subject:* Re: Storage Subsystem 2.0 plugin docs
>>
>>  
>>
>> Hi Edison,
>>
>>  
>>
>> I wanted to dive into these comments a bit more:
>>
>>  
>>
>> [Edison] plugin’s driver->createasync will be called when mgt server want
>> to create a volume on the storage. In the driver’s implementation, it can
>> directly call storage box’s api, or send a command to hypervisor host, then
>> call storage box’s api to create an iscsi.
>>
>> Then create a datastore(for vmware), SR(for xenserver), or storage
>> pool(for KVM) on hypervisor host, based on the iscsi iqn.
>>
>> If the volume is created from a template(for root disk), need to find a
>> way to import that template(which is nfs based currently, it will be just a
>> plain http url the future) into the root disk.
>>
>> The part about creating a datastore or a storage repository...is that
>> something the plug-in will be responsible for doing or will the storage
>> framework cover that piece?  I'm thinking the storage framework will since
>> all sorts of plug-ins would seem to need that ability (to have their
>> storage hooked up to a datastore or a storage repository).
>>
>>  
>>
>> [Edison] It’s a specific requirement for per volume per LU

Re: Review Request: CLOUDSTACK-922: LXC Support in Cloudstack

[Phong Nguyen]

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

(Updated March 26, 2013, 9:02 p.m.)


Review request for cloudstack, akarasulu and edison su.


Changes
---

Additional changes:

- root filesystem xml for Libvirt has been moved to createVbd()
- added LibvirtConnection.getConnectionByVmName6
- changed relevant calls to getConnection() to use getConnectionByVmName()
- calls to getConnection() for pool/storeage related information is not 
affected by connection url

Testing:

- wiped and rebuilt a clean installation with KVM system vms and LXC container


Description
---

This is a patch for adding LXC support to Cloudstack.

Please see the following links for more details:

Design doc: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Support+in+Cloudstack
Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-922


Diffs (updated)
-

  agent/conf/agent.properties f7eac67 
  api/src/com/cloud/agent/api/Command.java 9cd6749 
  api/src/com/cloud/agent/api/RebootCommand.java 299e61b 
  api/src/com/cloud/agent/api/StopCommand.java 9ee7ce3 
  api/src/com/cloud/hypervisor/Hypervisor.java 2e0012d 
  api/src/com/cloud/storage/Storage.java fba12b6 
  client/tomcatconf/componentContext.xml.in a98a41f 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/DirectVifDriver.java
 PRE-CREATION 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 8ee3ea4 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtConnection.java
 981d343 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtDomainXMLParser.java
 b622b6d 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtStorageVolumeDef.java
 d5cd91a 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java 
c93aeeb 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMPhysicalDisk.java
 08f51a4 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java
 c2bfad9 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
 d5e6ad6 
  
plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtVMDefTest.java
 b723875 
  scripts/storage/secondary/cloud-install-sys-tmplt 2172b28 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 544a803 
  server/src/com/cloud/hypervisor/LXCGuru.java PRE-CREATION 
  server/src/com/cloud/hypervisor/kvm/discoverer/KvmServerDiscoverer.java 
75e00ad 
  server/src/com/cloud/hypervisor/kvm/discoverer/LibvirtServerDiscoverer.java 
PRE-CREATION 
  server/src/com/cloud/hypervisor/kvm/discoverer/LxcServerDiscoverer.java 
PRE-CREATION 
  server/src/com/cloud/network/SshKeysDistriMonitor.java fc7c882 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
6742f7b 
  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
46ac7af 
  server/src/com/cloud/template/HypervisorTemplateAdapter.java 1426421 
  server/src/com/cloud/vm/VirtualMachineManagerImpl.java 0aeef0e 
  setup/db/db/schema-410to420.sql eb650cc 
  ui/scripts/system.js c0a5d14 
  ui/scripts/templates.js 040ce4a 
  ui/scripts/zoneWizard.js 5108c5c 

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


Testing
---

Performed end-to-end testing for starting an LXC instance:

- Add an LXC cluster
- Add an LXC host
- Register an LXC template
- Spin up an LXC container

Additional testing:

- Verified connectivity with direct network settings
- Used KVM systemvm with LXC cluster


Thanks,

Phong Nguyen

Re: [ACS41] Bugs blocking our 4.1 release

[Chip Childers]

On Tue, Mar 26, 2013 at 2:32 PM, Sheng Yang  wrote:
> CLOUDSTACK-1755 IPv6 - When Vm is part of Dual network ,
> /etc/reslov.conf does not have ipv6 router ipaddress and ipv6 external
> dns.
>
> This bug's fix version is 4.2...
>
> --Sheng

Just to be clear...  you are saying that it's not going to be fixed
for 4.1?  That's OK with me, as the IPv6 feature is experimental in
4.1.  I just want to understand what you are saying.

-chip

Re: [PROPOSAL] QuickCloud

[David Nalley]

On Mon, Mar 25, 2013 at 2:54 AM, Chiradeep Vittal
 wrote:
> To enable a cloud to start quicker, I am proposing that system vms be made 
> optional in the boot-up of a CloudStack Cloud.
> I'm working on the 'quickcloud' branch and the detailed proposal is here:
> https://cwiki.apache.org/confluence/x/clnVAQ
>


Theoretically this should make it easier to break out the 'services'
from the debian-based systemvm, right?
We get closer to being able to run the systemvm services anywhere
(such as Fedora, CEntOS, *BSD etc)


--David

Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[David Nalley]

On Tue, Mar 26, 2013 at 12:31 PM, Alex Huang  wrote:
>> 1.   Does dependence on the Microsoft compiler mean that the source end
>> up in the non-OSS build?
>
> I don't think so.

No it doesn't.

>
>>
>> 2.   Is the plugin able to participate in the BVT?
>>
> BVT must be able to accommodate this.  We need to figure out a way for the 
> build system to accommodate for this as well.  Can you get in touch with 
> Pradeep (build) and Prasanna (bvt) on this?
>
> --Alex


Since this is pretty radically different work (different tools,
platform) do we want to make the C# a different repo/ git submodule?

--David

[ACS402] CLOUDSTACK-1638 and patch?

[Joe Brockmeier]

Hi - would you please take a few minutes to address Chiradeep's comments
on the patch for CLOUDSTACK-1638?

If we can get that patch in shape, I'd really like to include this patch
in 4.0.2.

See: https://reviews.apache.org/r/9871/

Thanks!

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Review Request: Add docs for MidoNet networking plugin [CLOUDSTACK-996]

[David Nalley]

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



docs/en-US/MidoNet_Plugin_Guide.ent


Shouldn't this be 2013?



docs/en-US/plugin-midonet-revisions.xml


4.2.0 will not have the -incubating tag


- David Nalley


On March 26, 2013, 9:32 a.m., Dave Cahill wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10136/
> ---
> 
> (Updated March 26, 2013, 9:32 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> Adding docs for MidoNet networking plugin [CLOUDSTACK-996]
> 
> Plugin itself is awaiting review / commit here:
> [PATCH 1] https://reviews.apache.org/r/9897/
> [PATCH 2] https://reviews.apache.org/r/9898/
> 
> 
> This addresses bug CLOUDSTACK-996.
> 
> 
> Diffs
> -
> 
>   docs/en-US/MidoNet_Plugin_Guide.ent PRE-CREATION 
>   docs/en-US/MidoNet_Plugin_Guide.xml PRE-CREATION 
>   docs/en-US/plugin-midonet-about.xml PRE-CREATION 
>   docs/en-US/plugin-midonet-features.xml PRE-CREATION 
>   docs/en-US/plugin-midonet-introduction.xml PRE-CREATION 
>   docs/en-US/plugin-midonet-preparations.xml PRE-CREATION 
>   docs/en-US/plugin-midonet-provider.xml PRE-CREATION 
>   docs/en-US/plugin-midonet-revisions.xml PRE-CREATION 
>   docs/en-US/plugin-midonet-ui.xml PRE-CREATION 
>   docs/en-US/plugin-midonet-usage.xml PRE-CREATION 
>   docs/publican-plugin-midonet.cfg PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/10136/diff/
> 
> 
> Testing
> ---
> 
> Built docs.
> 
> 
> Thanks,
> 
> Dave Cahill
> 
>

Re: [ACS41] Bugs blocking our 4.1 release

[David Nalley]

On Tue, Mar 26, 2013 at 5:08 PM, Chip Childers
 wrote:
> On Tue, Mar 26, 2013 at 2:32 PM, Sheng Yang  wrote:
>> CLOUDSTACK-1755 IPv6 - When Vm is part of Dual network ,
>> /etc/reslov.conf does not have ipv6 router ipaddress and ipv6 external
>> dns.
>>
>> This bug's fix version is 4.2...
>>
>> --Sheng
>
> Just to be clear...  you are saying that it's not going to be fixed
> for 4.1?  That's OK with me, as the IPv6 feature is experimental in
> 4.1.  I just want to understand what you are saying.
>
> -chip

If it's already fixed in master, why would we not fix it in 4.1?
(There are plenty of valid reasons for us to not do so, but I haven't
heard anyone suggest them, so curious)

--David

RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Alex Huang]

> 
> Since this is pretty radically different work (different tools,
> platform) do we want to make the C# a different repo/ git submodule?

The controller portion should go inside the plugin portion of CloudStack.  The 
hypervisor part (ServerResource) should go on a separate repo.  Just look at 
the hypervisor part as equivalent to WMI on HyperV.  

--Alex

Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[David Nalley]

On Tue, Mar 26, 2013 at 6:23 PM, Alex Huang  wrote:
>>
>> Since this is pretty radically different work (different tools,
>> platform) do we want to make the C# a different repo/ git submodule?
>
> The controller portion should go inside the plugin portion of CloudStack.  
> The hypervisor part (ServerResource) should go on a separate repo.  Just look 
> at the hypervisor part as equivalent to WMI on HyperV.
>
> --Alex

Makes sense to me.

--David

Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Sebastien Goasguen]

On Mar 26, 2013, at 6:23 PM, Alex Huang  wrote:

>> 
>> Since this is pretty radically different work (different tools,
>> platform) do we want to make the C# a different repo/ git submodule?
> 
> The controller portion should go inside the plugin portion of CloudStack.  
> The hypervisor part (ServerResource) should go on a separate repo.  Just look 
> at the hypervisor part as equivalent to WMI on HyperV.  
> 
> --Alex
and the C# part is for the ServerResource, right ?

I won't code this, but it would be nice to minimize languages used in 
CloudStack and try to be consistent across hypervisors (as much as possible). 
Introducing another language and some framework that may or may not have 
proprietary modules/dependencies will certainly complicate the build and the 
testing, and maybe even the licensing.

-sebastien

Re: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[David Nalley]

On Tue, Mar 26, 2013 at 6:40 PM, Sebastien Goasguen  wrote:
>
> On Mar 26, 2013, at 6:23 PM, Alex Huang  wrote:
>
>>>
>>> Since this is pretty radically different work (different tools,
>>> platform) do we want to make the C# a different repo/ git submodule?
>>
>> The controller portion should go inside the plugin portion of CloudStack.  
>> The hypervisor part (ServerResource) should go on a separate repo.  Just 
>> look at the hypervisor part as equivalent to WMI on HyperV.
>>
>> --Alex
> and the C# part is for the ServerResource, right ?
>
> I won't code this, but it would be nice to minimize languages used in 
> CloudStack and try to be consistent across hypervisors (as much as possible). 
> Introducing another language and some framework that may or may not have 
> proprietary modules/dependencies will certainly complicate the build and the 
> testing, and maybe even the licensing.
>
> -sebastien

I tend to agree with this. But as you noted, I am not coding this.
If Java is really impossible/impractical then we'll just have to do
our due diligence as we progress.

--David

Re: [ACS41] Bugs blocking our 4.1 release

[Kelven Yang]

>CLOUDSTACK-1664 Action Events are not logged due to spring changes
>Kelven Yang
>CLOUDSTACK-1673 AWS Regions - Events - User disable event does not
>include the UUID of the user that was disabled.  Murali Reddy

I've made the fix ready for the above two in my local repo(I also tested
on OSS and nonOSS). However, I found another blocker bug in 4.0->4.1
upgrade process. Once I got this issue fixed, will submit the patches.

Kelven



On 3/25/13 1:15 PM, "Chip Childers"  wrote:

>Hi all,
>
>The following bugs need to be either (1) resolved or (2) triaged as not
>being as high a priority as they are now before I cut the RC.  Can folks
>take a moment to review and update / fix accordingly please?
>
>CLOUDSTACK-1694 Issues to start/access Management Server after upgrade
>from 4.0 to 4.1  Pradeep Soundararajan
>CLOUDSTACK-1719 EC2 REST API: AWS APIs are not getting translated on the
>CloudStack Management Server   Pradeep Soundararajan
>CLOUDSTACK-1772 the change in vnc listening port will cause live
>migration doesn't work edison us
>CLOUDSTACK-1795 Customize AOP to fully support legacy CloudStack @DB and
>@ActionEvent semantics Kelven Yang
>CLOUDSTACK-1664 Action Events are not logged due to spring changes
>Kelven Yang
>CLOUDSTACK-1673 AWS Regions - Events - User disable event does not
>include the UUID of the user that was disabled.  Murali Reddy
>CLOUDSTACK-1740 Failed to view console  Rajesh Battala
>CLOUDSTACK-1755 IPv6 - When Vm is part of Dual network , /etc/reslov.conf
>does not have ipv6 router ipaddress and ipv6 external dns.Sheng Yang
>CLOUDSTACK-1789 Unable to download templates to Primary Storage if a host
>is in maintenance edison su
>CLOUDSTACK-1802 Upgrade 4.0 -> 4.1 - Not able to strat management server
>becasue of missing /etc/cloudstack/management/tomcat6.conf file.
>Pradeep Soundararajan
>
>
>I'd also like us to resolve
>https://issues.apache.org/jira/browse/CLOUDSTACK-1796 - which is a
>Japanese docs building issue.  Sebastien, can you please review the
>latest from Transifex (per latest comment from Hiroaki)?
>
>-chip

RE: Storage Subsystem 2.0 plugin docs

[Edison Su]

Thanks!
FYI, there are some code at both xen and kvm hypervisor resource code to deal 
with storage pool creation.
For example, in CitrixResourceBase-> getNfsSR or getIscsiSR to create a nfs SR 
or ISCSI SR. In LibvirtStorageAdaptor, which can create storage pool in libvirt.


From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Tuesday, March 26, 2013 1:52 PM
To: Edison Su
Cc: cloudstack-...@incubator.apache.org; Vladimir Popovski
Subject: Re: Storage Subsystem 2.0 plugin docs

Hi Edison,

Sounds good.

I already have code to create a XenServer Storage Repository (and optionally 
use CHAP credentials) and I'm working right now on creating a vSphere Datastore.

When I have this working and in a nicer state, I can check in with you to 
review it and provide comments.

Once those two hypervisors are handled, I'll move on to KVM and OVM.

Thanks!

On Tue, Mar 26, 2013 at 2:33 PM, Edison Su 
mailto:edison...@citrix.com>> wrote:
Yes, code is welcome!!! Currently Only the interface at the management server 
side is defined. At the hypervisor resource side, we may need some kind of 
utility library or another plugin framework, as John proposed few months ago.

From: Mike Tutkowski 
[mailto:mike.tutkow...@solidfire.com]
Sent: Monday, March 25, 2013 2:37 PM
To: Edison Su; 
cloudstack-...@incubator.apache.org;
 Vladimir Popovski

Subject: Re: Storage Subsystem 2.0 plugin docs

Hey Edison,

So...if you think my understanding is correct (please check out the e-mail 
below), then I have a question.

Do we really want to have the storage plug-ins taking on the responsibility of 
talking to the hypervisors to hook up the storage that they just created?

I'm a bit familiar with how OpenStack does this and it seems that it only has 
its storage plug-ins create a volume (LUN, whatever) and then the framework 
handles the process of dealing with the hypervisor in question to hook up the 
storage.

It seems like otherwise we'd need to create a utility for all storage plug-ins 
to share otherwise they'd be duplicating efforts in talking to hypervisors.

What do you think?

On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski 
mailto:mike.tutkow...@solidfire.com>> wrote:
Hi Edison,

I believe I understand the requirements for the plug-in better now.

It sounds like the flow will be as such:

* The user executes a Compute or Disk Offering that is tied via a storage tag 
to a Primary Storage that is associated with a plug-in.

* The storage framework will ask the plug-in to create a volume.  The plug-in 
will create a volume and hook the volume up to the appropriate hypervisor.  For 
VMware, this means the plug-in will create a Datastore.  For XenServer, this 
means the plug-in will create a Storage Repository.  (So on and so forth for 
other hypervisors.)

* The VM or data disk is then deployed to the hypervisor.

Does that sound correct, Edison?

Thanks!

On Thu, Mar 21, 2013 at 5:44 PM, Edison Su 
mailto:edison...@citrix.com>> wrote:


From: Mike Tutkowski 
[mailto:mike.tutkow...@solidfire.com]
Sent: Thursday, March 21, 2013 4:18 PM
To: Edison Su
Subject: Re: Storage Subsystem 2.0 plugin docs

Hi Edison,

I wanted to dive into these comments a bit more:


[Edison] plugin's driver->createasync will be called when mgt server want to 
create a volume on the storage. In the driver's implementation, it can directly 
call storage box's api, or send a command to hypervisor host, then call storage 
box's api to create an iscsi.

Then create a datastore(for vmware), SR(for xenserver), or storage pool(for 
KVM) on hypervisor host, based on the iscsi iqn.

If the volume is created from a template(for root disk), need to find a way to 
import that template(which is nfs based currently, it will be just a plain http 
url the future) into the root disk.
The part about creating a datastore or a storage repository...is that something 
the plug-in will be responsible for doing or will the storage framework cover 
that piece?  I'm thinking the storage framework will since all sorts of 
plug-ins would seem to need that ability (to have their storage hooked up to a 
datastore or a storage repository).

[Edison] It's a specific requirement for per volume per LUN case, and specific 
for certain hypervisors(seems KVM doesn't need to create a storage pool when 
using iscsi LUN), so the storage framework will not deal with it right now.


Thanks for your time, Edison! :)

On Thu, Mar 21, 2013 at 4:45 PM, Edison Su 
mailto:edison...@citrix.com>> wrote:
Feedback/comments are appreciated, need to know your input from storage vendor 
point of view.

From: Vladimir Popovski 
[mailto:vladi...@zadarastorage.com]
Sent: Thursday, March 21, 2013 11:52 AM
To: Edison Su; cloudstack

Cc: mike.tutkow...@solidfire.com
Subject: RE: Storage Subsystem 2.0 plugin docs

Hi Ediso

RE: [DISCUSS] Hyper-V Plugin & Microsoft Compiler & IP Clearance

[Alex Huang]

> and the C# part is for the ServerResource, right ?
> 
> I won't code this, but it would be nice to minimize languages used in
> CloudStack and try to be consistent across hypervisors (as much as possible).
> Introducing another language and some framework that may or may not
> have proprietary modules/dependencies will certainly complicate the build
> and the testing, and maybe even the licensing.
> 

Actually the ServerResource part was always planned to be implemented in other 
languages.  Java is a terrible platform to execute scripts for example.  That's 
why communication between management server and the server resource was done in 
JSON.

--Alex

Re: [ACS41] Bugs blocking our 4.1 release

[Sheng Yang]

Yes. And it's mostly a guest os issue.

DHCP ipv6 server already sent out DNS entries but the guest os have
limitation of 3 dns entries, so 3 for ipv4 and 3 for ipv6, so guest os
would only see 3 of dns entries.

--Sheng

On Tue, Mar 26, 2013 at 2:08 PM, Chip Childers
 wrote:
> On Tue, Mar 26, 2013 at 2:32 PM, Sheng Yang  wrote:
>> CLOUDSTACK-1755 IPv6 - When Vm is part of Dual network ,
>> /etc/reslov.conf does not have ipv6 router ipaddress and ipv6 external
>> dns.
>>
>> This bug's fix version is 4.2...
>>
>> --Sheng
>
> Just to be clear...  you are saying that it's not going to be fixed
> for 4.1?  That's OK with me, as the IPv6 feature is experimental in
> 4.1.  I just want to understand what you are saying.
>
> -chip

Review Request: Remove baremetal as default network provider for basic zone configuration.

[Venkata Siva Vijayendra Bhamidipati]

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

Review request for cloudstack, Chip Childers, Kelven Yang, and Min Chen.


Description
---

Do not add baremetal as default network provider for basic zone configuration, 
since the ucs and baremetal components have been temporarily disabled as part 
of CLOUDSTACK-1773.


This addresses bug CLOUDSTACK-1812.


Diffs
-

  server/src/com/cloud/network/NetworkServiceImpl.java 0cd3ebe 

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


Testing
---

Confirmed that basic zone creation succeeds without failing at the physical 
network creation stage. Advanced zone creation also was checked to work 
correctly.


Thanks,

Venkata Siva Vijayendra Bhamidipati

Re: Review Request: BugFix CLOUDSTACK-1803: Slashes removed from local storage path

[edison su]

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

Ship it!


Ship It!

- edison su


On March 25, 2013, 8:41 p.m., Brian Spindler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10124/
> ---
> 
> (Updated March 25, 2013, 8:41 p.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Description
> ---
> 
> Fix for deleting all slashes from the storage path instead of just the first 
> slash.
> 
> 
> This addresses bug CLOUDSTACK-1803.
> 
> 
> Diffs
> -
> 
>   
> plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
>  2991574 
> 
> Diff: https://reviews.apache.org/r/10124/diff/
> 
> 
> Testing
> ---
> 
> Ubuntu 12.04, turned local storage on, added a physical host.
> 
> 
> Thanks,
> 
> Brian Spindler
> 
>

Re: [ACS41] Bugs blocking our 4.1 release

[Kelven Yang]

I have submitted the patches.

Kelven

On 3/25/13 1:15 PM, "Chip Childers"  wrote:

>Hi all,
>
>The following bugs need to be either (1) resolved or (2) triaged as not
>being as high a priority as they are now before I cut the RC.  Can folks
>take a moment to review and update / fix accordingly please?
>
>CLOUDSTACK-1694 Issues to start/access Management Server after upgrade
>from 4.0 to 4.1  Pradeep Soundararajan
>CLOUDSTACK-1719 EC2 REST API: AWS APIs are not getting translated on the
>CloudStack Management Server   Pradeep Soundararajan
>CLOUDSTACK-1772 the change in vnc listening port will cause live
>migration doesn't work edison su
>CLOUDSTACK-1795 Customize AOP to fully support legacy CloudStack @DB and
>@ActionEvent semantics Kelven Yang
>CLOUDSTACK-1664 Action Events are not logged due to spring changes
>Kelven Yang
>CLOUDSTACK-1673 AWS Regions - Events - User disable event does not
>include the UUID of the user that was disabled.  Murali Reddy
>CLOUDSTACK-1740 Failed to view console  Rajesh Battala
>CLOUDSTACK-1755 IPv6 - When Vm is part of Dual network , /etc/reslov.conf
>does not have ipv6 router ipaddress and ipv6 external dns.Sheng Yang
>CLOUDSTACK-1789 Unable to download templates to Primary Storage if a host
>is in maintenance edison su
>CLOUDSTACK-1802 Upgrade 4.0 -> 4.1 - Not able to strat management server
>becasue of missing /etc/cloudstack/management/tomcat6.conf file.
>Pradeep Soundararajan
>
>
>I'd also like us to resolve
>https://issues.apache.org/jira/browse/CLOUDSTACK-1796 - which is a
>Japanese docs building issue.  Sebastien, can you please review the
>latest from Transifex (per latest comment from Hiroaki)?
>
>-chip

Re: Review Request: BugFix CLOUDSTACK-1803: Slashes removed from local storage path

[David Nalley]

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


Edison committed this: 

Branch: refs/heads/master
Commit: 99bcfd24c70d751d0222944d15a468a6017fb660
Parents: 5df32e6
Author: Brian Spindler 
Authored: Mon Mar 25 13:20:27 2013 -0700
Committer: Edison Su 
Committed: Tue Mar 26 17:36:29 2013 -0700


- David Nalley


On March 25, 2013, 8:41 p.m., Brian Spindler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10124/
> ---
> 
> (Updated March 25, 2013, 8:41 p.m.)
> 
> 
> Review request for cloudstack and edison su.
> 
> 
> Description
> ---
> 
> Fix for deleting all slashes from the storage path instead of just the first 
> slash.
> 
> 
> This addresses bug CLOUDSTACK-1803.
> 
> 
> Diffs
> -
> 
>   
> plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
>  2991574 
> 
> Diff: https://reviews.apache.org/r/10124/diff/
> 
> 
> Testing
> ---
> 
> Ubuntu 12.04, turned local storage on, added a physical host.
> 
> 
> Thanks,
> 
> Brian Spindler
> 
>

Re: git commit: updated refs/heads/master to 99bcfd2

[David Nalley]

Is there a reason the commit message isn't what was in the review
request? Did you use git am?

--David

On Tue, Mar 26, 2013 at 8:38 PM,   wrote:
> Updated Branches:
>   refs/heads/master 5df32e6d7 -> 99bcfd24c
>
>
> All slashes were being removed from the storage path which caused adding the 
> pool to break.
> Reviewed-by: Edison Su
>
>
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/99bcfd24
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/99bcfd24
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/99bcfd24
>
> Branch: refs/heads/master
> Commit: 99bcfd24c70d751d0222944d15a468a6017fb660
> Parents: 5df32e6
> Author: Brian Spindler 
> Authored: Mon Mar 25 13:20:27 2013 -0700
> Committer: Edison Su 
> Committed: Tue Mar 26 17:36:29 2013 -0700
>
> --
>  .../CloudStackPrimaryDataStoreLifeCycleImpl.java   |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/99bcfd24/plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
> --
> diff --git 
> a/plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
>  
> b/plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
> index 2991574..b8b0859 100644
> --- 
> a/plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
> +++ 
> b/plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
> @@ -204,7 +204,7 @@ public class CloudStackPrimaryDataStoreLifeCycleImpl 
> implements
>  String hostPath = uri.getPath();
>  Object localStorage = dsInfos.get("localStorage");
>  if (localStorage != null) {
> -hostPath = hostPath.replace("/", "");
> +hostPath = hostPath.replaceFirst("/", "");
>  }
>  String userInfo = uri.getUserInfo();
>  int port = uri.getPort();
>

Re: Review Request: Add docs for MidoNet networking plugin [CLOUDSTACK-996]

[Dave Cahill]

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

(Updated March 27, 2013, 1:34 a.m.)


Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.


Changes
---

Fixed points mentioned by David - 2012 -> 2013, and remove -incubating.


Description
---

Adding docs for MidoNet networking plugin [CLOUDSTACK-996]

Plugin itself is awaiting review / commit here:
[PATCH 1] https://reviews.apache.org/r/9897/
[PATCH 2] https://reviews.apache.org/r/9898/


This addresses bug CLOUDSTACK-996.


Diffs (updated)
-

  docs/en-US/MidoNet_Plugin_Guide.ent PRE-CREATION 
  docs/en-US/MidoNet_Plugin_Guide.xml PRE-CREATION 
  docs/en-US/plugin-midonet-about.xml PRE-CREATION 
  docs/en-US/plugin-midonet-features.xml PRE-CREATION 
  docs/en-US/plugin-midonet-introduction.xml PRE-CREATION 
  docs/en-US/plugin-midonet-preparations.xml PRE-CREATION 
  docs/en-US/plugin-midonet-provider.xml PRE-CREATION 
  docs/en-US/plugin-midonet-revisions.xml PRE-CREATION 
  docs/en-US/plugin-midonet-ui.xml PRE-CREATION 
  docs/en-US/plugin-midonet-usage.xml PRE-CREATION 
  docs/publican-plugin-midonet.cfg PRE-CREATION 

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


Testing
---

Built docs.


Thanks,

Dave Cahill

Re: Storage Subsystem 2.0 plugin docs

[Mike Tutkowski]

Great - thanks, Edison!

I can take a look at that code.

I've almost gotten the VMware code written.

It's a little more involved than the XenServer code because you have to add
static IQNs for discovery to each host in a VMware cluster (this is somehow
handled behind the scenes, I suppose, with XenServer) before you can create
a Datastore based on your iSCSI target.

One thing I was wondering, though, is when you add a new host to this
VMware cluster.  It will need to "inherit" the list of IQNs to discover.  I
image this is the case today.  Do you know anything about that?  I might
just try it out and see if that works today.


On Tue, Mar 26, 2013 at 5:18 PM, Edison Su  wrote:

> Thanks! 
>
> FYI, there are some code at both xen and kvm hypervisor resource code to
> deal with storage pool creation. 
>
> For example, in CitrixResourceBase-> getNfsSR or getIscsiSR to create a
> nfs SR or ISCSI SR. In LibvirtStorageAdaptor, which can create storage pool
> in libvirt.
>
> ** **
>
> ** **
>
> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> *Sent:* Tuesday, March 26, 2013 1:52 PM
> *To:* Edison Su
> *Cc:* cloudstack-...@incubator.apache.org; Vladimir Popovski
>
> *Subject:* Re: Storage Subsystem 2.0 plugin docs
>
> ** **
>
> Hi Edison,
>
> ** **
>
> Sounds good.
>
> ** **
>
> I already have code to create a XenServer Storage Repository (and
> optionally use CHAP credentials) and I'm working right now on creating a
> vSphere Datastore.
>
> ** **
>
> When I have this working and in a nicer state, I can check in with you to
> review it and provide comments.
>
> ** **
>
> Once those two hypervisors are handled, I'll move on to KVM and OVM.
>
> ** **
>
> Thanks!
>
> ** **
>
> On Tue, Mar 26, 2013 at 2:33 PM, Edison Su  wrote:**
> **
>
> Yes, code is welcome!!! Currently Only the interface at the management
> server side is defined. At the hypervisor resource side, we may need some
> kind of utility library or another plugin framework, as John proposed few
> months ago.
>
>  
>
> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> *Sent:* Monday, March 25, 2013 2:37 PM
> *To:* Edison Su; cloudstack-...@incubator.apache.org; Vladimir Popovski***
> *
>
>
> *Subject:* Re: Storage Subsystem 2.0 plugin docs
>
>  
>
> Hey Edison,
>
>  
>
> So...if you think my understanding is correct (please check out the e-mail
> below), then I have a question.
>
>  
>
> Do we really want to have the storage plug-ins taking on the
> responsibility of talking to the hypervisors to hook up the storage that
> they just created?
>
>  
>
> I'm a bit familiar with how OpenStack does this and it seems that it only
> has its storage plug-ins create a volume (LUN, whatever) and then the
> framework handles the process of dealing with the hypervisor in question to
> hook up the storage.
>
>  
>
> It seems like otherwise we'd need to create a utility for all storage
> plug-ins to share otherwise they'd be duplicating efforts in talking to
> hypervisors.
>
>  
>
> What do you think?
>
>  
>
> On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> Hi Edison,
>
>  
>
> I believe I understand the requirements for the plug-in better now.
>
>  
>
> It sounds like the flow will be as such:
>
>  
>
> * The user executes a Compute or Disk Offering that is tied via a storage
> tag to a Primary Storage that is associated with a plug-in.
>
>  
>
> * The storage framework will ask the plug-in to create a volume.  The
> plug-in will create a volume and hook the volume up to the appropriate
> hypervisor.  For VMware, this means the plug-in will create a Datastore.
>  For XenServer, this means the plug-in will create a Storage Repository.
>  (So on and so forth for other hypervisors.)
>
>  
>
> * The VM or data disk is then deployed to the hypervisor.
>
>  
>
> Does that sound correct, Edison?
>
>  
>
> Thanks!
>
>  
>
> On Thu, Mar 21, 2013 at 5:44 PM, Edison Su  wrote:**
> **
>
>  
>
>  
>
> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> *Sent:* Thursday, March 21, 2013 4:18 PM
> *To:* Edison Su
> *Subject:* Re: Storage Subsystem 2.0 plugin docs
>
>  
>
> Hi Edison,
>
>  
>
> I wanted to dive into these comments a bit more:
>
>  
>
> [Edison] plugin’s driver->createasync will be called when mgt server want
> to create a volume on the storage. In the driver’s implementation, it can
> directly call storage box’s api, or send a command to hypervisor host, then
> call storage box’s api to create an iscsi.
>
> Then create a datastore(for vmware), SR(for xenserver), or storage
> pool(for KVM) on hypervisor host, based on the iscsi iqn.
>
> If the volume is created from a template(for root disk), need to find a
> way to import that template(which is nfs based currently, it will be

Re: [PROPOSAL] QuickCloud

[Chiradeep Vittal]

On 3/26/13 2:26 PM, "David Nalley"  wrote:

>On Mon, Mar 25, 2013 at 2:54 AM, Chiradeep Vittal
> wrote:
>> To enable a cloud to start quicker, I am proposing that system vms be
>>made optional in the boot-up of a CloudStack Cloud.
>> I'm working on the 'quickcloud' branch and the detailed proposal is
>>here:
>> https://cwiki.apache.org/confluence/x/clnVAQ
>>
>
>
>Theoretically this should make it easier to break out the 'services'
>from the debian-based systemvm, right?
>We get closer to being able to run the systemvm services anywhere
>(such as Fedora, CEntOS, *BSD etc)
>
>
>--David

Correct. 

Re: [ACS41] Blocker Defects to cut RC

[Prasanna Santhanam]

The list is coming down to cut RC -

Blockers as of (UTC -0530, Mar 27th)

CLOUDSTACK-1810 listTemplate API with templatefilter=featured|community is not 
returning any list
CLOUDSTACK-1817 Unable to create Basic Zone
CLOUDSTACK-1812 create physical network fails while creating basic zone
CLOUDSTACK-1804 Upgrade 4.0 -> 4.1 - DB upgrade fails.

1817 and 1812 seem contradictory to each other. So both can probably be
resolved in one-shot.

On Fri, Mar 22, 2013 at 12:44:35PM -0700, Sudha Ponnaganti wrote:
> Below are the blockers/critical - removed bare metal related ones from the 
> list. 
> 
> Alena - can you review 1791 and see if you can fix it or may be someone else 
> can pick it up if they have expertise in this area
> Prachi - Same with 1776 - can you review and set it unassigned if this is not 
> in your area of expertise. 
> 
> 
> Alena Prokharchyk CLOUDSTACK-1791 Volumes with storage tags can't 
> be attached
> Pradeep Soundararajan CLOUDSTACK-1694 Issues to start/access Management 
> Server after upgrade from 4.0 to 4.1
> Wido den HollanderCLOUDSTACK-1736 Ubuntu 12.04 
> cloud-setup-management Failed to configure CloudStack Management Server
> edison su CLOUDSTACK-1789 Unable to download templates to Primary 
> Storage if a host is in maintenance
> Hugo TrippaersCLOUDSTACK-216  Templates' Source Location 
> Information present on "template_host_ref" and "vm_template" tables should 
> refer to Apache System Template Locations
> Hugo TrippaersCLOUDSTACK-1252 Failed to download default 
> template in VMware
> Kelven Yang   CLOUDSTACK-1664 Action Events are not logged due to 
> spring changes
> Murali Reddy  CLOUDSTACK-1673 AWS Regions - Events - User disable 
> event does not include the UUID of the user that was disabled.
> Prachi Damle  CLOUDSTACK-1776 NPE on 
> listSecondaryStorageHostsInAllZones in Upgraded setup from 4.0 to 4.1
> 

-- 
Prasanna.,

Re: [QuickCloud] zero to cloud in less than a minute

[Ahmad Emneina]

would someone be able to fire up all those services (say for a basic zone)
on one host?


On Tue, Mar 26, 2013 at 10:37 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Following the discussion [1], we have QuickCloud in a rough-but-ready
> state for developers to try out
> Instructions  for developers to try it out with DevCloud2 here:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
>
> For now only Mac / Unix developers can use this workflow since NFS mounts
> are required.
>
> [1] http://markmail.org/thread/ajw7b6arhluqcuv2
>

Re: Review Request: CLOUDSTACK-1156: Limit Primary and Secondary storage for domain/accounts

[Sanjay Tripathi]

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

(Updated March 27, 2013, 6 a.m.)


Review request for cloudstack, Devdeep Singh, Nitin Mehta, Sateesh 
Chodapuneedi, mice xia, and Min Chen.


Changes
---

updated patch, in sync with the latest code.


Description
---

CLOUDSTACK-1156: Limit Primary and Secondary storage for domain/accounts

Addition of two new resource types i.e. Primary and Secondary storage space 
in the existing pool of
resource types.
Added methods to set the limits on these resources using updateResourceLimit
API command and to get a count using updateResourceCount. Also added calls 
in the
Templates, Volumes, Snapshots life cycle to check these limits and to 
increment/decrement the new
resource types

Resource Name  :: Resource type number
Primary Storage   10
Secondary Storage 11

Also added jUnit Tests for the same.


This addresses bug CLOUDSTACK-1156.


Diffs (updated)
-

  api/src/com/cloud/configuration/Resource.java 7614c8a 
  api/src/com/cloud/storage/VolumeApiService.java 8517988 
  
api/src/org/apache/cloudstack/api/command/user/resource/UpdateResourceCountCmd.java
 f6d3a98 
  
api/src/org/apache/cloudstack/api/command/user/resource/UpdateResourceLimitCmd.java
 0039f62 
  api/src/org/apache/cloudstack/api/command/user/volume/ResizeVolumeCmd.java 
955727a 
  api/src/org/apache/cloudstack/api/response/AccountResponse.java 9a98a35 
  api/src/org/apache/cloudstack/api/response/ResourceCountResponse.java a7fbbf2 
  api/src/org/apache/cloudstack/api/response/ResourceLimitResponse.java b444e7a 
  
plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalTemplateAdapter.java
 33725f6 
  server/src/com/cloud/alert/AlertManagerImpl.java a45482f 
  server/src/com/cloud/api/ApiResponseHelper.java 663139d 
  server/src/com/cloud/api/query/dao/AccountJoinDaoImpl.java 898bafc 
  server/src/com/cloud/api/query/vo/AccountJoinVO.java cd7231c 
  server/src/com/cloud/configuration/Config.java 9db7dbd 
  server/src/com/cloud/resourcelimit/ResourceLimitManagerImpl.java 23c0796 
  server/src/com/cloud/storage/VolumeManager.java af3cbbf 
  server/src/com/cloud/storage/VolumeManagerImpl.java 737ed0a 
  server/src/com/cloud/storage/dao/SnapshotDao.java 0e378a7 
  server/src/com/cloud/storage/dao/SnapshotDaoImpl.java 825b6d5 
  server/src/com/cloud/storage/dao/VolumeDao.java d7a2667 
  server/src/com/cloud/storage/dao/VolumeDaoImpl.java 40ed875 
  server/src/com/cloud/storage/download/DownloadListener.java d4c20cf 
  server/src/com/cloud/storage/download/DownloadMonitorImpl.java 0bc89e3 
  server/src/com/cloud/storage/snapshot/SnapshotManagerImpl.java bacca01 
  server/src/com/cloud/template/HypervisorTemplateAdapter.java 1426421 
  server/src/com/cloud/template/TemplateManagerImpl.java d843dbc 
  server/src/com/cloud/vm/UserVmManagerImpl.java 82a69bd 
  server/test/com/cloud/resourcelimit/ResourceLimitManagerImplTest.java d311ad3 
  server/test/com/cloud/vpc/MockResourceLimitManagerImpl.java b9fc861 
  setup/db/db/schema-40to410.sql 60ad025 
  setup/db/db/schema-410to420.sql eb650cc 
  utils/src/com/cloud/utils/UriUtils.java a8b5ccb 

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


Testing
---

Tested life cycle of templates, volumes, snapshots, vm on my local CloudStack 
setup.


Thanks,

Sanjay Tripathi

Re: Review Request: MidoNet Networking Plugin [2/2]

[Dave Cahill]

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

(Updated March 27, 2013, 6:33 a.m.)


Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.


Changes
---

Fixed Hiroaki's exception-related review comment.


Description
---

Feature spec:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Midokura+Networking+Plugin

Jira ticket:
https://issues.apache.org/jira/browse/CLOUDSTACK-996

Notes:

* Documentation will follow as a separate commit

* One main difference from existing networking plugins is the lack of a 
Resource class; we didn't feel it was necessary in this case. As mentioned in 
Extending CloudStack Networking [1]:
"Just like managers, resources are not strictly necessary. In theory a Network 
Element could implement a client for the API of the new controller and 
therefore be completely self-contained."

* We allow overriding Public traffic via the MidoNetPublicNetworkGuru. We 
checked this approach with the list [2] and received no comments, so we're 
going with it for now.

[1] https://cwiki.apache.org/CLOUDSTACK/extending-cloudstack-networking.html
[2] http://markmail.org/message/k5qse63eyylszm3i


This addresses bug CLOUDSTACK-996.


Diffs (updated)
-

  api/src/com/cloud/network/Network.java c2ab655 
  api/src/com/cloud/network/Networks.java e3d2158 
  api/src/com/cloud/network/PhysicalNetwork.java 343a2b1 
  api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java 
bc22804 
  client/pom.xml 7ad2eff 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtDomainXMLParser.java
 b622b6d 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java 
c93aeeb 
  plugins/network-elements/midokura-midonet/pom.xml 7f2e2d3 
  plugins/network-elements/midonet/pom.xml PRE-CREATION 
  
plugins/network-elements/midonet/src/com/cloud/network/element/MidoNetElement.java
 48833b3 
  
plugins/network-elements/midonet/src/com/cloud/network/element/SimpleFirewallRule.java
 PRE-CREATION 
  
plugins/network-elements/midonet/src/com/cloud/network/guru/MidoNetGuestNetworkGuru.java
 ed0eb3c 
  
plugins/network-elements/midonet/src/com/cloud/network/guru/MidoNetPublicNetworkGuru.java
 PRE-CREATION 
  
plugins/network-elements/midonet/src/com/cloud/network/resource/MidoNetVifDriver.java
 PRE-CREATION 
  
plugins/network-elements/midonet/test/com/cloud/network/element/MidoNetElementTest.java
 PRE-CREATION 
  plugins/pom.xml 39d9907 
  server/src/com/cloud/configuration/Config.java 9db7dbd 
  server/src/com/cloud/network/NetworkManagerImpl.java b1236cc 
  ui/scripts/system.js c0a5d14 

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


Testing
---

Built and deployed, spun up Advanced Isolated network with two VMs, verified 
internal and external connectivity via MidoNet.


Thanks,

Dave Cahill