Re: IOPS throttling setting isn't applied to a dinamically attached volume

[Daan Hoogland]

There are no strict definitions, but a blocker is something that
should be discussed on list in my opinion, as it is something that
implies a release is being blocked (and unusable if brought out
anyway). Maybe you where right to make your issue a blocker but I
would like to be convinced of that on list by discussion before we
mark it as such. This also ensures that enough devs are aware that we
have such an issue.

hope you understand,

On Wed, Jun 18, 2014 at 7:29 PM, Yoshikazu Nojima  wrote:
> Daan,
>
> Could you let me know the definitions of each priorities in ACS
> project (or a document that describe the definition)?
> Sometimes I'm confused which priority to use.
>
> Thanks,
> Noji
>
>
> 2014-06-18 6:09 GMT-06:00 Daan Hoogland :
>> H,
>>
>> Yoshikazu Nojima created an issue as blocker that I immediately set to
>> critical out of principle. I do want to mention it here though,
>> because it might be important enough to mark as a blocker after all.
>>
>> any expert on the title have extensive opinionated comments on it?
>>
>> --
>> Daan



-- 
Daan

Re: [POLL] Who uses "awsapi" with CloudStack in production?

[Daan Hoogland]

Carlos, please export your db and do a test upgrade on a lab machine?
Now is the time to solve any upgrade issues in 4.4.

Have you tried the 4.3 upgrade already?

regards,
Daan

On Wed, Jun 18, 2014 at 7:04 PM, Carlos Reátegui  wrote:
> Hi Rohit,
>
> The awsapi was one of the reasons we chose to use ACS.  We have developed 
> some internal tools and apps to manage our deployments on AWS that we want to 
> re-use on ACS.  We have not been able to use it yet because it was broken in 
> 4.1.1.  We tried to upgrade to 4.2 and were unsuccessful and are now waiting 
> for 4.4 to finally upgrade and hopefully be able to use the awsapi.
>
> We use ACS internally for development and testing of our applications that we 
> push to AWS.
>
> thanks,
> Carlos
>
>
> On Jun 18, 2014, at 12:11 AM, Rohit Yadav  wrote:
>
>> Hi,
>>
>> Who uses "awsapi" or any other EC2 compatible interface such as ec2stack
>> with CloudStack (or CloudStack distros such as Citrix CloudPlatform) in
>> production? And, if marketing and publicity are/were big motivation(s)?
>>
>> In case you don't want to discuss on this thread, please take this
>> anonymous poll:
>> http://www.polljunkie.com/poll/fbyfdc/who-uses-awsapi-with-cloudstack-in-prouduction
>>
>> # Some stats
>>
>> I've been watching Collab14 videos and found references where many speakers
>> reference overall CloudStack codebase to be about 1.5M (million) lines of
>> Java code which is not "exactly" true. Let me share some findings;
>>
>> - As of today, CloudStack master is about 1.7M lines of Java code [1]
>> - CloudStack "awsapi" artifact is 1.04M lines of Java code [2]
>> - Code excluding "awsapi", tests and license/comment is about 590k lines of
>> Java code [3]
>> - The core excluding plugins, api and the above is about 300k lines of Java
>> code [4]
>>
>> Why should  I care:
>> - some useful/fun stats to keep in mind
>> - it's not a giant mammoth that cannot be fixed or developed upon
>> - encouraging for new developers that if they try they can understand and
>> fix it
>>
>> FYI, this started on twitter yesterday:
>> https://twitter.com/_bhaisaab/status/479007075414974465
>>
>> [1] cd cloudstack-repo && find . | grep java$ | xargs cat | wc -l
>> [2] cd cloudstack-repo && find awsapi | grep java$ | xargs cat | wc -l
>> [3] cd cloudstack-repo && find . | grep -v awsapi | grep -v [tT]est | grep
>> java$ | xargs cat | grep -v '^//' | wc -l
>> [4] cd cloudstack-repo && find . | grep -v awsapi | grep -v [Tt]est | grep
>> -v plugins | grep -v api | grep java$ | xargs cat | grep -v '^//' | wc -l
>>
>> Regards.
>



-- 
Daan

Re: [ACS 4.4] cherry-pick request for CLOUDSTACK-6935

[Daan Hoogland]

On Wed, Jun 18, 2014 at 10:35 PM, Yoshikazu Nojima  wrote:
> 45f0c7367680f4bfbcee470139b708d69322be78


is in

-- 
Daan

Expected behavior for volume migration done after the download of volume

[Anshul Gangwar]

Hi,


I am looking into fixing bug 
https://issues.apache.org/jira/browse/CLOUDSTACK-6900. When we download volume 
then we create entry for that volume in volume_store_ref table. We mark the 
volume in ready state. When we migrate that volume, then again one more entry 
is created with same volume id. Its state is marked as allocated. This way 
there are two entries in volume_store_ref table. In one case it is marked as 
allocated and in other case it is marked as in ready state.

Later we try to list only one dataobject in datastore for state transition 
during volume migration. If the listed volume's state is allocated then it 
passes otherwise it fails.

Download url expires after 4 hrs. After 4 hrs migration should pass as there 
will be unique dataobject in datastore for the volume.

What should be the expected behavior in this transition period i.e. till the 
download volume of url expires?

Thanks,

Anshul

Re: Review Request 22695: Stress Test to test multiple Remote Access VPN Connections to VPC

[Santhosh Edukulla]

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



test/integration/component/test_multipleremotevpn_vpc.py


We are restarting management server, if it is kept as part of component, 
then other tests when running parallely, will get affected? Do we want to add 
this as part of component or there is additional maint directory, we may want 
to put there. 



test/integration/component/test_multipleremotevpn_vpc.py


use is not None


- Santhosh Edukulla


On June 17, 2014, 9 p.m., Chandan Purushothama wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22695/
> ---
> 
> (Updated June 17, 2014, 9 p.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, Raja Pullela, sangeetha 
> hariharan, sanjeev n, Santhosh Edukulla, sudha ponnaganti, and 
> SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Stress Test that tests multiple VPN Connections to VPC. The number of VPN 
> Connections to be stressed with can be regulated using "vpnclient_count" on 
> test_data.py.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_multipleremotevpn_vpc.py PRE-CREATION 
>   tools/marvin/marvin/config/test_data.py d870c98 
> 
> Diff: https://reviews.apache.org/r/22695/diff/
> 
> 
> Testing
> ---
> 
> Test case no : Enable VPN for Public IP Address on the VPC ... === TestName: 
> test_01_Multiple_RemoteAccessVPN_Connections_To_VPC_Ping_Guest_VM_Multiple_Times
>  | Status : SUCCESS ===
> ok
> 
> --
> Ran 1 test in 2480.632s
> 
> OK
> 
> 
> Thanks,
> 
> Chandan Purushothama
> 
>

Re: Review Request 22693: Added VirtualRouterElements, InternalLoadBalancerElements classes to base.py- Extended methods in DiskOffering, StoragePool and Physical Network classes to accept more parame

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On June 17, 2014, 7:25 p.m., Chandan Purushothama wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22693/
> ---
> 
> (Updated June 17, 2014, 7:25 p.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, Raja Pullela, sangeetha 
> hariharan, sanjeev n, Santhosh Edukulla, sudha ponnaganti, and 
> SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Currently methods in DiskOffering, StoragePool and Physical Network restrict 
> the programmer to use limited parameters. I made changes to the methods in 
> those classes to accept more parameters that can be used during test script 
> programming.
> 
> Added VirtualRouterElements, InternalLoadBalancerElements classes to base.py 
> . The code will make the test script programming easier for programmers 
> writing test scripts related to Zones.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/lib/base.py 8b89087 
> 
> Diff: https://reviews.apache.org/r/22693/diff/
> 
> 
> Testing
> ---
> 
> Test Suite was scripted and tested with the above mentioned additions to 
> base.py.
> 
> 
> Thanks,
> 
> Chandan Purushothama
> 
>

How to list pciDevices

[Gaurav Aradhye]

Hello,

How do we list the available pci devices available in a setup? I want to
know the GPU and vGPU type which we specify while creating service offering
in advance so that I can pass it in test case.

Regards,
Gaurav

S3 use with simulator

[Sebastien Goasguen]

Hi,

I am using the simulator and started a basic zone.
I have an S3 object store locally (riakCS), and I am trying to add it to the 
infra using the 'cloudtouseobjectstore' api with cloudmonkey.

I tried with:

> update cloudtouseobjectstore url=http://localhost:9081/riak-cs name=riak 
> provider=riakcs 
> details[0].key=accesskey&details[0].value=STU6Z-ZMK1TPMDAXL9I1&details[1].key=secretkey&details[1].value=8OuY3mHDXihu0Tdb2aVJ4vuYZLBAl5Z7NiWKsg==
530: Failed to add data store: DataCenter id is null, and simulator image store 
has to be associated with a data center

I am not sure if the arguments are right, has anyone done this before ?

thanks,

-sebastien

Re: Review Request 22750: Removed load option and added required_hardware attribute to pom

[SrikanteswaraRao Talluri]

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


Following command is failing: 
sudo mvn -Pdeveloper,marvin.test  -pl :cloud-marvin -Dendpoint=localhost
removing 'Marvin-0.1.0' (and everything under it)
[INFO] 
[INFO] --- exec-maven-plugin:1.2.1:exec (integration-test) @ cloud-marvin ---

=== Marvin Parse Config Init Failed ===




can 'marvin.setup' profile also be updated?

- SrikanteswaraRao Talluri


On June 19, 2014, 5:10 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22750/
> ---
> 
> (Updated June 19, 2014, 5:10 a.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-6914
> https://issues.apache.org/jira/browse/CLOUDSTACK-6914
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1. As part of refactoring, we removed load option to nose marvin plugin, now 
> removed it from pom and added required_hardware attribute to pom
> 2. simulator, selfservice, tags earlier added were redundant, at many places 
> under test cases, these are same. Removed them as part of clean up from test 
> cases. Removed them from pom file as well
> 
> 
> Diffs
> -
> 
>   tools/marvin/pom.xml f36f5e4 
> 
> Diff: https://reviews.apache.org/r/22750/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

[ACS44] cherry-pick request

[Murali Reddy]

Please cherry-pick below commit in 4.4-forward into 4.4

commit d8cbba1bc616d43e218229a2807915c1b21569dc

CLOUDSTACK-6750: [OVS] With stretched network deploying vm in a ovs
disabled zone does not fail

Re: Managing individual ESXi instances

[Ivan Efremov]

Thanks for the reply!

Ivan


18.06.2014, 21:43, "Alex Huang" :
> Hi Ivan,
>
> To introduce a new hypervisor, it's a matter of
> - Adding a new Discoverer implementation to tell CloudStack which Resource 
> best works with the new Hypervisor.
> - Adding a new Resource implementation that deals with all of the hypervisor 
> commands sent to it.  This is the big part due to the large set of commands 
> we send to it.
>
> For someone who understands CloudStack code and the hypervisor well, I think 
> a prototype can be done in about two months or so.  For ESX, you have to 
> figure out a how to map functions that CS supports but is not with ESX.  For 
> example, I think migration and live storage migration.  You can decide not to 
> support them in the prototype and just support simple vm/volume/network life 
> cycle for now.
>
> --Alex
>>  -Original Message-
>>  From: Ivan Efremov [mailto:e...@yandex.ru]
>>  Sent: Wednesday, June 18, 2014 8:31 AM
>>  To: dev@cloudstack.apache.org
>>  Subject: Re: Managing individual ESXi instances
>>
>>  Hi Alex,
>>
>>  How do you think, what is the rough estimation of adding ESX API support to
>>  CloudStack?
>>  AFAIU the main point of integration of the new API is plugins/hypervisors.
>>  Are there any other major points that should be patched when adding a new
>>  hypervisor type?
>>
>>  Thanks,
>>  Ivan
>>
>>  18.06.2014, 18:24, "Alex Huang" :
>>>  IIRC, the reason is because the vCenter API is more powerful than the ESX
>>  API.  At the time (before Apache), the features that requested needed
>>  vCenter. There's currently no proposal to use plain ESXi.  Would love to see
>>  one though.
>>>  --Alex
   -Original Message-
   From: Ivan Efremov [mailto:e...@yandex.ru]
   Sent: Tuesday, June 17, 2014 8:26 PM
   To: dev@cloudstack.apache.org
   Subject: Managing individual ESXi instances

   Hi all,

   I've sent this mail to the users list but this one looks as the better
>>  destination.
   I'm new to the CloudStack platform and I'm wondering why the platform
   does need the vCenter API and can not use ESXi directly,

   Can anyone elaborate on this?
   Are there any proposals for adding ESXi integration to CloudStack?

   Thanks,
   Ivan

Re: [ACS44] cherry-pick request

[Daan Hoogland]

On Thu, Jun 19, 2014 at 2:22 PM, Murali Reddy  wrote:
> d8cbba1bc616d43e218229a2807915c1b21569dc


is in

-- 
Daan

ID instead of name in deployVirtualMachine

[Nux!]

Hi,

We need to deploy VMs on behalf of certain users and surprisingly it's not 
possible to use accountid with deployvirtualmachine, the actual name of the 
account needs to be used.
Anyone knows why this is and if it can be changed? It's quite awkward since 
everything else in the API seems to rely heavily on IDs.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

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

[Silvano Nogueira Buback]

Hi Ilya,

   I put the plugin code in
https://github.com/globocom/cloudstack/tree/4.3.0-globo/plugins/network-elements/dns-api.
We use it with Shared/Advanced network zones. But in order to communicate
with other networks (bind server network, for example), it is necessary to
define and implement an ACL. In Globo.com this is made automatically by our
NetworkAPI that has common ACLs to new networks that allow all virtual
machines to access DNSAPI on port 53. The IP of bind managed by DNSAPI is
the same of internal DNS configured in the zone. DNSAPI works without
NetworkAPI as well, you just have to configure ACLs manually.

I will prepare the Design Document, which will explain all changes made
and send it to this mailing list. We are working to improve DNS-API
Documentation too. You can check it out now, but we're still working on it:
https://github.com/globocom/Dns-Api.

We intend to make NetworkAPI code open source too to manage shared
networks. Using NetworkAPI, shared network are created by regular users,
because this api are responsible to choose ip address and vlan number, and
to create network in different equipment too. I want to talk about this in
another thread, when I submit the code of NetworkAPI to community.

Inside Globo we are working in our own tool of Database as a Service (
https://github.com/globocom/database-as-a-service). The module you saw at
github is responsible to provision new VMs using Cloudstack. We are
developing an connector to Cloud Portal Business Manager too. If you want
more information about DBaaS, you can send an e-mail to db...@corp.globo.com.
People there can explain detail about the implementation / feature and
plans. I'm in that list too.

Regards,

Silvano Buback
Globo.com Infra-structure Expert


On Fri, Jun 13, 2014 at 3:24 AM, ilya musayev 
wrote:

> Hi Silvano,
>
> I really liked what you did.
>
> I'm curious if this DNS provider will work with non-isolated/shared
> advanced network zones as well.
> Otherwise, great approach to solving the last DNS puzzle. I now wonder how
> easy it would be to add other DNS Providers support into CloudStack besides
> Bind.
>
> Can you share the changes you've made to your cloudstack env to support
> DNSApis?
>
> Also noticed DBaaS-CloudStack in github, sounds interesting, what is it
> based on? If you can, please kindly explain.
>
> Regards
> ilya
>
> On 6/12/14, 10:21 PM, Silvano Nogueira Buback wrote:
>
>> Hi there,
>>
>>
>> I work at Globo.com, a media company in Brazil. Here we use a cloudstack
>> private network with an advanced zone setup (isolated vlans).
>>
>> For some couple of reasons, the name of virtual machine needs to be
>> available not only on virtual router network context, but on our internal
>> DNS servers.
>>
>> Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server)
>> thru an open source API written by globo.com called DNSAPI. More info at
>> https://github.com/globocom/Dns-Api.
>>
>> To make this implementation of DNS provider, we based our plugin on
>> "dns-notifier", but we had to add more classes for our implementation.
>>
>> * DnsAPINetworkDAO to manage the networkDomain for each network.
>> * DnsAPIVirtualMachineDAO to manage DNS records for vms.
>> * DnsAPIElement, this class implements the provider itself.
>> * DnsAPIResource, implements all communications with DNSAPI
>> (ServerResource).
>>
>> Besides this classes, another one was necessary to the call to
>> DnsAPIResource and return the answer, and one API command was created to
>> configure the provider in Zone.
>>
>> Above a video that show you how everything was integrated.
>>
>> https://www.youtube.com/watch?v=fAB53T_NZMI
>>
>> We really appreciate all your comments about our implementation,
>>
>> thanks in advance
>> PS: Sorry about duplicated e-mail in mailing list, but I forget to use
>> DISCUSS and send using company e-mail)
>>
>>
>

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

[Silvano Nogueira Buback]

Hi Erik,

   At Globo, network domain always have exclusive names, based on zone name
and vlan number, so there is no conflict.

   At the point of view of plugin, if domain exists it will be used. If a
record exists, it will be overwritten. When you delete a network, dns
domain will be deleted too, doesn't matter if it exists before network
creation or not. Records in this domain will be removed too.

[]'s,

Silvano Buback



On Fri, Jun 13, 2014 at 3:52 AM, Erik Weber  wrote:

> On Fri, Jun 13, 2014 at 7:21 AM, Silvano Nogueira Buback <
> silv...@corp.globo.com> wrote:
>
> > Hi there,
> >
> >
> > I work at Globo.com, a media company in Brazil. Here we use a cloudstack
> > private network with an advanced zone setup (isolated vlans).
> >
> > For some couple of reasons, the name of virtual machine needs to be
> > available not only on virtual router network context, but on our internal
> > DNS servers.
> >
> > Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind
> server)
> > thru an open source API written by globo.com called DNSAPI. More info at
> > https://github.com/globocom/Dns-Api.
> >
> > To make this implementation of DNS provider, we based our plugin on
> > "dns-notifier", but we had to add more classes for our implementation.
> >
> > * DnsAPINetworkDAO to manage the networkDomain for each network.
> > * DnsAPIVirtualMachineDAO to manage DNS records for vms.
> > * DnsAPIElement, this class implements the provider itself.
> > * DnsAPIResource, implements all communications with DNSAPI
> > (ServerResource).
> >
> > Besides this classes, another one was necessary to the call to
> > DnsAPIResource and return the answer, and one API command was created to
> > configure the provider in Zone.
> >
> > Above a video that show you how everything was integrated.
> >
> > https://www.youtube.com/watch?v=fAB53T_NZMI
> >
> > We really appreciate all your comments about our implementation,
> >
>
>
> replying in the right thread this time :-)
>
> I like the idea and the fact that the backend is available as open source.
> That should make it pretty straight forward to convert it to other DNS
> solutions (PowerDNS for me).
>
> - What happens if there is a conflict?
> - Does it require / assume that the domain is non-existant on the DNS
> servers?
> - How does cleanup handle additional records added outside of CloudStack?
>
> --
> Erik Weber
>

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

