Re: [SOLVED] No response received when trying to login

[Rohit Yadav]

This is a known issue with ACS 4.3, where ACS becomes unresponsive/stuck if 
RabbitMQ is not running or if both RMQ broker and ACS plugin are not correctly 
configured.

I’m not sure about 4.4, but with 4.5+ in case RabbitMQ server is not running or 
the plugin is not correctly configured, ACS will add error logs that it was 
unable to publish events on the event bus (rabbitmq).

> On 17-Apr-2015, at 2:08 am, Yiping Zhang  wrote:
>
> I am using RabbitMQ feature,  and I did notice that the UI become
> noticeably slower for some operations, such as VM create / destroy actions.
> When the RabbitMQ server is down, the login process become unresponsive.
>
> Yiping
>
> On 4/16/15, 3:42 AM, "Erik Weber"  wrote:
>
>> Since I don't really use the feature, but merely tested it, I removed the
>> rabbitmq bean I previously set up.
>>
>> I guess the proper solution is to figure out why rabbitmq barks, probably
>> due to something being full..
>>
>> --
>> Erik
>>
>> On Thu, Apr 16, 2015 at 12:40 PM, Nux!  wrote:
>>
>>> Erik,
>>>
>>> Can you share more details about how you solved this? What did you have
>>> to
>>> do exactly?
>>>
>>> Just thinking it may come it handy to some poor soul in the future.
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
 From: "Erik Weber" 
 To: "dev" , us...@cloudstack.apache.org
 Sent: Thursday, 16 April, 2015 10:27:16
 Subject: Re: [SOLVED] No response received when trying to login
>>>
 Thank you Rajani, it was rabbitmq problems.

 All solved, and I can log in again :-)

 --
 Erik

 On Thu, Apr 16, 2015 at 10:54 AM, Rajani Karuturi 
>>> wrote:

> If you configured RabbitMQ service, check logs on the Rabbitmq hosts.
>
> check the size of the events table and see if an insert is taking
>>> time.
>>> You
> could try the login and then show full processlist at the mysql
>>> prompt
>>> to
> see any slow queries.
>
>
> ~Rajani
>
> On Thu, Apr 16, 2015 at 1:57 PM, Erik Weber 
>>> wrote:
>
>> On Thu, Apr 16, 2015 at 10:21 AM, Rajani Karuturi
>>> 
>> wrote:
>>
>>> Can you check if its blocked on raising the login event? probably
>> activemq
>>> is down or the events table is full..
>>>
>>>
>> Thanks for the suggestion, how would I go forward to check that?
>>
>> I've restarted cloudstack-management multiple times if it matters.
>>
>> --
>> Erik
>>
>>>
>

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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

Re: [DISCUSS] actions after 4.4.3 release

[Rohit Yadav]

Hi,

I’ve updated the rpms and debs on shapeblue.com/packages hosting, on both main 
and upstream repositories.
Will add the link to the release notes for 4.4.3 after as they are published.

> On 19-Apr-2015, at 4:14 pm, Daan Hoogland  wrote:
>
> H,
>
> I just moved the RC to releases. work to be done now is
> - writing a good release announcement
> - finalizing the release notes
> next we can edit the site to reflect our recent efforts.
>
> I could do with some help there. volunteers?
>
> Following the finalization of this 4.4 release, we should quickly be
> moving to bringing out a stable 4.5.
> Let us do that before moving to 4.6. At our shop we have not a big
> interest in 4.5 but as a community
> we must. So in support of our 4.5 Release Manager; please all consider
> the work to be done in this
> respect and discuss on list!
>
> thanks,
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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

[GitHub] cloudstack pull request: CLOUDSTACK-8308-Adding-automation-test-ca...

[pritisarap12]

GitHub user pritisarap12 opened a pull request:

https://github.com/apache/cloudstack/pull/181

CLOUDSTACK-8308-Adding-automation-test-cases-for-VM/Volume-snapshot-testpath