[Silvano Nogueira Buback]

Hi Rohit,

I started the documentation and I think on next wednesday I'm with the
first version ready for community feedback. I will put the details of how
plugin work with DNSAPI and how DNSAPI work with bind.

I don't have permission to create new pages on wiki. I submit the
documentation to here or someone will give me access to update wiki?

[]'s,

Silvano Buback


On Fri, Jun 13, 2014 at 7:53 AM, Rohit Yadav  wrote:

> Hi Silvano,
>
> On Fri, Jun 13, 2014 at 10:51 AM, Silvano Nogueira Buback <
> silv...@corp.globo.com> wrote:
>
> > Hi there,
> >
> >
> > I work at Globo.com, a media company in Brazil. Here we use a cloudstack
> > private network with an advanced zone setup (isolated vlans).
> >
> > For some couple of reasons, the name of virtual machine needs to be
> > available not only on virtual router network context, but on our internal
> > DNS servers.
> >
> > Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind
> server)
> > thru an open source API written by globo.com called DNSAPI. More info at
> > https://github.com/globocom/Dns-Api.
> >
>
> Thanks for the proposal.
>
> I recommend that you document your design goals in 4.5 or above design docs
> wiki:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.5+Design+Documents
>
> I saw the video you shared, it looked seamless but I could not figure out
> how the ACS plugin interacts with the DNS provider. The API library you
> mentioned is written in Ruby, so how does it integrate or work with the dns
> plugin in ACS, is it over HTTP or RPC/Thrift?
>
> Regards.
>
>
> >
> > To make this implementation of DNS provider, we based our plugin on
> > "dns-notifier", but we had to add more classes for our implementation.
> >
> > * DnsAPINetworkDAO to manage the networkDomain for each network.
> > * DnsAPIVirtualMachineDAO to manage DNS records for vms.
> > * DnsAPIElement, this class implements the provider itself.
> > * DnsAPIResource, implements all communications with DNSAPI
> > (ServerResource).
> >
> > Besides this classes, another one was necessary to the call to
> > DnsAPIResource and return the answer, and one API command was created to
> > configure the provider in Zone.
> >
> > Above a video that show you how everything was integrated.
> >
> > https://www.youtube.com/watch?v=fAB53T_NZMI
> >
> > We really appreciate all your comments about our implementation,
> >
> > thanks in advance
> > PS: Sorry about duplicated e-mail in mailing list, but I forget to use
> > DISCUSS and send using company e-mail)
> >
>

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

[Silvano Nogueira Buback]

Hi Chiradeep,

   Bind server is configured per zone. We did not test with PowerDNS, but I
think they are able to talk because API is the same. We are configuring
bind server managed by "DNSAPI" as internal DNS in zone. So VR doesn't
provide more name resolution for network. I will put the details in
documentation.

Regards,

Silvano Buback
Globo.com Infra-structure Expert



On Mon, Jun 16, 2014 at 2:50 AM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> It looks like the DnsProvider calls the REST API of the RoR-based DNSAPI.
>
> +1, but as Rohit said, I’d love to see the design details on the Wiki.
> This will make it easier for folks like Erik to integrate PowerDns.
> Does the VR use the Bind server for name resolution? That is, is the Bind
> server the same as the zone DNS? Is this configured on a region level or a
> zone level? Or is it strictly per network offering?
>
> From: Rohit Yadav mailto:bhais...@apache.org>>
> Reply-To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Date: Friday, June 13, 2014 at 6:53 AM
> To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Subject: Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind
> (for 4.5)
>
> Hi Silvano,
>
> On Fri, Jun 13, 2014 at 10:51 AM, Silvano Nogueira Buback <
> silv...@corp.globo.com> wrote:
>
> Hi there,
>
>
> I work at Globo.com, a media company in Brazil. Here we use a cloudstack
> private network with an advanced zone setup (isolated vlans).
>
> For some couple of reasons, the name of virtual machine needs to be
> available not only on virtual router network context, but on our internal
> DNS servers.
>
> Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server)
> thru an open source API written by globo.com called DNSAPI. More info at
> https://github.com/globocom/Dns-Api.
>
>
> Thanks for the proposal.
>
> I recommend that you document your design goals in 4.5 or above design docs
> wiki:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.5+Design+Documents
>
> I saw the video you shared, it looked seamless but I could not figure out
> how the ACS plugin interacts with the DNS provider. The API library you
> mentioned is written in Ruby, so how does it integrate or work with the dns
> plugin in ACS, is it over HTTP or RPC/Thrift?
>
> Regards.
>
>
>
> To make this implementation of DNS provider, we based our plugin on
> "dns-notifier", but we had to add more classes for our implementation.
>
> * DnsAPINetworkDAO to manage the networkDomain for each network.
> * DnsAPIVirtualMachineDAO to manage DNS records for vms.
> * DnsAPIElement, this class implements the provider itself.
> * DnsAPIResource, implements all communications with DNSAPI
> (ServerResource).
>
> Besides this classes, another one was necessary to the call to
> DnsAPIResource and return the answer, and one API command was created to
> configure the provider in Zone.
>
> Above a video that show you how everything was integrated.
>
> https://www.youtube.com/watch?v=fAB53T_NZMI
>
> We really appreciate all your comments about our implementation,
>
> thanks in advance
> PS: Sorry about duplicated e-mail in mailing list, but I forget to use
> DISCUSS and send using company e-mail)
>
>
>

Re: Expected behavior for volume migration done after the download of volume

[Nitin Mehta]

There should have been only one entry created. Seems like both these
operations are working independently at the moment.
So when download volume happens you create a db entry in volume_store_ref.
You request migration of volume then it should not have to copy the volume
to sec. storage since it exists there already.
When migration is done you need to see that the url hasn't expired so you
shouldn¹t delete the entry and similarly when url expires you would have
to know that migration is in progress so you shouldn¹t delete the volume.
You need to figure out a mechanism so that this is solved elegantly (say
keeping a reference count, incrementing it when migration or download is
requested and then decrementing it once the operation is done or url is
expired)

Thanks,
-Nitin

On 19/06/14 1:51 AM, "Anshul Gangwar"  wrote:

>Hi,
>
>
>I am looking into fixing bug
>https://issues.apache.org/jira/browse/CLOUDSTACK-6900. When we download
>volume then we create entry for that volume in volume_store_ref table. We
>mark the volume in ready state. When we migrate that volume, then again
>one more entry is created with same volume id. Its state is marked as
>allocated. This way there are two entries in volume_store_ref table. In
>one case it is marked as allocated and in other case it is marked as in
>ready state.
>
>Later we try to list only one dataobject in datastore for state
>transition during volume migration. If the listed volume's state is
>allocated then it passes otherwise it fails.
>
>Download url expires after 4 hrs. After 4 hrs migration should pass as
>there will be unique dataobject in datastore for the volume.
>
>What should be the expected behavior in this transition period i.e. till
>the download volume of url expires?
>
>Thanks,
>
>Anshul
>
>

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

[Rohit Yadav]

On Thu, Jun 19, 2014 at 7:36 PM, Silvano Nogueira Buback <
silv...@corp.globo.com> wrote:

> Hi Rohit,
>
> I started the documentation and I think on next wednesday I'm with the
> first version ready for community feedback. I will put the details of how
> plugin work with DNSAPI and how DNSAPI work with bind.
>

That would be nice.


>
> I don't have permission to create new pages on wiki. I submit the
> documentation to here or someone will give me access to update wiki?
>

Create a user account on cwiki.a.o and share with us your
account/username/email. I don't have admin access but I'm sure someone such
as Daan or Chip would be able to help you.

Cheers.


> []'s,
>
> Silvano Buback
>
>
> On Fri, Jun 13, 2014 at 7:53 AM, Rohit Yadav  wrote:
>
> > Hi Silvano,
> >
> > On Fri, Jun 13, 2014 at 10:51 AM, Silvano Nogueira Buback <
> > silv...@corp.globo.com> wrote:
> >
> > > Hi there,
> > >
> > >
> > > I work at Globo.com, a media company in Brazil. Here we use a
> cloudstack
> > > private network with an advanced zone setup (isolated vlans).
> > >
> > > For some couple of reasons, the name of virtual machine needs to be
> > > available not only on virtual router network context, but on our
> internal
> > > DNS servers.
> > >
> > > Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind
> > server)
> > > thru an open source API written by globo.com called DNSAPI. More info
> at
> > > https://github.com/globocom/Dns-Api.
> > >
> >
> > Thanks for the proposal.
> >
> > I recommend that you document your design goals in 4.5 or above design
> docs
> > wiki:
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.5+Design+Documents
> >
> > I saw the video you shared, it looked seamless but I could not figure out
> > how the ACS plugin interacts with the DNS provider. The API library you
> > mentioned is written in Ruby, so how does it integrate or work with the
> dns
> > plugin in ACS, is it over HTTP or RPC/Thrift?
> >
> > Regards.
> >
> >
> > >
> > > To make this implementation of DNS provider, we based our plugin on
> > > "dns-notifier", but we had to add more classes for our implementation.
> > >
> > > * DnsAPINetworkDAO to manage the networkDomain for each network.
> > > * DnsAPIVirtualMachineDAO to manage DNS records for vms.
> > > * DnsAPIElement, this class implements the provider itself.
> > > * DnsAPIResource, implements all communications with DNSAPI
> > > (ServerResource).
> > >
> > > Besides this classes, another one was necessary to the call to
> > > DnsAPIResource and return the answer, and one API command was created
> to
> > > configure the provider in Zone.
> > >
> > > Above a video that show you how everything was integrated.
> > >
> > > https://www.youtube.com/watch?v=fAB53T_NZMI
> > >
> > > We really appreciate all your comments about our implementation,
> > >
> > > thanks in advance
> > > PS: Sorry about duplicated e-mail in mailing list, but I forget to use
> > > DISCUSS and send using company e-mail)
> > >
> >
>

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

[Silvano Buback]

Of course, I forgotten my account info:
snbuback / silv...@corp.globo.com


On Thu, Jun 19, 2014 at 11:20 AM, Rohit Yadav  wrote:

> On Thu, Jun 19, 2014 at 7:36 PM, Silvano Nogueira Buback <
> silv...@corp.globo.com> wrote:
>
> > Hi Rohit,
> >
> > I started the documentation and I think on next wednesday I'm with
> the
> > first version ready for community feedback. I will put the details of how
> > plugin work with DNSAPI and how DNSAPI work with bind.
> >
>
> That would be nice.
>
>
> >
> > I don't have permission to create new pages on wiki. I submit the
> > documentation to here or someone will give me access to update wiki?
> >
>
> Create a user account on cwiki.a.o and share with us your
> account/username/email. I don't have admin access but I'm sure someone such
> as Daan or Chip would be able to help you.
>
> Cheers.
>
>
> > []'s,
> >
> > Silvano Buback
> >
> >
> > On Fri, Jun 13, 2014 at 7:53 AM, Rohit Yadav 
> wrote:
> >
> > > Hi Silvano,
> > >
> > > On Fri, Jun 13, 2014 at 10:51 AM, Silvano Nogueira Buback <
> > > silv...@corp.globo.com> wrote:
> > >
> > > > Hi there,
> > > >
> > > >
> > > > I work at Globo.com, a media company in Brazil. Here we use a
> > cloudstack
> > > > private network with an advanced zone setup (isolated vlans).
> > > >
> > > > For some couple of reasons, the name of virtual machine needs to be
> > > > available not only on virtual router network context, but on our
> > internal
> > > > DNS servers.
> > > >
> > > > Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind
> > > server)
> > > > thru an open source API written by globo.com called DNSAPI. More
> info
> > at
> > > > https://github.com/globocom/Dns-Api.
> > > >
> > >
> > > Thanks for the proposal.
> > >
> > > I recommend that you document your design goals in 4.5 or above design
> > docs
> > > wiki:
> > >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.5+Design+Documents
> > >
> > > I saw the video you shared, it looked seamless but I could not figure
> out
> > > how the ACS plugin interacts with the DNS provider. The API library you
> > > mentioned is written in Ruby, so how does it integrate or work with the
> > dns
> > > plugin in ACS, is it over HTTP or RPC/Thrift?
> > >
> > > Regards.
> > >
> > >
> > > >
> > > > To make this implementation of DNS provider, we based our plugin on
> > > > "dns-notifier", but we had to add more classes for our
> implementation.
> > > >
> > > > * DnsAPINetworkDAO to manage the networkDomain for each network.
> > > > * DnsAPIVirtualMachineDAO to manage DNS records for vms.
> > > > * DnsAPIElement, this class implements the provider itself.
> > > > * DnsAPIResource, implements all communications with DNSAPI
> > > > (ServerResource).
> > > >
> > > > Besides this classes, another one was necessary to the call to
> > > > DnsAPIResource and return the answer, and one API command was created
> > to
> > > > configure the provider in Zone.
> > > >
> > > > Above a video that show you how everything was integrated.
> > > >
> > > > https://www.youtube.com/watch?v=fAB53T_NZMI
> > > >
> > > > We really appreciate all your comments about our implementation,
> > > >
> > > > thanks in advance
> > > > PS: Sorry about duplicated e-mail in mailing list, but I forget to
> use
> > > > DISCUSS and send using company e-mail)
> > > >
> > >
> >
>

Re: Can we delete a template after a VM is instantiated from it?

[Rafael Weingartner]

Bug filed https://issues.apache.org/jira/browse/CLOUDSTACK-6945.
BTW: Why in Jira is the Version 4.3.0 marked as unreleased ? Is it also a
bug !?



On Wed, Jun 18, 2014 at 9:13 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Google CloudStack JIRA.
>
> Create an account and you should be able to log a bug.
>
> On Wednesday, June 18, 2014, Rafael Weingartner <
> rafaelweingart...@gmail.com>
> wrote:
>
> > Sure, I can do that.
> > I also think that it is a bug.
> > sorry if it seems a dumb question, but, how can I file a bug report?
> >
> >
> > On Wed, Jun 18, 2014 at 8:24 PM, Min Chen  > > wrote:
> >
> > > This seems a bug to me, start vm should not rely on the template not
> > > deleted. Please file a bug for that.
> > >
> > > Thanks
> > > -min
> > >
> > > On 6/16/14 10:33 AM, "Rafael Weingartner"  > >
> > > wrote:
> > >
> > > >This way, it seems that you have a bug in CS 4.3.0 when starting a
> > machine
> > > >that was created from a template that has been deleted.
> > > >
> > > >
> > > >There will happen a null pointer exception in:
> > > >³858 -if (volTemplateId != null && volTemplateId.longValue()
> !=
> > > >template.getId())²
> > > >
> > > >The object, ³template² is going to be null, because in:
> > > >
> > > >³811 -  VirtualMachineTemplate template =
> > > >_entityMgr.findById(VirtualMachineTemplate.class,
> vm.getTemplateId());²
> > > >
> > > >The findById, will add a where clause, looking for template that have
> > the
> > > >column removed that is null, therefore It will return a null object.
> > > >
> > > >
> > > >
> > > >On Mon, Jun 16, 2014 at 4:41 AM, Nux! >
> > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> You can remove it from the UI, but not directly from the disk as it
> is
> > > >> used (in many cases) as a backing file for the VMs spawned from it.
> > > >>
> > > >> HTH
> > > >> Lucian
> > > >>
> > > >> --
> > > >> Sent from the Delta quadrant using Borg technology!
> > > >>
> > > >> Nux!
> > > >> www.nux.ro
> > > >>
> > > >> - Original Message -
> > > >> From: "Sanjeev Neelarapu"  > >
> > > >> To: dev@cloudstack.apache.org 
> > > >> Sent: Monday, 16 June, 2014 5:18:04 AM
> > > >> Subject: RE: Can we delete a template after a VM is instantiated
> from
> > > >>it?
> > > >>
> > > >> We can delete template without any issues.
> > > >>
> > > >> -Sanjeev
> > > >>
> > > >> -Original Message-
> > > >> From: Rafael Weingartner [mailto:rafaelweingart...@gmail.com
> > ]
> > > >> Sent: Sunday, June 15, 2014 8:48 PM
> > > >> To: dev@cloudstack.apache.org 
> > > >> Subject: Can we delete a template after a VM is instantiated from
> it?
> > > >>
> > > >>  Hi,
> > > >>
> > > >> I was wondering if we can delete a template that has already been
> used
> > > >>to
> > > >> instantiate some VMs.
> > > >>
> > > >> Would that cause any trouble?
> > > >>
> > > >> --
> > > >> Rafael Weingärtner
> > > >>
> > > >
> > > >
> > > >
> > > >--
> > > >Rafael Weingärtner
> > >
> > >
> >
> >
> > --
> > Rafael Weingärtner
> >
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>



-- 
Rafael Weingärtner

Re: IOPS throttling setting isn't applied to a dinamically attached volume

[Yoshikazu Nojima]

Daan,

Thank you for explanation.
I understand.
I will create a ticket with "critical" and bring up to the dev ML if
it need to be treated as "blocker" from now on.

Thanks,
Noji



2014-06-19 1:30 GMT-06:00 Daan Hoogland :
> There are no strict definitions, but a blocker is something that
> should be discussed on list in my opinion, as it is something that
> implies a release is being blocked (and unusable if brought out
> anyway). Maybe you where right to make your issue a blocker but I
> would like to be convinced of that on list by discussion before we
> mark it as such. This also ensures that enough devs are aware that we
> have such an issue.
>
> hope you understand,
>
> On Wed, Jun 18, 2014 at 7:29 PM, Yoshikazu Nojima  wrote:
>> Daan,
>>
>> Could you let me know the definitions of each priorities in ACS
>> project (or a document that describe the definition)?
>> Sometimes I'm confused which priority to use.
>>
>> Thanks,
>> Noji
>>
>>
>> 2014-06-18 6:09 GMT-06:00 Daan Hoogland :
>>> H,
>>>
>>> Yoshikazu Nojima created an issue as blocker that I immediately set to
>>> critical out of principle. I do want to mention it here though,
>>> because it might be important enough to mark as a blocker after all.
>>>
>>> any expert on the title have extensive opinionated comments on it?
>>>
>>> --
>>> Daan
>
>
>
> --
> Daan

Re: [POLL] Who uses "awsapi" with CloudStack in production?

[Carlos Reátegui]

Hi Daan,

I have not tried 4.3.  I saw some of the issues people were having and decided 
to hold off from trying.

Do you suggest I try with 4.3 or should I build my own deb packages and try 4.4?

BTW I am on ubuntu 12.04 + XenServer 6.0.2


On Jun 19, 2014, at 12:35 AM, Daan Hoogland  wrote:

> Carlos, please export your db and do a test upgrade on a lab machine?
> Now is the time to solve any upgrade issues in 4.4.
> 
> Have you tried the 4.3 upgrade already?
> 
> regards,
> Daan
> 
> On Wed, Jun 18, 2014 at 7:04 PM, Carlos Reátegui  wrote:
>> Hi Rohit,
>> 
>> The awsapi was one of the reasons we chose to use ACS.  We have developed 
>> some internal tools and apps to manage our deployments on AWS that we want 
>> to re-use on ACS.  We have not been able to use it yet because it was broken 
>> in 4.1.1.  We tried to upgrade to 4.2 and were unsuccessful and are now 
>> waiting for 4.4 to finally upgrade and hopefully be able to use the awsapi.
>> 
>> We use ACS internally for development and testing of our applications that 
>> we push to AWS.
>> 
>> thanks,
>> Carlos
>> 
>> 
>> On Jun 18, 2014, at 12:11 AM, Rohit Yadav  wrote:
>> 
>>> Hi,
>>> 
>>> Who uses "awsapi" or any other EC2 compatible interface such as ec2stack
>>> with CloudStack (or CloudStack distros such as Citrix CloudPlatform) in
>>> production? And, if marketing and publicity are/were big motivation(s)?
>>> 
>>> In case you don't want to discuss on this thread, please take this
>>> anonymous poll:
>>> http://www.polljunkie.com/poll/fbyfdc/who-uses-awsapi-with-cloudstack-in-prouduction
>>> 
>>> # Some stats
>>> 
>>> I've been watching Collab14 videos and found references where many speakers
>>> reference overall CloudStack codebase to be about 1.5M (million) lines of
>>> Java code which is not "exactly" true. Let me share some findings;
>>> 
>>> - As of today, CloudStack master is about 1.7M lines of Java code [1]
>>> - CloudStack "awsapi" artifact is 1.04M lines of Java code [2]
>>> - Code excluding "awsapi", tests and license/comment is about 590k lines of
>>> Java code [3]
>>> - The core excluding plugins, api and the above is about 300k lines of Java
>>> code [4]
>>> 
>>> Why should  I care:
>>> - some useful/fun stats to keep in mind
>>> - it's not a giant mammoth that cannot be fixed or developed upon
>>> - encouraging for new developers that if they try they can understand and
>>> fix it
>>> 
>>> FYI, this started on twitter yesterday:
>>> https://twitter.com/_bhaisaab/status/479007075414974465
>>> 
>>> [1] cd cloudstack-repo && find . | grep java$ | xargs cat | wc -l
>>> [2] cd cloudstack-repo && find awsapi | grep java$ | xargs cat | wc -l
>>> [3] cd cloudstack-repo && find . | grep -v awsapi | grep -v [tT]est | grep
>>> java$ | xargs cat | grep -v '^//' | wc -l
>>> [4] cd cloudstack-repo && find . | grep -v awsapi | grep -v [Tt]est | grep
>>> -v plugins | grep -v api | grep java$ | xargs cat | grep -v '^//' | wc -l
>>> 
>>> Regards.
>> 
> 
> 
> 
> -- 
> Daan

Re: [POLL] Who uses "awsapi" with CloudStack in production?

[Daan Hoogland]

I am saying you should export your db and run a test upgrade against it
using the 4.4 branch so we can make sure it works correctly by the time we
release.
Op 19 jun. 2014 19:10 schreef "Carlos Reátegui" :