--Adding automation testcases for volume cuncurrent snapshots

Testpath Result:
Concurrent Snapshots ... === TestName: test_01_concurrent_snapshots | 
Status : SUCCESS ===
ok
Concurrent Snapshots ... SKIP: Skip test if 
restartManagementServerThroughTestCase is not provided

--
Ran 2 tests in 7895.425s

OK (SKIP=1)


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

$ git pull https://github.com/pritisarap12/cloudstack 
CLOUDSTACK-8308-Adding-automation-test-cases-for-VM/Volume-snapshottestpath-cuncurrent-snapshots

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

https://github.com/apache/cloudstack/pull/181.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 #181


commit caecbff611ca3b0b112f63f246eef698c503434e
Author: pritisarap12 
Date:   2015-04-20T11:15:50Z

CLOUDSTACK-8308-Adding-automation-test-cases-for-VM/Volume-snapshot-testpath
--Adding automation testcases for volume cuncurrent snapshots




---
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.
---

Jenkins build is still unstable: simulator-singlerun #1133

[jenkins]

See 

Re: [DISCUSS] 4.6 release management

[Simon Weller]

>
>From: Sebastien Goasguen 
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] 4.6 release management

> On Apr 18, 2015, at 8:36 AM, Marcus  wrote:
>
> Have they diverged that much? Due to cherry-picking, I guess.
> Otherwise you should be able to do it cleanly.
>
> There's a good opportunity to do this next release. Instead of
> creating a release branch, we freeze master and start creating dev
> branches.

>+1

>This just amounts to treating master now like a release branch. Getting back 
>to PL suggestion, that means
>that any commit to master would be through a PR or MERGE request on the ML. 
>Anything else will be reverted by the >RM.

+1 on this.

Ultimately this will be painful to start with, but it will pay dividends in the 
future with a much more stable (and tested) master, and hence future releases 
will be of higher quality. 
With stable (and frequent iterative) releases, there will be much less pressure 
to back port fixes/features, because the community will see taking a new 
release as low risk.

- Si

>Marcus, do you feel like writing down a little process for this and some dates 
>that we can target.
>It would be nice to do this for 4.6.

>
> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland  
> wrote:
>> We heavily invested in code now on master. Not looking forward to
>> backporting that.
>>
>> mobile dev with bilingual spelling checker used (read at your own risk)
>> Op 17 apr. 2015 21:02 schreef "Marcus" :
>>
>>> Well, would we just swap the last release branch with master? Master
>>> is the dev branch, and the last release is really what we have as a
>>> stable branch.
>>>
>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland 
>>> wrote:
 On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen 
>>> wrote:
>
>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion 
>>> wrote:
>>
>> Today during the CloudStackdays  we did a round table about Release
>> management targeting the next 4.6 releases.
>>
>>
>> Quick bullet point discussions:
>>
>> ideas to change release planning
>>
>>  - Plugin contribution is complicated because often  a new plugin
>>> involve
>>  change on the core:
>> - ex: storage plugin involve changes on Hypervisor code
>>  - There is an idea of going on a 2 weeks release model which could
>>  introduce issue the database schema.
>>  - Database schema version should be different then the application
>>  version.
>>  - There is a will to enforce git workflow in 4.6  and trigger
>>> simulator
>>  job on  PullRequest.
>>  - Some people (I'm part of them) are concerned on our current way of
>>  supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>  4.5.x). But the current level of confidence against latest release
>>> is low,
>>  so that need to be improved.
>>
>>
>> So, the main messages is that w'd like to improve the release
>>> velocity, and
>> release branch stability.  so we would like to propose few change in
>>> the
>> way we would add code to the 4.6 branch as follow:
>>
>> - All new contribution to 4.6 would be thru Pull Request or merge
>>> request,
>> which would trigger a simulator job, ideally only if that pass the PR
>>> would
>> be accepted and automatically merged.  At this time, I think we pretty
>>> much
>> have everything in place to do that. At a first step we would use
>> simulator+marvin jobs then improve tests coverage from there.
>
> +1
>
> We do need to realize what this means and be all fine with it.
>
> It means that if someone who is not RM directly commits to the release
>>> branch, the commit will be reverted.
> And that from the beginning of the branching…
 I agree and we can even go as far as reverting fixes that are
 cherry-picked in favour of merged forward.