> Hi Daan,
>
> I have not tried 4.3.  I saw some of the issues people were having and
> decided to hold off from trying.
>
> Do you suggest I try with 4.3 or should I build my own deb packages and
> try 4.4?
>
> BTW I am on ubuntu 12.04 + XenServer 6.0.2
>
>
> On Jun 19, 2014, at 12:35 AM, Daan Hoogland 
> wrote:
>
> > Carlos, please export your db and do a test upgrade on a lab machine?
> > Now is the time to solve any upgrade issues in 4.4.
> >
> > Have you tried the 4.3 upgrade already?
> >
> > regards,
> > Daan
> >
> > On Wed, Jun 18, 2014 at 7:04 PM, Carlos Reátegui 
> wrote:
> >> Hi Rohit,
> >>
> >> The awsapi was one of the reasons we chose to use ACS.  We have
> developed some internal tools and apps to manage our deployments on AWS
> that we want to re-use on ACS.  We have not been able to use it yet because
> it was broken in 4.1.1.  We tried to upgrade to 4.2 and were unsuccessful
> and are now waiting for 4.4 to finally upgrade and hopefully be able to use
> the awsapi.
> >>
> >> We use ACS internally for development and testing of our applications
> that we push to AWS.
> >>
> >> thanks,
> >> Carlos
> >>
> >>
> >> On Jun 18, 2014, at 12:11 AM, Rohit Yadav  wrote:
> >>
> >>> Hi,
> >>>
> >>> Who uses "awsapi" or any other EC2 compatible interface such as
> ec2stack
> >>> with CloudStack (or CloudStack distros such as Citrix CloudPlatform) in
> >>> production? And, if marketing and publicity are/were big motivation(s)?
> >>>
> >>> In case you don't want to discuss on this thread, please take this
> >>> anonymous poll:
> >>>
> http://www.polljunkie.com/poll/fbyfdc/who-uses-awsapi-with-cloudstack-in-prouduction
> >>>
> >>> # Some stats
> >>>
> >>> I've been watching Collab14 videos and found references where many
> speakers
> >>> reference overall CloudStack codebase to be about 1.5M (million) lines
> of
> >>> Java code which is not "exactly" true. Let me share some findings;
> >>>
> >>> - As of today, CloudStack master is about 1.7M lines of Java code [1]
> >>> - CloudStack "awsapi" artifact is 1.04M lines of Java code [2]
> >>> - Code excluding "awsapi", tests and license/comment is about 590k
> lines of
> >>> Java code [3]
> >>> - The core excluding plugins, api and the above is about 300k lines of
> Java
> >>> code [4]
> >>>
> >>> Why should  I care:
> >>> - some useful/fun stats to keep in mind
> >>> - it's not a giant mammoth that cannot be fixed or developed upon
> >>> - encouraging for new developers that if they try they can understand
> and
> >>> fix it
> >>>
> >>> FYI, this started on twitter yesterday:
> >>> https://twitter.com/_bhaisaab/status/479007075414974465
> >>>
> >>> [1] cd cloudstack-repo && find . | grep java$ | xargs cat | wc -l
> >>> [2] cd cloudstack-repo && find awsapi | grep java$ | xargs cat | wc -l
> >>> [3] cd cloudstack-repo && find . | grep -v awsapi | grep -v [tT]est |
> grep
> >>> java$ | xargs cat | grep -v '^//' | wc -l
> >>> [4] cd cloudstack-repo && find . | grep -v awsapi | grep -v [Tt]est |
> grep
> >>> -v plugins | grep -v api | grep java$ | xargs cat | grep -v '^//' | wc
> -l
> >>>
> >>> Regards.
> >>
> >
> >
> >
> > --
> > Daan
>
>

Re: [POLL] Who uses "awsapi" with CloudStack in production?

[Rohit Yadav]

On Thu, Jun 19, 2014 at 10:39 PM, Carlos Reátegui 
wrote:

> Hi Daan,
>
> I have not tried 4.3.  I saw some of the issues people were having and
> decided to hold off from trying.
>
> Do you suggest I try with 4.3 or should I build my own deb packages and
> try 4.4?
>
> BTW I am on ubuntu 12.04 + XenServer 6.0.2
>

Carlos, Daan is suggesting that you help us test our upcoming 4.4 release
:) using the 4.4 branch [1]

[1] https://github.com/apache/cloudstack/tree/4.4

Cheers.


>
>
> On Jun 19, 2014, at 12:35 AM, Daan Hoogland 
> wrote:
>
> > Carlos, please export your db and do a test upgrade on a lab machine?
> > Now is the time to solve any upgrade issues in 4.4.
> >
> > Have you tried the 4.3 upgrade already?
> >
> > regards,
> > Daan
> >
> > On Wed, Jun 18, 2014 at 7:04 PM, Carlos Reátegui 
> wrote:
> >> Hi Rohit,
> >>
> >> The awsapi was one of the reasons we chose to use ACS.  We have
> developed some internal tools and apps to manage our deployments on AWS
> that we want to re-use on ACS.  We have not been able to use it yet because
> it was broken in 4.1.1.  We tried to upgrade to 4.2 and were unsuccessful
> and are now waiting for 4.4 to finally upgrade and hopefully be able to use
> the awsapi.
> >>
> >> We use ACS internally for development and testing of our applications
> that we push to AWS.
> >>
> >> thanks,
> >> Carlos
> >>
> >>
> >> On Jun 18, 2014, at 12:11 AM, Rohit Yadav  wrote:
> >>
> >>> Hi,
> >>>
> >>> Who uses "awsapi" or any other EC2 compatible interface such as
> ec2stack
> >>> with CloudStack (or CloudStack distros such as Citrix CloudPlatform) in
> >>> production? And, if marketing and publicity are/were big motivation(s)?
> >>>
> >>> In case you don't want to discuss on this thread, please take this
> >>> anonymous poll:
> >>>
> http://www.polljunkie.com/poll/fbyfdc/who-uses-awsapi-with-cloudstack-in-prouduction
> >>>
> >>> # Some stats
> >>>
> >>> I've been watching Collab14 videos and found references where many
> speakers
> >>> reference overall CloudStack codebase to be about 1.5M (million) lines
> of
> >>> Java code which is not "exactly" true. Let me share some findings;
> >>>
> >>> - As of today, CloudStack master is about 1.7M lines of Java code [1]
> >>> - CloudStack "awsapi" artifact is 1.04M lines of Java code [2]
> >>> - Code excluding "awsapi", tests and license/comment is about 590k
> lines of
> >>> Java code [3]
> >>> - The core excluding plugins, api and the above is about 300k lines of
> Java
> >>> code [4]
> >>>
> >>> Why should  I care:
> >>> - some useful/fun stats to keep in mind
> >>> - it's not a giant mammoth that cannot be fixed or developed upon
> >>> - encouraging for new developers that if they try they can understand
> and
> >>> fix it
> >>>
> >>> FYI, this started on twitter yesterday:
> >>> https://twitter.com/_bhaisaab/status/479007075414974465
> >>>
> >>> [1] cd cloudstack-repo && find . | grep java$ | xargs cat | wc -l
> >>> [2] cd cloudstack-repo && find awsapi | grep java$ | xargs cat | wc -l
> >>> [3] cd cloudstack-repo && find . | grep -v awsapi | grep -v [tT]est |
> grep
> >>> java$ | xargs cat | grep -v '^//' | wc -l
> >>> [4] cd cloudstack-repo && find . | grep -v awsapi | grep -v [Tt]est |
> grep
> >>> -v plugins | grep -v api | grep java$ | xargs cat | grep -v '^//' | wc
> -l
> >>>
> >>> Regards.
> >>
> >
> >
> >
> > --
> > Daan
>
>

Re: [POLL] Who uses "awsapi" with CloudStack in production?

[Carlos Reategui]

I can do that.

My current install is from the repo http://cloudstack.apt-get.eu/ubuntu.
 Do you know if that is built with -Dnoredist? I would like to make sure I
build and package the same way.

Thanks
Carlos


On Thu, Jun 19, 2014 at 11:35 AM, Rohit Yadav  wrote:

> On Thu, Jun 19, 2014 at 10:39 PM, Carlos Reátegui 
> wrote:
>
> > Hi Daan,
> >
> > I have not tried 4.3.  I saw some of the issues people were having and
> > decided to hold off from trying.
> >
> > Do you suggest I try with 4.3 or should I build my own deb packages and
> > try 4.4?
> >
> > BTW I am on ubuntu 12.04 + XenServer 6.0.2
> >
>
> Carlos, Daan is suggesting that you help us test our upcoming 4.4 release
> :) using the 4.4 branch [1]
>
> [1] https://github.com/apache/cloudstack/tree/4.4
>
> Cheers.
>
>
> >
> >
> > On Jun 19, 2014, at 12:35 AM, Daan Hoogland 
> > wrote:
> >
> > > Carlos, please export your db and do a test upgrade on a lab machine?
> > > Now is the time to solve any upgrade issues in 4.4.
> > >
> > > Have you tried the 4.3 upgrade already?
> > >
> > > regards,
> > > Daan
> > >
> > > On Wed, Jun 18, 2014 at 7:04 PM, Carlos Reátegui 
> > wrote:
> > >> Hi Rohit,
> > >>
> > >> The awsapi was one of the reasons we chose to use ACS.  We have
> > developed some internal tools and apps to manage our deployments on AWS
> > that we want to re-use on ACS.  We have not been able to use it yet
> because
> > it was broken in 4.1.1.  We tried to upgrade to 4.2 and were unsuccessful
> > and are now waiting for 4.4 to finally upgrade and hopefully be able to
> use
> > the awsapi.
> > >>
> > >> We use ACS internally for development and testing of our applications
> > that we push to AWS.
> > >>
> > >> thanks,
> > >> Carlos
> > >>
> > >>
> > >> On Jun 18, 2014, at 12:11 AM, Rohit Yadav 
> wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> Who uses "awsapi" or any other EC2 compatible interface such as
> > ec2stack
> > >>> with CloudStack (or CloudStack distros such as Citrix CloudPlatform)
> in
> > >>> production? And, if marketing and publicity are/were big
> motivation(s)?
> > >>>
> > >>> In case you don't want to discuss on this thread, please take this
> > >>> anonymous poll:
> > >>>
> >
> http://www.polljunkie.com/poll/fbyfdc/who-uses-awsapi-with-cloudstack-in-prouduction
> > >>>
> > >>> # Some stats
> > >>>
> > >>> I've been watching Collab14 videos and found references where many
> > speakers
> > >>> reference overall CloudStack codebase to be about 1.5M (million)
> lines
> > of
> > >>> Java code which is not "exactly" true. Let me share some findings;
> > >>>
> > >>> - As of today, CloudStack master is about 1.7M lines of Java code [1]
> > >>> - CloudStack "awsapi" artifact is 1.04M lines of Java code [2]
> > >>> - Code excluding "awsapi", tests and license/comment is about 590k
> > lines of
> > >>> Java code [3]
> > >>> - The core excluding plugins, api and the above is about 300k lines
> of
> > Java
> > >>> code [4]
> > >>>
> > >>> Why should  I care:
> > >>> - some useful/fun stats to keep in mind
> > >>> - it's not a giant mammoth that cannot be fixed or developed upon
> > >>> - encouraging for new developers that if they try they can understand
> > and
> > >>> fix it
> > >>>
> > >>> FYI, this started on twitter yesterday:
> > >>> https://twitter.com/_bhaisaab/status/479007075414974465
> > >>>
> > >>> [1] cd cloudstack-repo && find . | grep java$ | xargs cat | wc -l
> > >>> [2] cd cloudstack-repo && find awsapi | grep java$ | xargs cat | wc
> -l
> > >>> [3] cd cloudstack-repo && find . | grep -v awsapi | grep -v [tT]est |
> > grep
> > >>> java$ | xargs cat | grep -v '^//' | wc -l
> > >>> [4] cd cloudstack-repo && find . | grep -v awsapi | grep -v [Tt]est |
> > grep
> > >>> -v plugins | grep -v api | grep java$ | xargs cat | grep -v '^//' |
> wc
> > -l
> > >>>
> > >>> Regards.
> > >>
> > >
> > >
> > >
> > > --
> > > Daan
> >
> >
>

Re: [POLL] Who uses "awsapi" with CloudStack in production?

[Rohit Yadav]

On Fri, Jun 20, 2014 at 12:22 AM, Carlos Reategui 
wrote:

> I can do that.
>
> My current install is from the repo http://cloudstack.apt-get.eu/ubuntu.
>  Do you know if that is built with -Dnoredist? I would like to make sure I
> build and package the same way.
>

Wido maintains it and only hosts released versions of CloudStack and AFAIK
we don't have an active nightlies debian build repo for users.

That means, you'll have to build from source which is not very hard to do
(you may even automate it):

1. Download the 4.4 branch zipball:
https://github.com/apache/cloudstack/archive/4.4.zip

2. Follow this:

http://cloudstack-installation.readthedocs.org/en/latest/building_from_source.html#prerequisites-for-building-apache-cloudstack

If you're stuck or have any issues reach out to the community, we're good
people :)

@Wido: Hey! Can you start the nightlies again so users don't have to do
debian builds themselves?

Regards.


>
> Thanks
> Carlos
>
>
> On Thu, Jun 19, 2014 at 11:35 AM, Rohit Yadav  wrote:
>
> > On Thu, Jun 19, 2014 at 10:39 PM, Carlos Reátegui 
> > wrote:
> >
> > > Hi Daan,
> > >
> > > I have not tried 4.3.  I saw some of the issues people were having and
> > > decided to hold off from trying.
> > >
> > > Do you suggest I try with 4.3 or should I build my own deb packages and
> > > try 4.4?
> > >
> > > BTW I am on ubuntu 12.04 + XenServer 6.0.2
> > >
> >
> > Carlos, Daan is suggesting that you help us test our upcoming 4.4 release
> > :) using the 4.4 branch [1]
> >
> > [1] https://github.com/apache/cloudstack/tree/4.4
> >
> > Cheers.
> >
> >
> > >
> > >
> > > On Jun 19, 2014, at 12:35 AM, Daan Hoogland 
> > > wrote:
> > >
> > > > Carlos, please export your db and do a test upgrade on a lab machine?
> > > > Now is the time to solve any upgrade issues in 4.4.
> > > >
> > > > Have you tried the 4.3 upgrade already?
> > > >
> > > > regards,
> > > > Daan
> > > >
> > > > On Wed, Jun 18, 2014 at 7:04 PM, Carlos Reátegui <
> create...@gmail.com>
> > > wrote:
> > > >> Hi Rohit,
> > > >>
> > > >> The awsapi was one of the reasons we chose to use ACS.  We have
> > > developed some internal tools and apps to manage our deployments on AWS
> > > that we want to re-use on ACS.  We have not been able to use it yet
> > because
> > > it was broken in 4.1.1.  We tried to upgrade to 4.2 and were
> unsuccessful
> > > and are now waiting for 4.4 to finally upgrade and hopefully be able to
> > use
> > > the awsapi.
> > > >>
> > > >> We use ACS internally for development and testing of our
> applications
> > > that we push to AWS.
> > > >>
> > > >> thanks,
> > > >> Carlos
> > > >>
> > > >>
> > > >> On Jun 18, 2014, at 12:11 AM, Rohit Yadav 
> > wrote:
> > > >>
> > > >>> Hi,
> > > >>>
> > > >>> Who uses "awsapi" or any other EC2 compatible interface such as
> > > ec2stack
> > > >>> with CloudStack (or CloudStack distros such as Citrix
> CloudPlatform)
> > in
> > > >>> production? And, if marketing and publicity are/were big
> > motivation(s)?
> > > >>>
> > > >>> In case you don't want to discuss on this thread, please take this
> > > >>> anonymous poll:
> > > >>>
> > >
> >
> http://www.polljunkie.com/poll/fbyfdc/who-uses-awsapi-with-cloudstack-in-prouduction
> > > >>>
> > > >>> # Some stats
> > > >>>
> > > >>> I've been watching Collab14 videos and found references where many
> > > speakers
> > > >>> reference overall CloudStack codebase to be about 1.5M (million)
> > lines
> > > of
> > > >>> Java code which is not "exactly" true. Let me share some findings;
> > > >>>
> > > >>> - As of today, CloudStack master is about 1.7M lines of Java code
> [1]
> > > >>> - CloudStack "awsapi" artifact is 1.04M lines of Java code [2]
> > > >>> - Code excluding "awsapi", tests and license/comment is about 590k
> > > lines of
> > > >>> Java code [3]
> > > >>> - The core excluding plugins, api and the above is about 300k lines
> > of
> > > Java
> > > >>> code [4]
> > > >>>
> > > >>> Why should  I care:
> > > >>> - some useful/fun stats to keep in mind
> > > >>> - it's not a giant mammoth that cannot be fixed or developed upon
> > > >>> - encouraging for new developers that if they try they can
> understand
> > > and
> > > >>> fix it
> > > >>>
> > > >>> FYI, this started on twitter yesterday:
> > > >>> https://twitter.com/_bhaisaab/status/479007075414974465
> > > >>>
> > > >>> [1] cd cloudstack-repo && find . | grep java$ | xargs cat | wc -l
> > > >>> [2] cd cloudstack-repo && find awsapi | grep java$ | xargs cat | wc
> > -l
> > > >>> [3] cd cloudstack-repo && find . | grep -v awsapi | grep -v
> [tT]est |
> > > grep
> > > >>> java$ | xargs cat | grep -v '^//' | wc -l
> > > >>> [4] cd cloudstack-repo && find . | grep -v awsapi | grep -v
> [Tt]est |
> > > grep
> > > >>> -v plugins | grep -v api | grep java$ | xargs cat | grep -v '^//' |
> > wc
> > > -l
> > > >>>
> > > >>> Regards.
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Daan
> > >
> > >
> >
>

[GitHub] cloudstack-docs-install pull request: fix sudo command to create d...

[creategui]

GitHub user creategui opened a pull request:

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

fix sudo command to create debian Packages file

sudo command was not working due to shell redirection.

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

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

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

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

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

This closes #16


commit d9158e6a148bed38df11e5118a5a789bc67acf8c
Author: Carlos Reategui 
Date:   2014-06-20T01:02:46Z

fix sudo command to create debian Packages file




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

Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

As discussed in mailing list, this patch is applied for golden primary storage 
in [1].
I have changed the term from "golden" to "base" because there are some 
functions and variables in CloudStack also use "base" for base image.
This patch only apply for Xen Server.

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


Diffs
-

  api/src/com/cloud/deploy/DeployDestination.java 
4ded5ebe7a18252da471ee25019856f2b2f772e0 
  api/src/com/cloud/storage/StoragePool.java 
8e03c3348f3a6dd3156ab9e440126ea317957dc0 
  api/src/com/cloud/template/VirtualMachineTemplate.java 
599212bb039fdbb78511019e8f0a6ea4b4a84440 
  api/src/org/apache/cloudstack/api/ApiConstants.java 
ae5d6f05b6b52f60b151369a641cb11fcbb558af 
  api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 
2350f6b389203e2c6cc2182fe03fe9a95e936b81 
  
api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
 ae44bc9373232d242e4ebdcf76844969f0fe69fc 
  
api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
 3d1a77353257c814efaf60875ffdf99603bc414e 
  
api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
 f478c9bc8eebf867a03deb4add1bf695ac3ec0ad 
  api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 
3571866fe74dca9aa5fe0d11373313eab97e94ac 
  api/src/org/apache/cloudstack/api/response/TemplateResponse.java 
3e21043e339103c021d3c9e767acac8b3837f760 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java PRE-CREATION 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java PRE-CREATION 
  core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java 
29e53b0d9581f764a17ea285606213d2c045b029 
  core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java 
b201c386f4975913f13c575d7685e50cedc7d92f 
  core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
33361e87265df05e00bfa6dba810d2b68ae8d923 
  core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java 
66feaecb5ef20053db50956e2801fec096a350c9 
  core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
114c8854d1504436523aa99c78bf2b4d84a12077 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
 1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
 dfdbd8ab92c47799f6ad23637fa63e030f0be968 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
 f93f4efac83c565cd33eb7eb67dcaca335f1c226 
  engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java 
ee6721ab445a5222d0087dc9170e0b58f9eef91a 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
4aa5fc80d9660d2f985db98124c33465bd99767f 
  
engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
 b1ac2f853374d6f1ddd9087919dbc16db0433f59 
  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 6256e2526ef9bd4632a5e3873c4d9531eb301c7f 
  engine/schema/src/com/cloud/storage/VMTemplateVO.java 
9a77cbf873aa9e422985fbcdc0ae7e18b8c78d4c 
  engine/schema/src/com/cloud/storage/VolumeVO.java 
e328253a596891029c2b55bea81b7ead425251ee 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
 a976bfbf6fe46306d20ad939c335bba6b9b7be54 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
 92793f1fb1a08a455a78667ba4a39ae162378360 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/StoragePoolVO.java 
1508ce0b28c83968c25d9601b6dae34e1a73dbb0 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/store/TemplateObject.java
 7288d454c30fdb81445e43549145f1f2da8533e4 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/ClusterScopeStoragePoolAllocator.java
 ea084c7555468001a12376640d9785b1cf852948 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
 446e101141bafde28615d766fdffd3a36ee8f3ce 
  
engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java 
c1aa8c2f0d49eb6bc6ff124dd4d87b7b714f62e9 
  
engine/storage/src/org/apache/cloudstack/storage/volume/datastore/PrimaryDataStoreHelper.java
 6b129755009413faae6685a62cfb3ae7b62b42f3 
  
engine/storage/volume/src/org/apache/cloudstack/storage/datastore/PrimaryDataStoreImpl.java
 f3c9e790277a4dc27fa9e572138c5d932be87b74 
  
engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeObject.java
 f2b4c9532a62ae917b351574523cc8b3014a4394 
  
engine/storage/volume/src/org/apache/cloud

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

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

(Updated June 20, 2014, 1:41 a.m.)


Review request for cloudstack.


Repository: cloudstack-git


Description
---

As discussed in mailing list, this patch is applied for golden primary storage 
in [1].
I have changed the term from "golden" to "base" because there are some 
functions and variables in CloudStack also use "base" for base image.
This patch only apply for Xen Server.

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


Diffs
-

  api/src/com/cloud/deploy/DeployDestination.java 
4ded5ebe7a18252da471ee25019856f2b2f772e0 
  api/src/com/cloud/storage/StoragePool.java 
8e03c3348f3a6dd3156ab9e440126ea317957dc0 
  api/src/com/cloud/template/VirtualMachineTemplate.java 
599212bb039fdbb78511019e8f0a6ea4b4a84440 
  api/src/org/apache/cloudstack/api/ApiConstants.java 
ae5d6f05b6b52f60b151369a641cb11fcbb558af 
  api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 
2350f6b389203e2c6cc2182fe03fe9a95e936b81 
  
api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
 ae44bc9373232d242e4ebdcf76844969f0fe69fc 
  
api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
 3d1a77353257c814efaf60875ffdf99603bc414e 
  
api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
 f478c9bc8eebf867a03deb4add1bf695ac3ec0ad 
  api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 
3571866fe74dca9aa5fe0d11373313eab97e94ac 
  api/src/org/apache/cloudstack/api/response/TemplateResponse.java 
3e21043e339103c021d3c9e767acac8b3837f760 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java PRE-CREATION 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java PRE-CREATION 
  core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java 
29e53b0d9581f764a17ea285606213d2c045b029 
  core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java 
b201c386f4975913f13c575d7685e50cedc7d92f 
  core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
33361e87265df05e00bfa6dba810d2b68ae8d923 
  core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java 
66feaecb5ef20053db50956e2801fec096a350c9 
  core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
114c8854d1504436523aa99c78bf2b4d84a12077 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
 1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
 dfdbd8ab92c47799f6ad23637fa63e030f0be968 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
 f93f4efac83c565cd33eb7eb67dcaca335f1c226 
  engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java 
ee6721ab445a5222d0087dc9170e0b58f9eef91a 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
4aa5fc80d9660d2f985db98124c33465bd99767f 
  
engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
 b1ac2f853374d6f1ddd9087919dbc16db0433f59 
  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 6256e2526ef9bd4632a5e3873c4d9531eb301c7f 
  engine/schema/src/com/cloud/storage/VMTemplateVO.java 
9a77cbf873aa9e422985fbcdc0ae7e18b8c78d4c 
  engine/schema/src/com/cloud/storage/VolumeVO.java 
e328253a596891029c2b55bea81b7ead425251ee 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
 a976bfbf6fe46306d20ad939c335bba6b9b7be54 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
 92793f1fb1a08a455a78667ba4a39ae162378360 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/StoragePoolVO.java 
1508ce0b28c83968c25d9601b6dae34e1a73dbb0 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/store/TemplateObject.java
 7288d454c30fdb81445e43549145f1f2da8533e4 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/ClusterScopeStoragePoolAllocator.java
 ea084c7555468001a12376640d9785b1cf852948 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
 446e101141bafde28615d766fdffd3a36ee8f3ce 
  
engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java 
c1aa8c2f0d49eb6bc6ff124dd4d87b7b714f62e9 
  
engine/storage/src/org/apache/cloudstack/storage/volume/datastore/PrimaryDataStoreHelper.java
 6b129755009413faae6685a62cfb3ae7b62b42f3 
  
engine/storage/volume/src/org/apache/cloudstack/storage/datastore/PrimaryDataStoreImpl.java
 f3c9e790277a4dc27fa9e572138c5d932be87b74 
  
engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeObject.java
 f2b4c9532a62ae917b351574523cc8b3014a4394 
  
engin

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

Hi Tim, Mike,

This patch apply for golden primary storage feature [1]. Please review it.

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


On Fri, Jun 20, 2014 at 8:41 AM, Hieu LE  wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22799/
>   Review request for cloudstack.
> By Hieu LE.
>
> *Updated June 20, 2014, 1:41 a.m.*
>  *Repository: * cloudstack-git
> Description
>
> As discussed in mailing list, this patch is applied for golden primary 
> storage in [1].
> I have changed the term from "golden" to "base" because there are some 
> functions and variables in CloudStack also use "base" for base image.
> This patch only apply for Xen Server.
>
> [1]: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+Storage
>
>   Diffs
>
>- api/src/com/cloud/deploy/DeployDestination.java
>(4ded5ebe7a18252da471ee25019856f2b2f772e0)
>- api/src/com/cloud/storage/StoragePool.java
>(8e03c3348f3a6dd3156ab9e440126ea317957dc0)
>- api/src/com/cloud/template/VirtualMachineTemplate.java
>(599212bb039fdbb78511019e8f0a6ea4b4a84440)
>- api/src/org/apache/cloudstack/api/ApiConstants.java
>(ae5d6f05b6b52f60b151369a641cb11fcbb558af)
>- api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java
>(2350f6b389203e2c6cc2182fe03fe9a95e936b81)
>- 
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>(ae44bc9373232d242e4ebdcf76844969f0fe69fc)
>- 
> api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
>(3d1a77353257c814efaf60875ffdf99603bc414e)
>- 
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
>(f478c9bc8eebf867a03deb4add1bf695ac3ec0ad)
>- api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java
>(3571866fe74dca9aa5fe0d11373313eab97e94ac)
>- api/src/org/apache/cloudstack/api/response/TemplateResponse.java
>(3e21043e339103c021d3c9e767acac8b3837f760)
>- core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java
>(PRE-CREATION)
>- core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java
>(PRE-CREATION)
>- core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java
>(29e53b0d9581f764a17ea285606213d2c045b029)
>- core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java
>(b201c386f4975913f13c575d7685e50cedc7d92f)
>- 
> core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java
>(33361e87265df05e00bfa6dba810d2b68ae8d923)
>- 
> core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java
>(66feaecb5ef20053db50956e2801fec096a350c9)
>- core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java
>(114c8854d1504436523aa99c78bf2b4d84a12077)
>- 
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
>(1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9)
>- 
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
>(dfdbd8ab92c47799f6ad23637fa63e030f0be968)
>- 
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
>(f93f4efac83c565cd33eb7eb67dcaca335f1c226)
>- engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java
>(ee6721ab445a5222d0087dc9170e0b58f9eef91a)
>- engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>(4aa5fc80d9660d2f985db98124c33465bd99767f)
>- 
> engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
>(b1ac2f853374d6f1ddd9087919dbc16db0433f59)
>- 
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>(6256e2526ef9bd4632a5e3873c4d9531eb301c7f)
>- engine/schema/src/com/cloud/storage/VMTemplateVO.java
>(9a77cbf873aa9e422985fbcdc0ae7e18b8c78d4c)
>- engine/schema/src/com/cloud/storage/VolumeVO.java
>(e328253a596891029c2b55bea81b7ead425251ee)
>- 
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>(a976bfbf6fe46306d20ad939c335bba6b9b7be54)
>- 
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>(92793f1fb1a08a455a78667ba4a39ae162378360)
>- 
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/StoragePoolVO.java
>(1508ce0b28c83968c25d9601b6dae34e1a73dbb0)
>- 
> engine/storage/image/src/org/apache/cloudstack/storage/image/store/TemplateObject.java
>(7288d454c30fdb81445e43549145f1f2da8533e4)
>- 
> engine/storage/src/org/apache/cloudstack/storage/allocator/ClusterScopeStoragePoolAllocator.java
>(ea084c7555468001a12376640d9785b1cf852948)
>- 
> engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
>(446e101141bafde28615d766fdffd3a36ee8f3ce)
>- 
> engine/storage/src/org/apache/

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

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