>
> IMHO, I think this would be a good step but I don’t think it goes far
>>> enough.
 Agreed here as well but let's take the step while discussing further
 steps and not implement to much process as well

>
> This still uses a paradigm where a release is made from a release
>>> branch that was started from an unstable development branch.
> Hence you still need *extensive* QA.
 The problem here is that there is no stable point to fork from at the
 moment. We will get there and we shouldn't stop taking steps in that
 direction.

>
> If we truly want to release faster, we need to release from the same
>>> QA’d branch time after time….a release needs to be based on a previous
>>> release
>
> Basically, we need a rolling release cycle. That will have the added
>>> benefit to not leave releases behind and have to focus on backporting.
>
>>
>> Please comments :-)
>



 --
 Daan
>>>

Primary Storage algorithm - when having more primary storages

[Andrija Panic]

Hi people,

just wondering - if I have 3 primary storages (3 x NFS boxes) - what is the
volume alocation algoritm - is it compelte random, or is it like 1 client's
volume goes always to 1 storage...

Any info appreciated !

Thanks,

-- 

Andrija Panić

Re: Primary Storage algorithm - when having more primary storages

[Wei ZHOU]

/etc/cloudstack/management/componentContext.xml

  

  
  
  
  
  

  


2015-04-20 15:44 GMT+02:00 Andrija Panic :

> Hi people,
>
> just wondering - if I have 3 primary storages (3 x NFS boxes) - what is the
> volume alocation algoritm - is it compelte random, or is it like 1 client's
> volume goes always to 1 storage...
>
> Any info appreciated !
>
> Thanks,
>
> --
>
> Andrija Panić
>

AW: [DISCUSS] 4.6 release management

[S . Brüseke - proIO GmbH]

Hi all,

it is really hard for a newbie to follow all of your thought regarding this. 
Can somebody please explain it a little bit more?
Thank you very much!

Mit freundlichen Grüßen / With kind regards,

Swen Brüseke

-Ursprüngliche Nachricht-
Von: Simon Weller [mailto:swel...@ena.com] 
Gesendet: Montag, 20. April 2015 15:24
An: dev@cloudstack.apache.org
Betreff: Re: [DISCUSS] 4.6 release management

>
>From: Sebastien Goasguen 
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] 4.6 release management

> On Apr 18, 2015, at 8:36 AM, Marcus  wrote:
>
> Have they diverged that much? Due to cherry-picking, I guess.
> Otherwise you should be able to do it cleanly.
>
> There's a good opportunity to do this next release. Instead of 
> creating a release branch, we freeze master and start creating dev 
> branches.

>+1

>This just amounts to treating master now like a release branch. Getting 
>back to PL suggestion, that means that any commit to master would be through a 
>PR or MERGE request on the ML. Anything else will be reverted by the >RM.

+1 on this.

Ultimately this will be painful to start with, but it will pay dividends in the 
future with a much more stable (and tested) master, and hence future releases 
will be of higher quality. 
With stable (and frequent iterative) releases, there will be much less pressure 
to back port fixes/features, because the community will see taking a new 
release as low risk.

- Si

>Marcus, do you feel like writing down a little process for this and some dates 
>that we can target.
>It would be nice to do this for 4.6.

>
> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland  
> wrote:
>> We heavily invested in code now on master. Not looking forward to 
>> backporting that.
>>
>> mobile dev with bilingual spelling checker used (read at your own 
>> risk) Op 17 apr. 2015 21:02 schreef "Marcus" :
>>
>>> Well, would we just swap the last release branch with master? Master 
>>> is the dev branch, and the last release is really what we have as a 
>>> stable branch.
>>>
>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland 
>>> 
>>> wrote:
 On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen 
 
>>> wrote:
>
>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion 
>> 
>>> wrote:
>>
>> Today during the CloudStackdays  we did a round table about 
>> Release management targeting the next 4.6 releases.
>>
>>
>> Quick bullet point discussions:
>>
>> ideas to change release planning
>>
>>  - Plugin contribution is complicated because often  a new plugin
>>> involve
>>  change on the core:
>> - ex: storage plugin involve changes on Hypervisor code
>>  - There is an idea of going on a 2 weeks release model which 
>> could  introduce issue the database schema.
>>  - Database schema version should be different then the 
>> application  version.
>>  - There is a will to enforce git workflow in 4.6  and trigger
>>> simulator
>>  job on  PullRequest.
>>  - Some people (I'm part of them) are concerned on our current 
>> way of  supporting and back porting fixes to multiple release 
>> (4.3.x, 4.4.x,  4.5.x). But the current level of confidence 
>> against latest release
>>> is low,
>>  so that need to be improved.
>>
>>
>> So, the main messages is that w'd like to improve the release
>>> velocity, and
>> release branch stability.  so we would like to propose few change 
>> in
>>> the
>> way we would add code to the 4.6 branch as follow:
>>
>> - All new contribution to 4.6 would be thru Pull Request or merge
>>> request,
>> which would trigger a simulator job, ideally only if that pass 
>> the PR
>>> would
>> be accepted and automatically merged.  At this time, I think we 
>> pretty
>>> much
>> have everything in place to do that. At a first step we would use
>> simulator+marvin jobs then improve tests coverage from there.
>
> +1
>
> We do need to realize what this means and be all fine with it.
>
> It means that if someone who is not RM directly commits to the 
> release
>>> branch, the commit will be reverted.
> And that from the beginning of the branching.
 I agree and we can even go as far as reverting fixes that are 
 cherry-picked in favour of merged forward.

>
> IMHO, I think this would be a good step but I don't think it goes 
> far
>>> enough.
 Agreed here as well but let's take the step while discussing 
 further steps and not implement to much process as well

>
> This still uses a paradigm where a release is made from a release
>>> branch that was started from an unstable development branch.
> Hence you still need *extensive* QA.
 The problem here is that there is no stable point to fork from at 
 the moment. We will get there and we shouldn't sto

Re: Primary Storage algorithm - when having more primary storages

[Andrija Panic]

Sorry for my ignorance - meaing completely random (except the scope ?)

On 20 April 2015 at 16:01, Wei ZHOU  wrote:

> /etc/cloudstack/management/componentContext.xml
>
>class="com.cloud.utils.component.AdapterList">
> 
>   
>   
>   
>   
>   
> 
>   
>
>
> 2015-04-20 15:44 GMT+02:00 Andrija Panic :
>
> > Hi people,
> >
> > just wondering - if I have 3 primary storages (3 x NFS boxes) - what is
> the
> > volume alocation algoritm - is it compelte random, or is it like 1
> client's
> > volume goes always to 1 storage...
> >
> > Any info appreciated !
> >
> > Thanks,
> >
> > --
> >
> > Andrija Panić
> >
>



-- 

Andrija Panić

Re: Primary Storage algorithm - when having more primary storages

[Abhinandan Prateek]

Following algorithms are used to select storage pool:

random, userconcentratedpod_random: RANDOM
userdispersing: Select on basis of least no of volumes
firstfitleastconsumed: Select on basis of remaining capacity

These values can be set for “vm.allocation.algorithm” global config variable.

-abhi

> On 20-Apr-2015, at 8:17 pm, Andrija Panic  wrote:
>
> Sorry for my ignorance - meaing completely random (except the scope ?)
>
> On 20 April 2015 at 16:01, Wei ZHOU  wrote:
>
>> /etc/cloudstack/management/componentContext.xml
>>
>>  > class="com.cloud.utils.component.AdapterList">
>>
>>  
>>  
>>  
>>  
>>  
>>
>>  
>>
>>
>> 2015-04-20 15:44 GMT+02:00 Andrija Panic :
>>
>>> Hi people,
>>>
>>> just wondering - if I have 3 primary storages (3 x NFS boxes) - what is
>> the
>>> volume alocation algoritm - is it compelte random, or is it like 1
>> client's
>>> volume goes always to 1 storage...
>>>
>>> Any info appreciated !
>>>
>>> Thanks,
>>>
>>> --
>>>
>>> Andrija Panić
>>>
>>
>
>
>
> --
>
> Andrija Panić

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

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

[GitHub] cloudstack pull request: fix typo in rsyslog logrotate script on V...

[remibergsma]

GitHub user remibergsma opened a pull request:

https://github.com/apache/cloudstack/pull/182

fix typo in rsyslog logrotate script on VR

This is fixed already in master and 4.5 and did not occur in 4.3 and 
before. This is a PR against 4.4 to fix it in 4.4 as well.

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

$ git pull https://github.com/remibergsma/cloudstack 4.4_rsyslog_fix

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

https://github.com/apache/cloudstack/pull/182.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 #182


commit fbddab848fa2b2cdc8d489f31c8eea40e8c098aa
Author: Remi Bergsma 
Date:   2015-04-20T16:10:26Z

fix typo in rsyslog logrotate script on VR

This is fixed already in master and 4.5 and did not occur in 4.3 and 
before. This fixes it in 4.4 as well.




---
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.
---

[GitHub] cloudstack pull request: fix typo in rsyslog logrotate script on V...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/182#issuecomment-94501510
  
LGTM.


---
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.
---

[GitHub] cloudstack pull request: use eu.ceph.com as ceph.com is down

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/175#issuecomment-94501965
  
Thanks @NuxRo can you close this PR as it's merged now.


---
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.
---

[GitHub] cloudstack pull request: use eu.ceph.com as ceph.com is down

[NuxRo]

Github user NuxRo closed the pull request at:

https://github.com/apache/cloudstack/pull/175


---
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.
---

[GitHub] cloudstack pull request: fix typo in rsyslog logrotate script on V...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/182#issuecomment-94551453
  
@remibergsma somehow this did not close the PR even though I added the 
"This closes #182" string. Can you please close it?


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

Re: OpenDaylight status

[ilya]

Chiradeep was on OpenDayLight board, perhaps he knows where we are with 
cloudstack..


On 4/19/15 1:41 AM, Erik Weber wrote:

Does anyone know what the status of the ODL plugin is?

Erik

Re: OpenDaylight status

[Chiradeep Vittal]

I’m not sure. I saw that somebody from Inocybe (Mathieu Lemay) was interested 
in supporting the plugin. As to whether it works with the latest release of 
ODL, not sure.

From: ilya
Reply-To: "dev@cloudstack.apache.org"
Date: Monday, April 20, 2015 at 2:59 PM
To: "dev@cloudstack.apache.org", Chiradeep 
Vittal
Subject: Re: OpenDaylight status

Chiradeep was on OpenDayLight board, perhaps he knows where we are with
cloudstack..

On 4/19/15 1:41 AM, Erik Weber wrote:
Does anyone know what the status of the ODL plugin is?

Erik

Re: OpenDaylight status

[Marcus]

What state was it in when it was merged? Functioning?

On Mon, Apr 20, 2015 at 4:19 PM, Chiradeep Vittal
 wrote:
> I’m not sure. I saw that somebody from Inocybe (Mathieu Lemay) was interested 
> in supporting the plugin. As to whether it works with the latest release of 
> ODL, not sure.
>
> From: ilya
> Reply-To: "dev@cloudstack.apache.org"
> Date: Monday, April 20, 2015 at 2:59 PM
> To: "dev@cloudstack.apache.org", Chiradeep 
> Vittal
> Subject: Re: OpenDaylight status
>
> Chiradeep was on OpenDayLight board, perhaps he knows where we are with
> cloudstack..
>
> On 4/19/15 1:41 AM, Erik Weber wrote:
> Does anyone know what the status of the ODL plugin is?
>
> Erik
>
>
>

RE: Primary Storage algorithm - when having more primary storages

[Prachi Damle]

By Default it is first fit - and that means the first one found with enough 
capacity. This results in the first one returned by the Db ordering to get 
allocated first until it has capacity.
One can choose the algorithm using vm.allocation.algorithm as Abhi mentioned. 

-Prachi

-Original Message-
From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com] 
Sent: Monday, April 20, 2015 8:37 AM
To: dev@cloudstack.apache.org
Subject: Re: Primary Storage algorithm - when having more primary storages