(Updated June 20, 2014, 1:54 a.m.)


Review request for cloudstack, Mike Tutkowski and Tim Mackey.


Changes
---

add reviewers


Repository: cloudstack-git


Description
---

As discussed in mailing list, this patch is applied for golden primary storage 
in [1].
I have changed the term from "golden" to "base" because there are some 
functions and variables in CloudStack also use "base" for base image.
This patch only apply for Xen Server.

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


Diffs
-

  api/src/com/cloud/deploy/DeployDestination.java 
4ded5ebe7a18252da471ee25019856f2b2f772e0 
  api/src/com/cloud/storage/StoragePool.java 
8e03c3348f3a6dd3156ab9e440126ea317957dc0 
  api/src/com/cloud/template/VirtualMachineTemplate.java 
599212bb039fdbb78511019e8f0a6ea4b4a84440 
  api/src/org/apache/cloudstack/api/ApiConstants.java 
ae5d6f05b6b52f60b151369a641cb11fcbb558af 
  api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 
2350f6b389203e2c6cc2182fe03fe9a95e936b81 
  
api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
 ae44bc9373232d242e4ebdcf76844969f0fe69fc 
  
api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
 3d1a77353257c814efaf60875ffdf99603bc414e 
  
api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
 f478c9bc8eebf867a03deb4add1bf695ac3ec0ad 
  api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 
3571866fe74dca9aa5fe0d11373313eab97e94ac 
  api/src/org/apache/cloudstack/api/response/TemplateResponse.java 
3e21043e339103c021d3c9e767acac8b3837f760 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java PRE-CREATION 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java PRE-CREATION 
  core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java 
29e53b0d9581f764a17ea285606213d2c045b029 
  core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java 
b201c386f4975913f13c575d7685e50cedc7d92f 
  core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
33361e87265df05e00bfa6dba810d2b68ae8d923 
  core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java 
66feaecb5ef20053db50956e2801fec096a350c9 
  core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
114c8854d1504436523aa99c78bf2b4d84a12077 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
 1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
 dfdbd8ab92c47799f6ad23637fa63e030f0be968 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
 f93f4efac83c565cd33eb7eb67dcaca335f1c226 
  engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java 
ee6721ab445a5222d0087dc9170e0b58f9eef91a 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
4aa5fc80d9660d2f985db98124c33465bd99767f 
  
engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
 b1ac2f853374d6f1ddd9087919dbc16db0433f59 
  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 6256e2526ef9bd4632a5e3873c4d9531eb301c7f 
  engine/schema/src/com/cloud/storage/VMTemplateVO.java 
9a77cbf873aa9e422985fbcdc0ae7e18b8c78d4c 
  engine/schema/src/com/cloud/storage/VolumeVO.java 
e328253a596891029c2b55bea81b7ead425251ee 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
 a976bfbf6fe46306d20ad939c335bba6b9b7be54 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
 92793f1fb1a08a455a78667ba4a39ae162378360 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/StoragePoolVO.java 
1508ce0b28c83968c25d9601b6dae34e1a73dbb0 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/store/TemplateObject.java
 7288d454c30fdb81445e43549145f1f2da8533e4 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/ClusterScopeStoragePoolAllocator.java
 ea084c7555468001a12376640d9785b1cf852948 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
 446e101141bafde28615d766fdffd3a36ee8f3ce 
  
engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java 
c1aa8c2f0d49eb6bc6ff124dd4d87b7b714f62e9 
  
engine/storage/src/org/apache/cloudstack/storage/volume/datastore/PrimaryDataStoreHelper.java
 6b129755009413faae6685a62cfb3ae7b62b42f3 
  
engine/storage/volume/src/org/apache/cloudstack/storage/datastore/PrimaryDataStoreImpl.java
 f3c9e790277a4dc27fa9e572138c5d932be87b74 
  
engine/storage/volume/src/org/apache/cloudstack/storage/volume/Volum

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

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

(Updated June 20, 2014, 3:46 a.m.)


Review request for cloudstack, Mike Tutkowski and Tim Mackey.


Changes
---

fix UI bug


Repository: cloudstack-git


Description
---

As discussed in mailing list, this patch is applied for golden primary storage 
in [1].
I have changed the term from "golden" to "base" because there are some 
functions and variables in CloudStack also use "base" for base image.
This patch only apply for Xen Server.

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


Diffs (updated)
-

  api/src/com/cloud/deploy/DeployDestination.java 
4ded5ebe7a18252da471ee25019856f2b2f772e0 
  api/src/com/cloud/storage/StoragePool.java 
8e03c3348f3a6dd3156ab9e440126ea317957dc0 
  api/src/com/cloud/template/VirtualMachineTemplate.java 
599212bb039fdbb78511019e8f0a6ea4b4a84440 
  api/src/org/apache/cloudstack/api/ApiConstants.java 
ae5d6f05b6b52f60b151369a641cb11fcbb558af 
  api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 
2350f6b389203e2c6cc2182fe03fe9a95e936b81 
  
api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
 ae44bc9373232d242e4ebdcf76844969f0fe69fc 
  
api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStoragePoolCmd.java
 3d1a77353257c814efaf60875ffdf99603bc414e 
  
api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
 f478c9bc8eebf867a03deb4add1bf695ac3ec0ad 
  api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 
3571866fe74dca9aa5fe0d11373313eab97e94ac 
  api/src/org/apache/cloudstack/api/response/TemplateResponse.java 
3e21043e339103c021d3c9e767acac8b3837f760 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java PRE-CREATION 
  core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java PRE-CREATION 
  core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java 
29e53b0d9581f764a17ea285606213d2c045b029 
  core/src/org/apache/cloudstack/storage/to/TemplateObjectTO.java 
b201c386f4975913f13c575d7685e50cedc7d92f 
  core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
33361e87265df05e00bfa6dba810d2b68ae8d923 
  core/test/org/apache/cloudstack/api/agent/test/CheckNetworkAnswerTest.java 
66feaecb5ef20053db50956e2801fec096a350c9 
  core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
114c8854d1504436523aa99c78bf2b4d84a12077 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
 1dbff59a8911ad8f0933ef17a2c2b1d3e33523b9 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/StoragePoolAllocator.java
 dfdbd8ab92c47799f6ad23637fa63e030f0be968 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/VolumeInfo.java
 f93f4efac83c565cd33eb7eb67dcaca335f1c226 
  engine/components-api/src/com/cloud/deploy/DeploymentPlanningManager.java 
ee6721ab445a5222d0087dc9170e0b58f9eef91a 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
4aa5fc80d9660d2f985db98124c33465bd99767f 
  
engine/orchestration/src/org/apache/cloudstack/engine/cloud/entity/api/VMEntityManagerImpl.java
 b1ac2f853374d6f1ddd9087919dbc16db0433f59 
  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 6256e2526ef9bd4632a5e3873c4d9531eb301c7f 
  engine/schema/src/com/cloud/storage/VMTemplateVO.java 
9a77cbf873aa9e422985fbcdc0ae7e18b8c78d4c 
  engine/schema/src/com/cloud/storage/VolumeVO.java 
e328253a596891029c2b55bea81b7ead425251ee 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
 a976bfbf6fe46306d20ad939c335bba6b9b7be54 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
 92793f1fb1a08a455a78667ba4a39ae162378360 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/StoragePoolVO.java 
1508ce0b28c83968c25d9601b6dae34e1a73dbb0 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/store/TemplateObject.java
 7288d454c30fdb81445e43549145f1f2da8533e4 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/ClusterScopeStoragePoolAllocator.java
 ea084c7555468001a12376640d9785b1cf852948 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
 446e101141bafde28615d766fdffd3a36ee8f3ce 
  
engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java 
c1aa8c2f0d49eb6bc6ff124dd4d87b7b714f62e9 
  
engine/storage/src/org/apache/cloudstack/storage/volume/datastore/PrimaryDataStoreHelper.java
 6b129755009413faae6685a62cfb3ae7b62b42f3 
  
engine/storage/volume/src/org/apache/cloudstack/storage/datastore/PrimaryDataStoreImpl.java
 f3c9e790277a4dc27fa9e572138c5d932be87b74 
  
engine/storage/volume/src/org/apache/cloudstack/storage/volum

Is VM snapshot supported in KVM ?

[Rayees Namathponnan]

Hi All,

Is VM snapshot supported in KVM, below doc says its supported in KVM,

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

But if I try to take vm snapshot from UI,  I am getting message "VM snapshot is 
not enabled for hypervisor type: KVM"


Regards,
Rayees

Re: Is VM snapshot supported in KVM ?

[Koushik Das]

VM snapshot is disabled for KVM. Check hypervisor_capabilities table. Not sure 
what was the reason for keeping it disabled.

On 20-Jun-2014, at 10:16 AM, Rayees Namathponnan 
 wrote:

> Hi All,
> 
> Is VM snapshot supported in KVM, below doc says its supported in KVM,
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots
> 
> But if I try to take vm snapshot from UI,  I am getting message "VM snapshot 
> is not enabled for hypervisor type: KVM"
> 
> 
> Regards,
> Rayees

Re: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

I just wanted to update those who are interested in this thread about work
I've done on this over the past couple days.

This gist is that I've added a new method to the PrimaryDataStoreLifeCycle
interface that has the following signature (this code is not yet checked
in):

void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
capacityIops);

This method can be invoked from StorageManagerImpl when the
updateStoragePool API is called.

This gives the storage plug-in that backs the primary storage in question
an opportunity to update the backend storage it represents, if that makes
sense to do in your particular case (for example, changing the size and/or
IOPS of a volume).

There is a related enhancement to the resizeVolume API that I plan to
tackle next week. That one will be particularly useful for managed storage
plug-ins.

Also, I have been collecting input on the generic key/value proposal here:

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111

That may turn into a considerable amount of work. I was initially thinking
it could be fit into 4.5, but it might be 4.6.

Thanks for any feedback!


On Thu, Jun 12, 2014 at 11:09 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> As I think about this more, there are two situations we should cover:
>
> 1) Non-managed storage that has control over IOPS.
>
> When you invoke the createStoragePool API, you can pass in capacityIops.
>
> We should support modifying capacityIops via the updateStoragePool API.
>
> 2) Managed storage that has control over IOPS.
>
> In this environment, there is a 1:1 mapping between a SAN volume and a
> CloudStack volume.
>
> This is where we need to augment the resizeVolume API to accept - in a
> similar fashion to size - a new value for Min and/or Max IOPS.
>
> For example, a resizeVolume can be initiated by simply selecting a new
> Disk Offering.
>
> In this situation, the size and IOPS are part of the new Disk Offering
> (i.e. neither size nor IOPS can be marked as custom) and when the resize
> method of the storage plug-in is invoked, it will have a chance to change
> the size and/or IOPS.
>
> I would say we should perform a bit of analysis in the CloudStack volume
> logic to NOT stop resize from being invoked on the storage plug-in IF the
> volume size is the same, but the IOPS are different. This way the volume
> can be online as long as the user is only changing the IOPS of the volume.
>
> I also think it's only a problem for XenServer for the VDI to have its
> size changed dynamically.
>
> I plan to draw a flowchart for this soon. Once I do that I think it will
> be easier to talk in detail.
>
> Thanks!
>
>
> On Thu, Jun 12, 2014 at 12:59 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> From what I understand about the resizeVolume API, to change the size of
>> a given volume, you must either:
>>
>> 1) pass in a new Disk Offering (if the current Disk Offering the volume
>> uses does not allow for a custom size)
>>
>> or
>>
>> 2) pass in the ID of the volume and a new size (if the current Disk
>> Offering the volume uses does allow for a custom size)
>>
>> Either way, if you are shrinking the volume's size, you then have to pass
>> in 'true' for the 'shrinkok' parameter.
>>
>> One thing we should do is support this same concept with IOPS. At the
>> time being, both Min and Max IOPS can be custom (set by user) or non custom
>> (set by admin). This is a direct parallel to custom size or non-custom
>> size. If the user is using a non-custom IOPS setting and wants to switch to
>> a custom IOPS setting, he should be able to do so by switching to a Disk
>> Offering with custom IOPS. Of course we should support doing this while the
>> volume is attached.
>>
>> If arbitrary key/value pairs can be associated with Disk Offerings, then
>> you should be able to get the new key/value pairs by switching to a new
>> Disk Offering. We'd want to allow this to work with the volume in the
>> attached state, as well.
>>
>> Perhaps we should allow this all to happen online (volume attached)
>> UNLESS doing what we're about to do will change the size of the volume.
>> Then we can fail the OP and tell them to detach the volume and re-run the
>> OP.
>>
>> What are you thoughts on that?
>>
>> Also, I think volumeResize only works for data disks at the time being.
>>
>> In my mind, volumeResize is a bit of a misnomer now. We are really
>> allowing the user to resize their Disk Offering now in terms of not only
>> size, but IOPS, and even arbitrary key/value pairs. This is still all done
>> by selecting a new Disk Offering (or - if you have a custom size or custom
>> IOPS disk offering already - by passing in the ID of the volume and the new
>> size and/or IOPS).
>>
>> Let's brainstorm on this a bit and see which way makes sense to go.
>>
>> Thanks!
>>
>>
>> On Thu, Jun 12, 2014 at 9:48 AM, Punith S  wrote:
>>
>>> sure mike.
>>>
>>> and i have one question,
>>>
>>> which existing volume a