Following algorithms are used to select storage pool:

random, userconcentratedpod_random: RANDOM
userdispersing: Select on basis of least no of volumes
firstfitleastconsumed: Select on basis of remaining capacity

These values can be set for “vm.allocation.algorithm” global config variable.

-abhi

> On 20-Apr-2015, at 8:17 pm, Andrija Panic  wrote:
>
> Sorry for my ignorance - meaing completely random (except the scope ?)
>
> On 20 April 2015 at 16:01, Wei ZHOU  wrote:
>
>> /etc/cloudstack/management/componentContext.xml
>>
>>  > class="com.cloud.utils.component.AdapterList">
>>
>>  
>>  
>>  
>>  
>>  
>>
>>  
>>
>>
>> 2015-04-20 15:44 GMT+02:00 Andrija Panic :
>>
>>> Hi people,
>>>
>>> just wondering - if I have 3 primary storages (3 x NFS boxes) - what is
>> the
>>> volume alocation algoritm - is it compelte random, or is it like 1
>> client's
>>> volume goes always to 1 storage...
>>>
>>> Any info appreciated !
>>>
>>> Thanks,
>>>
>>> --
>>>
>>> Andrija Panić
>>>
>>
>
>
>
> --
>
> Andrija Panić

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & 
Build
CSForge – rapid IaaS deployment 
framework
CloudStack 
Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training 
Courses

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