Re: feature : changing volume properties dynamically in 4.5

[Amit Das]

Hi Mike,

Is there any use case to have a more generic signature for
updateStoragePool API ?

e.g
void updateStoragePool(StoragePool storagePool, Map updateDetails);
// not too sure of what should be E & V as of now. To start with E & V can
be String types or Enums for better static checks.

instead of below
void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
 capacityIops);

​​

Regards,
Amit
*CloudByte Inc.* 


On Fri, Jun 20, 2014 at 10:37 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I just wanted to update those who are interested in this thread about work
> I've done on this over the past couple days.
>
> This gist is that I've added a new method to the PrimaryDataStoreLifeCycle
> interface that has the following signature (this code is not yet checked
> in):
>
> void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
> capacityIops);
>
> This method can be invoked from StorageManagerImpl when the
> updateStoragePool API is called.
>
> This gives the storage plug-in that backs the primary storage in question
> an opportunity to update the backend storage it represents, if that makes
> sense to do in your particular case (for example, changing the size and/or
> IOPS of a volume).
>
> There is a related enhancement to the resizeVolume API that I plan to
> tackle next week. That one will be particularly useful for managed storage
> plug-ins.
>
> Also, I have been collecting input on the generic key/value proposal here:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
>
> That may turn into a considerable amount of work. I was initially thinking
> it could be fit into 4.5, but it might be 4.6.
>
> Thanks for any feedback!
>
>
> On Thu, Jun 12, 2014 at 11:09 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> As I think about this more, there are two situations we should cover:
>>
>> 1) Non-managed storage that has control over IOPS.
>>
>> When you invoke the createStoragePool API, you can pass in capacityIops.
>>
>> We should support modifying capacityIops via the updateStoragePool API.
>>
>> 2) Managed storage that has control over IOPS.
>>
>> In this environment, there is a 1:1 mapping between a SAN volume and a
>> CloudStack volume.
>>
>> This is where we need to augment the resizeVolume API to accept - in a
>> similar fashion to size - a new value for Min and/or Max IOPS.
>>
>> For example, a resizeVolume can be initiated by simply selecting a new
>> Disk Offering.
>>
>> In this situation, the size and IOPS are part of the new Disk Offering
>> (i.e. neither size nor IOPS can be marked as custom) and when the resize
>> method of the storage plug-in is invoked, it will have a chance to change
>> the size and/or IOPS.
>>
>> I would say we should perform a bit of analysis in the CloudStack volume
>> logic to NOT stop resize from being invoked on the storage plug-in IF the
>> volume size is the same, but the IOPS are different. This way the volume
>> can be online as long as the user is only changing the IOPS of the volume.
>>
>> I also think it's only a problem for XenServer for the VDI to have its
>> size changed dynamically.
>>
>> I plan to draw a flowchart for this soon. Once I do that I think it will
>> be easier to talk in detail.
>>
>> Thanks!
>>
>>
>> On Thu, Jun 12, 2014 at 12:59 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> From what I understand about the resizeVolume API, to change the size of
>>> a given volume, you must either:
>>>
>>> 1) pass in a new Disk Offering (if the current Disk Offering the volume
>>> uses does not allow for a custom size)
>>>
>>> or
>>>
>>> 2) pass in the ID of the volume and a new size (if the current Disk
>>> Offering the volume uses does allow for a custom size)
>>>
>>> Either way, if you are shrinking the volume's size, you then have to
>>> pass in 'true' for the 'shrinkok' parameter.
>>>
>>> One thing we should do is support this same concept with IOPS. At the
>>> time being, both Min and Max IOPS can be custom (set by user) or non custom
>>> (set by admin). This is a direct parallel to custom size or non-custom
>>> size. If the user is using a non-custom IOPS setting and wants to switch to
>>> a custom IOPS setting, he should be able to do so by switching to a Disk
>>> Offering with custom IOPS. Of course we should support doing this while the
>>> volume is attached.
>>>
>>> If arbitrary key/value pairs can be associated with Disk Offerings, then
>>> you should be able to get the new key/value pairs by switching to a new
>>> Disk Offering. We'd want to allow this to work with the volume in the
>>> attached state, as well.
>>>
>>> Perhaps we should allow this all to happen online (volume attached)
>>> UNLESS doing what we're about to do will change the size of the volume.
>>> Then we can fail the OP and tell them to detach the volume and re-run the
>>> OP.
>>>
>>> What are you thoughts on that?
>>>
>>> Also, I think volumeRe

Re: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

Unfortunately, at the time being, the updateStoragePool API (from the
public-facing API) only takes in bytes, IOPS, and storage tags...not
details (createStoragePool takes in a lot more parameters...including
details).

So - for now at least - we're a little limited in what the new interface
method can tell storage providers about (unless we wanted to spend time
adding to the parameter list of updateStoragePool).

On Friday, June 20, 2014, Amit Das  wrote:

> Hi Mike,
>
> Is there any use case to have a more generic signature for
> updateStoragePool API ?
>
> e.g
> void updateStoragePool(StoragePool storagePool, Map updateDetails);
> // not too sure of what should be E & V as of now. To start with E & V can
> be String types or Enums for better static checks.
>
> instead of below
> void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
>  capacityIops);
>
> ​​
>
> Regards,
> Amit
> *CloudByte Inc.* 
>
>
> On Fri, Jun 20, 2014 at 10:37 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
>> I just wanted to update those who are interested in this thread about
>> work I've done on this over the past couple days.
>>
>> This gist is that I've added a new method to the
>> PrimaryDataStoreLifeCycle interface that has the following signature (this
>> code is not yet checked in):
>>
>> void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
>> capacityIops);
>>
>> This method can be invoked from StorageManagerImpl when the
>> updateStoragePool API is called.
>>
>> This gives the storage plug-in that backs the primary storage in question
>> an opportunity to update the backend storage it represents, if that makes
>> sense to do in your particular case (for example, changing the size and/or
>> IOPS of a volume).
>>
>> There is a related enhancement to the resizeVolume API that I plan to
>> tackle next week. That one will be particularly useful for managed storage
>> plug-ins.
>>
>> Also, I have been collecting input on the generic key/value proposal here:
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
>>
>> That may turn into a considerable amount of work. I was initially
>> thinking it could be fit into 4.5, but it might be 4.6.
>>
>> Thanks for any feedback!
>>
>>
>> On Thu, Jun 12, 2014 at 11:09 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com
>> > wrote:
>>
>>> As I think about this more, there are two situations we should cover:
>>>
>>> 1) Non-managed storage that has control over IOPS.
>>>
>>> When you invoke the createStoragePool API, you can pass in capacityIops.
>>>
>>> We should support modifying capacityIops via the updateStoragePool API.
>>>
>>> 2) Managed storage that has control over IOPS.
>>>
>>> In this environment, there is a 1:1 mapping between a SAN volume and a
>>> CloudStack volume.
>>>
>>> This is where we need to augment the resizeVolume API to accept - in a
>>> similar fashion to size - a new value for Min and/or Max IOPS.
>>>
>>> For example, a resizeVolume can be initiated by simply selecting a new
>>> Disk Offering.
>>>
>>> In this situation, the size and IOPS are part of the new Disk Offering
>>> (i.e. neither size nor IOPS can be marked as custom) and when the resize
>>> method of the storage plug-in is invoked, it will have a chance to change
>>> the size and/or IOPS.
>>>
>>> I would say we should perform a bit of analysis in the CloudStack volume
>>> logic to NOT stop resize from being invoked on the storage plug-in IF the
>>> volume size is the same, but the IOPS are different. This way the volume
>>> can be online as long as the user is only changing the IOPS of the volume.
>>>
>>> I also think it's only a problem for XenServer for the VDI to have its
>>> size changed dynamically.
>>>
>>> I plan to draw a flowchart for this soon. Once I do that I think it will
>>> be easier to talk in detail.
>>>
>>> Thanks!
>>>
>>>
>>> On Thu, Jun 12, 2014 at 12:59 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com
>>> > wrote:
>>>
 From what I understand about the resizeVolume API, to change the size
 of a given volume, you must either:

 1) pass in a new Disk Offering (if the current Disk Offering the volume
 uses does not allow for a custom size)

 or

 2) pass in the ID of the volume and a new size (if the current Disk
 Offering the volume uses does allow for a custom size)

 Either way, if you are shrinking the volume's size, you then have to
 pass in 'true' for the 'shrinkok' parameter.

 One thing we should do is support this same concept with IOPS. At the
 time being, both Min and Max IOPS can be custom (set by user) or non custom
 (set by admin). This is a direct parallel to custom size or non-custom
 size. If the user is using a non-custom IOPS setting and wants to switch to
 a custom IOPS setting, he should be able to do so by switching to a Disk
 Offering with custom IOPS. Of course we should support do

Re: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

We do - in some places in the code - use a hash map...like what you
describe.

I guess the trade off there would be that the values that contain our
numbers would end up being high-level objects instead of numbers (because
we don't really know what future values might be).

I'm OK with either approach.

On Friday, June 20, 2014, Mike Tutkowski 
wrote:

> Unfortunately, at the time being, the updateStoragePool API (from the
> public-facing API) only takes in bytes, IOPS, and storage tags...not
> details (createStoragePool takes in a lot more parameters...including
> details).
>
> So - for now at least - we're a little limited in what the new interface
> method can tell storage providers about (unless we wanted to spend time
> adding to the parameter list of updateStoragePool).
>
> On Friday, June 20, 2014, Amit Das  > wrote:
>
>> Hi Mike,
>>
>> Is there any use case to have a more generic signature for
>> updateStoragePool API ?
>>
>> e.g
>> void updateStoragePool(StoragePool storagePool, Map updateDetails);
>> // not too sure of what should be E & V as of now. To start with E & V
>> can be String types or Enums for better static checks.
>>
>> instead of below
>> void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
>>  capacityIops);
>>
>> ​​
>>
>> Regards,
>> Amit
>> *CloudByte Inc.* 
>>
>>
>> On Fri, Jun 20, 2014 at 10:37 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> I just wanted to update those who are interested in this thread about
>>> work I've done on this over the past couple days.
>>>
>>> This gist is that I've added a new method to the
>>> PrimaryDataStoreLifeCycle interface that has the following signature (this
>>> code is not yet checked in):
>>>
>>> void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
>>> capacityIops);
>>>
>>> This method can be invoked from StorageManagerImpl when the
>>> updateStoragePool API is called.
>>>
>>> This gives the storage plug-in that backs the primary storage in
>>> question an opportunity to update the backend storage it represents, if
>>> that makes sense to do in your particular case (for example, changing the
>>> size and/or IOPS of a volume).
>>>
>>> There is a related enhancement to the resizeVolume API that I plan to
>>> tackle next week. That one will be particularly useful for managed storage
>>> plug-ins.
>>>
>>> Also, I have been collecting input on the generic key/value proposal
>>> here:
>>>
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
>>>
>>> That may turn into a considerable amount of work. I was initially
>>> thinking it could be fit into 4.5, but it might be 4.6.
>>>
>>> Thanks for any feedback!
>>>
>>>
>>> On Thu, Jun 12, 2014 at 11:09 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
 As I think about this more, there are two situations we should cover:

 1) Non-managed storage that has control over IOPS.

 When you invoke the createStoragePool API, you can pass in capacityIops.

 We should support modifying capacityIops via the updateStoragePool API.

 2) Managed storage that has control over IOPS.

 In this environment, there is a 1:1 mapping between a SAN volume and a
 CloudStack volume.

 This is where we need to augment the resizeVolume API to accept - in a
 similar fashion to size - a new value for Min and/or Max IOPS.

 For example, a resizeVolume can be initiated by simply selecting a new
 Disk Offering.

 In this situation, the size and IOPS are part of the new Disk Offering
 (i.e. neither size nor IOPS can be marked as custom) and when the resize
 method of the storage plug-in is invoked, it will have a chance to change
 the size and/or IOPS.

 I would say we should perform a bit of analysis in the CloudStack
 volume logic to NOT stop resize from being invoked on the storage plug-in
 IF the volume size is the same, but the IOPS are different. This way the
 volume can be online as long as the user is only changing the IOPS of the
 volume.

 I also think it's only a problem for XenServer for the VDI to have its
 size changed dynamically.

 I plan to draw a flowchart for this soon. Once I do that I think it
 will be easier to talk in detail.

 Thanks!


 On Thu, Jun 12, 2014 at 12:59 PM, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:

> From what I understand about the resizeVolume API, to change the size
> of a given volume, you must either:
>
> 1) pass in a new Disk Offering (if the current Disk Offering the
> volume uses does not allow for a custom size)
>
> or
>
> 2) pass in the ID of the volume and a new size (if the current Disk
> Offering the volume uses does allow for a custom size)
>
> Either way, if you are shrinking the volume's size, you then have to
> pass in 'true' fo

Re: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

In fact, we do use a hash-map approach for some KVM storage code, too.

Let's do that here, as well.

I'll make that change.

Thanks

On Friday, June 20, 2014, Mike Tutkowski 
wrote:

> We do - in some places in the code - use a hash map...like what you
> describe.
>
> I guess the trade off there would be that the values that contain our
> numbers would end up being high-level objects instead of numbers (because
> we don't really know what future values might be).
>
> I'm OK with either approach.
>
> On Friday, June 20, 2014, Mike Tutkowski  > wrote:
>
>> Unfortunately, at the time being, the updateStoragePool API (from the
>> public-facing API) only takes in bytes, IOPS, and storage tags...not
>> details (createStoragePool takes in a lot more parameters...including
>> details).
>>
>> So - for now at least - we're a little limited in what the new interface
>> method can tell storage providers about (unless we wanted to spend time
>> adding to the parameter list of updateStoragePool).
>>
>> On Friday, June 20, 2014, Amit Das  wrote:
>>
>>> Hi Mike,
>>>
>>> Is there any use case to have a more generic signature for
>>> updateStoragePool API ?
>>>
>>> e.g
>>> void updateStoragePool(StoragePool storagePool, Map updateDetails);
>>> // not too sure of what should be E & V as of now. To start with E & V
>>> can be String types or Enums for better static checks.
>>>
>>> instead of below
>>> void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
>>>  capacityIops);
>>>
>>> ​​
>>>
>>> Regards,
>>> Amit
>>> *CloudByte Inc.* 
>>>
>>>
>>> On Fri, Jun 20, 2014 at 10:37 AM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
 I just wanted to update those who are interested in this thread about
 work I've done on this over the past couple days.

 This gist is that I've added a new method to the
 PrimaryDataStoreLifeCycle interface that has the following signature (this
 code is not yet checked in):

 void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
 capacityIops);

 This method can be invoked from StorageManagerImpl when the
 updateStoragePool API is called.

 This gives the storage plug-in that backs the primary storage in
 question an opportunity to update the backend storage it represents, if
 that makes sense to do in your particular case (for example, changing the
 size and/or IOPS of a volume).

 There is a related enhancement to the resizeVolume API that I plan to
 tackle next week. That one will be particularly useful for managed storage
 plug-ins.

 Also, I have been collecting input on the generic key/value proposal
 here:


 https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111

 That may turn into a considerable amount of work. I was initially
 thinking it could be fit into 4.5, but it might be 4.6.

 Thanks for any feedback!


 On Thu, Jun 12, 2014 at 11:09 PM, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:

> As I think about this more, there are two situations we should cover:
>
> 1) Non-managed storage that has control over IOPS.
>
> When you invoke the createStoragePool API, you can pass in
> capacityIops.
>
> We should support modifying capacityIops via the updateStoragePool API.
>
> 2) Managed storage that has control over IOPS.
>
> In this environment, there is a 1:1 mapping between a SAN volume and a
> CloudStack volume.
>
> This is where we need to augment the resizeVolume API to accept - in a
> similar fashion to size - a new value for Min and/or Max IOPS.
>
> For example, a resizeVolume can be initiated by simply selecting a new
> Disk Offering.
>
> In this situation, the size and IOPS are part of the new Disk Offering
> (i.e. neither size nor IOPS can be marked as custom) and when the resize
> method of the storage plug-in is invoked, it will have a chance to change
> the size and/or IOPS.
>
> I would say we should perform a bit of analysis in the CloudStack
> volume logic to NOT stop resize from being invoked on the storage plug-in
> IF the volume size is the same, but the IOPS are different. This way the
> volume can be online as long as the user is only changing the IOPS of the
> volume.
>
> I also think it's only a problem for XenServer for the VDI to have its
> size changed dynamically.
>
> I plan to draw a flowchart for this soon. Once I do that I think it
> will be easier to talk in detail.
>
> Thanks!
>
>
> On Thu, Jun 12, 2014 at 12:59 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> From what I understand about the resizeVolume API, to change the size
>> of a given volume, you must either:
>>
>> 1) pass in a new Disk Offering (if the current 

Re: building and testing 4.4.

[Rohit Yadav]

Hi Carlos,

On Fri, Jun 20, 2014 at 4:17 AM, Carlos Reategui 
wrote:

> Hi Rohit,
> Thanks for the info, but I was asking about the non-oss.  Is that included
> in Wido's released versions?
>

This is oss (I checked the 4.3 release debs, and could not find vmware jars
and other non-oss stuff).


>
> I'm assuming the zip file you linked below will give me the same as:
> git checkout remotes/origin/4.4
>

Yes :)


> Also, what is the issue with tomcat 6.0.35?  I just noticed that my
> Management Server is running the default Ubuntu tomcat6 which is 6.0.35.
>  Are all versions of CloudStack affected?
>

Historically we've been using 6.0.33, we need to revisit it. For now I
would recommend you to use Tomcat 6.0.33.

Thanks for filing the doc bug.

Regards.


>
> thanks,
> Carlos
>
> PS figured it would be good to change the subject of this thread
>
>
> On Thu, Jun 19, 2014 at 12:16 PM, Rohit Yadav  wrote:
>
> > On Fri, Jun 20, 2014 at 12:22 AM, Carlos Reategui 
> > wrote:
> >
> > > I can do that.
> > >
> > > My current install is from the repo
> http://cloudstack.apt-get.eu/ubuntu.
> > >  Do you know if that is built with -Dnoredist? I would like to make
> sure
> > I
> > > build and package the same way.
> > >
> >
> > Wido maintains it and only hosts released versions of CloudStack and
> AFAIK
> > we don't have an active nightlies debian build repo for users.
> >
> > That means, you'll have to build from source which is not very hard to do
> > (you may even automate it):
> >
> > 1. Download the 4.4 branch zipball:
> > https://github.com/apache/cloudstack/archive/4.4.zip
> >
> > 2. Follow this:
> >
> >
> >
> http://cloudstack-installation.readthedocs.org/en/latest/building_from_source.html#prerequisites-for-building-apache-cloudstack
> >
> > If you're stuck or have any issues reach out to the community, we're good
> > people :)
> >
> > @Wido: Hey! Can you start the nightlies again so users don't have to do
> > debian builds themselves?
> >
> > Regards.
> >
> >
> > >
> > > Thanks
> > > Carlos
> > >
> > >
> > > On Thu, Jun 19, 2014 at 11:35 AM, Rohit Yadav 
> > wrote:
> > >
> > > > On Thu, Jun 19, 2014 at 10:39 PM, Carlos Reátegui <
> create...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Daan,
> > > > >
> > > > > I have not tried 4.3.  I saw some of the issues people were having
> > and
> > > > > decided to hold off from trying.
> > > > >
> > > > > Do you suggest I try with 4.3 or should I build my own deb packages
> > and
> > > > > try 4.4?
> > > > >
> > > > > BTW I am on ubuntu 12.04 + XenServer 6.0.2
> > > > >
> > > >
> > > > Carlos, Daan is suggesting that you help us test our upcoming 4.4
> > release
> > > > :) using the 4.4 branch [1]
> > > >
> > > > [1] https://github.com/apache/cloudstack/tree/4.4
> > > >
> > > > Cheers.
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Jun 19, 2014, at 12:35 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Carlos, please export your db and do a test upgrade on a lab
> > machine?
> > > > > > Now is the time to solve any upgrade issues in 4.4.
> > > > > >
> > > > > > Have you tried the 4.3 upgrade already?
> > > > > >
> > > > > > regards,
> > > > > > Daan
> > > > > >
> > > > > > On Wed, Jun 18, 2014 at 7:04 PM, Carlos Reátegui <
> > > create...@gmail.com>
> > > > > wrote:
> > > > > >> Hi Rohit,
> > > > > >>
> > > > > >> The awsapi was one of the reasons we chose to use ACS.  We have
> > > > > developed some internal tools and apps to manage our deployments on
> > AWS
> > > > > that we want to re-use on ACS.  We have not been able to use it yet
> > > > because
> > > > > it was broken in 4.1.1.  We tried to upgrade to 4.2 and were
> > > unsuccessful
> > > > > and are now waiting for 4.4 to finally upgrade and hopefully be
> able
> > to
> > > > use
> > > > > the awsapi.
> > > > > >>
> > > > > >> We use ACS internally for development and testing of our
> > > applications
> > > > > that we push to AWS.
> > > > > >>
> > > > > >> thanks,
> > > > > >> Carlos
> > > > > >>
> > > > > >>
> > > > > >> On Jun 18, 2014, at 12:11 AM, Rohit Yadav 
> > > > wrote:
> > > > > >>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> Who uses "awsapi" or any other EC2 compatible interface such as
> > > > > ec2stack
> > > > > >>> with CloudStack (or CloudStack distros such as Citrix
> > > CloudPlatform)
> > > > in
> > > > > >>> production? And, if marketing and publicity are/were big
> > > > motivation(s)?
> > > > > >>>
> > > > > >>> In case you don't want to discuss on this thread, please take
> > this
> > > > > >>> anonymous poll:
> > > > > >>>
> > > > >
> > > >
> > >
> >
> http://www.polljunkie.com/poll/fbyfdc/who-uses-awsapi-with-cloudstack-in-prouduction
> > > > > >>>
> > > > > >>> # Some stats
> > > > > >>>
> > > > > >>> I've been watching Collab14 videos and found references where
> > many
> > > > > speakers
> > > > > >>> reference overall CloudStack codebase to be about 1.5M
> (million)
> > > > lines
> > > > > of
> > > > > >>> Java code whi

Re: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

I'll define constants for the keys in PrimaryDataStoreLifeCycle.

On Friday, June 20, 2014, Mike Tutkowski 
wrote:

> In fact, we do use a hash-map approach for some KVM storage code, too.
>
> Let's do that here, as well.
>
> I'll make that change.
>
> Thanks
>
> On Friday, June 20, 2014, Mike Tutkowski  > wrote:
>
>> We do - in some places in the code - use a hash map...like what you
>> describe.
>>
>> I guess the trade off there would be that the values that contain our
>> numbers would end up being high-level objects instead of numbers (because
>> we don't really know what future values might be).
>>
>> I'm OK with either approach.
>>
>> On Friday, June 20, 2014, Mike Tutkowski 
>> wrote:
>>
>>> Unfortunately, at the time being, the updateStoragePool API (from the
>>> public-facing API) only takes in bytes, IOPS, and storage tags...not
>>> details (createStoragePool takes in a lot more parameters...including
>>> details).
>>>
>>> So - for now at least - we're a little limited in what the new interface
>>> method can tell storage providers about (unless we wanted to spend time
>>> adding to the parameter list of updateStoragePool).
>>>
>>> On Friday, June 20, 2014, Amit Das  wrote:
>>>
 Hi Mike,

 Is there any use case to have a more generic signature for
 updateStoragePool API ?

 e.g
 void updateStoragePool(StoragePool storagePool, Map updateDetails
 );
 // not too sure of what should be E & V as of now. To start with E & V
 can be String types or Enums for better static checks.

 instead of below
 void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
  capacityIops);

 ​​

 Regards,
 Amit
 *CloudByte Inc.* 


 On Fri, Jun 20, 2014 at 10:37 AM, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:

> I just wanted to update those who are interested in this thread about
> work I've done on this over the past couple days.
>
> This gist is that I've added a new method to the
> PrimaryDataStoreLifeCycle interface that has the following signature (this
> code is not yet checked in):
>
> void updateCapacity(StoragePool storagePool, Long capacityBytes, Long
> capacityIops);
>
> This method can be invoked from StorageManagerImpl when the
> updateStoragePool API is called.
>
> This gives the storage plug-in that backs the primary storage in
> question an opportunity to update the backend storage it represents, if
> that makes sense to do in your particular case (for example, changing the
> size and/or IOPS of a volume).
>
> There is a related enhancement to the resizeVolume API that I plan to
> tackle next week. That one will be particularly useful for managed storage
> plug-ins.
>
> Also, I have been collecting input on the generic key/value proposal
> here:
>
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
>
> That may turn into a considerable amount of work. I was initially
> thinking it could be fit into 4.5, but it might be 4.6.
>
> Thanks for any feedback!
>
>
> On Thu, Jun 12, 2014 at 11:09 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> As I think about this more, there are two situations we should cover:
>>
>> 1) Non-managed storage that has control over IOPS.
>>
>> When you invoke the createStoragePool API, you can pass in
>> capacityIops.
>>
>> We should support modifying capacityIops via the updateStoragePool
>> API.
>>
>> 2) Managed storage that has control over IOPS.
>>
>> In this environment, there is a 1:1 mapping between a SAN volume and
>> a CloudStack volume.
>>
>> This is where we need to augment the resizeVolume API to accept - in
>> a similar fashion to size - a new value for Min and/or Max IOPS.
>>
>> For example, a resizeVolume can be initiated by simply selecting a
>> new Disk Offering.
>>
>> In this situation, the size and IOPS are part of the new Disk
>> Offering (i.e. neither size nor IOPS can be marked as custom) and when 
>> the
>> resize method of the storage plug-in is invoked, it will have a chance to
>> change the size and/or IOPS.
>>
>> I would say we should perform a bit of analysis in the CloudStack
>> volume logic to NOT stop resize from being invoked on the storage plug-in
>> IF the volume size is the same, but the IOPS are different. This way the
>> volume can be online as long as the user is only changing the IOPS of the
>> volume.
>>
>> I also think it's only a problem for XenServer for the VDI to have
>> its size changed dynamically.
>>
>> I plan to draw a flowchart for this soon. Once I do that I think it
>> will be easier to talk in detail.
>>
>> Thanks!
>>
>>
>> On

Review Request 22805: CLOUDSTACK-1466:Adding automation tests for Secondary Storage Limits

[Ashutosh Kelkar]

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

Review request for cloudstack and Girish Shilamkar.


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


Repository: cloudstack-git


Description
---

Automation tests for Secondary Storage Limits. This patch contains 2 test 
suites. 2 more test suites to follow.


Diffs
-

  test/integration/component/test_ss_domain_limits.py PRE-CREATION 
  test/integration/component/test_ss_limits.py PRE-CREATION 
  tools/marvin/marvin/config/test_data.py d870c98 
  tools/marvin/marvin/lib/base.py 8b89087 

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


Testing
---

Yes.


Thanks,

Ashutosh Kelkar