Re: OpenDaylight status

[Chiradeep Vittal]

http://permalink.gmane.org/gmane.comp.apache.cloudstack.devel/35692


From: Marcus
Reply-To: "dev@cloudstack.apache.org"
Date: Monday, April 20, 2015 at 4:30 PM
To: "dev@cloudstack.apache.org"
Subject: Re: OpenDaylight status

What state was it in when it was merged? Functioning?

On Mon, Apr 20, 2015 at 4:19 PM, Chiradeep Vittal
mailto:chiradeep.vit...@citrix.com>> wrote:
I’m not sure. I saw that somebody from Inocybe (Mathieu Lemay) was interested 
in supporting the plugin. As to whether it works with the latest release of 
ODL, not sure.

From: ilya
Reply-To: 
"dev@cloudstack.apache.org"
Date: Monday, April 20, 2015 at 2:59 PM
To: 
"dev@cloudstack.apache.org",
 Chiradeep Vittal
Subject: Re: OpenDaylight status

Chiradeep was on OpenDayLight board, perhaps he knows where we are with
cloudstack..

On 4/19/15 1:41 AM, Erik Weber wrote:
Does anyone know what the status of the ODL plugin is?

Erik

[CLOUDSTACK DAYS TOKYO] CFP Deadline - April 24th

[Karen Vuong]

Hi everyone,

Just a friendly reminder that the CFP deadline for CloudStack Days Tokyo
has been extended to Friday, April 24th. You could submit your proposal
here: http://events.linuxfoundation.org/events/cloudstack-tokyo/program/cfp

Thanks,

Karen