Re: [ACS441][ACS431] Release-notes

[Daan Hoogland]

On Fri, Sep 12, 2014 at 4:17 AM, Pierre-Luc Dion  wrote:

> Also, should we removed untested upgrade path on those Release-notes?
>

​Sure, if we can identify them.

I will add the filters shortly​



-- 
Daan

[ACS44] patching for 4.4.1

[Daan Hoogland]

I am going to sound like a dictator and purposely so; Please refrain from
submitting to the 4.4 branch directly. Instead branch it as
hotfix/4.4- i.e. hotfix/4.4-7462 or alternatively
hotfix/4.4/CLOUDSTACK-7462.

​Release manager (ad interim​)
-- 
Daan

Re: [VOTE] Release Apache CloudStack 4.3.1 round #4

[Rohit Yadav]

On 12-Sep-2014, at 6:43 am, Erik Weber  wrote:
> Do we have an official upgrade path for those who want to upgrade?

Upgrade path exists between 4.3.0 and 4.3.1, and in 4.4 branch from 4.3.1 to 
4.4.1.

To upgrade systemvms, you can add an new template or register/seed the template.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.2+(KVM)+System+Vm+Upgrade
http://support.citrix.com/article/CTX200024

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | 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 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: [ACS441][ACS431] Release-notes

[Daan Hoogland]

Pierre-Luc, I made three, but the '4.4.1 known' is basically the same as
'4.4.1 issues', so I editted that one. See if it satisfies your needs.

-- 
Daan

Re: [ACS44] patching for 4.4.1

[Sebastien Goasguen]

On Sep 12, 2014, at 3:29 AM, Daan Hoogland  wrote:

> I am going to sound like a dictator and purposely so; Please refrain from
> submitting to the 4.4 branch directly. Instead branch it as
> hotfix/4.4- i.e. hotfix/4.4-7462 or alternatively
> hotfix/4.4/CLOUDSTACK-7462.
> 
> ​Release manager (ad interim​)

+1 you should be the only one committing to 4.4 branch

If the patch also applies to master, we need to clarify who merges that hot fix 
branch to master as well.
The tickets also need to be properly updated will all branches where it applies
And I would love for folks to keep the CHANGES file up to date.

> -- 
> Daan

Re: how to add devcloud

[Sebastien Goasguen]

On Sep 11, 2014, at 10:50 AM, sandeep khandekar  
wrote:

> Dear cloudstackers,
> 
> I am trying to install cloudstack 4.2  developer version from the following
> link.
> http://docs.cloudstack.apache.org/en/master/developer_guide.html
> 
> How to add devcloud?
> downloaded and started devcloud on virtualbox,
> 
> when I login I cant see primary and secondary storage, default templates
> not yet started?
> My doubt is do I need to execute the following commands in devcloud or my
> management server host

I usually do it on the mgt server (your localhost)

> Adding DevCloud as an Hypervisor
> 
> Picking up from a clean build:
> 
> mvn -Pdeveloper,systemvm clean install
> mvn -P developer -pl developer,tools/devcloud -Ddeploydb
> 
> At this stage install marvin similarly than with the simulator:
> 
> pip install tools/marvin/dist/Marvin-0.1.0.tar.gz
> 
> Start the management server
> 
> mvn -pl client jetty:run
> 
> Then you are going to configure CloudStack to use the running DevCloud
> instance:
> 
> cd tools/devcloud
> python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> 
> I execute the above commands on host not in devcloud.

Do you see errors in the mgt server logs, doe the marvin deployDataCenter 
script completes successfully ?

> My management server is in ubuntu and devcloud is on virtualbox.
> 
> How to add secstorage and primary storage after executing the below command
> 
> python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> 
> How to bring ssvm up and how to install tiny linux?
> 

They should all come up automatically after running
> python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg

You might want to check:
https://github.com/imduffy15/GSoC-2014

Which is an alternative to devcloud and works better.



> Thank you.
> 
> -- 
> SANDEEP KHANDEKAR
> Assistant Professor
> Department of Computer science and engineering
> Sreenidhi Institute of science and Technology
> Hyderabad

unresolved tickets

[Daan Hoogland]

H all,

Doing some backlog triaging I saw one (actually some) of Animesh' old
filters. There is a lot of tickets that are resolved but never closed. This
to me sounds like someone implemented a solution to them but the result was
never verified. I am guilty myself with 17 points. I made a filter [1] to
see any issue assigned to or reported by you, that is resolved and thus not
closed. Please let's all have a look and clean up the mess we left behind.
Usually there is two of us on these tickets and a little consult with each
other might be wise.

Our tickets are generally public and people (customers/users) like to see
that issues are closed. Resolved to some might mean that a clever
workaround has been thought of but no solution is implemented or that a lot
of code was written and consequential ticket are opened due to that but no
real testable solution is in place yet.

[1] https://issues.apache.org/jira/issues/?filter=12329277

​4.4.x dictator,​
-- 
Daan

Re: Review Request 24090: Externalized the hard-coded strings from JavaScript files to resource bundles.

[Vetrivel Chinnasamy]

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

(Updated Sept. 12, 2014, 9:42 a.m.)


Review request for cloudstack, Brian Federle and Jessica Wang.


Changes
---

Fixed the conflict.


Repository: cloudstack-git


Description
---

Externalized the hard-coded strings from JavaScript files to resource bundles. 
Updated the dictionary.jsp file accordingly. Also got the externalized strings 
translated in JA & SC.


Diffs (updated)
-

  client/WEB-INF/classes/resources/messages.properties 4655973 
  client/WEB-INF/classes/resources/messages_ja_JP.properties ed6a1b1 
  client/WEB-INF/classes/resources/messages_zh_CN.properties 2c497bc 
  ui/dictionary.jsp 0102144 
  ui/dictionary2.jsp PRE-CREATION 
  ui/index.jsp 48afa6a 
  ui/modules/vnmcAsa1000v/vnmcAsa1000v.js 621c52a 
  ui/modules/vnmcNetworkProvider/vnmcNetworkProvider.js c9295a3 
  ui/scripts/accounts.js cc4624a 
  ui/scripts/autoscaler.js c8963fd 
  ui/scripts/cloudStack.js 38cf501 
  ui/scripts/configuration.js a70c672 
  ui/scripts/domains.js 488382e 
  ui/scripts/events.js 2731cb6 
  ui/scripts/instances.js 4d536e3 
  ui/scripts/lbStickyPolicy.js 16995f6 
  ui/scripts/network.js 02dd269 
  ui/scripts/projects.js 53b7964 
  ui/scripts/regions.js 368c1bf 
  ui/scripts/sharedFunctions.js 41f5d3a 
  ui/scripts/storage.js f4ab6e1 
  ui/scripts/system.js 54aafe2 
  ui/scripts/templates.js 6dcd6da 
  ui/scripts/ui-custom/autoscaler.js 0aa6c77 
  ui/scripts/ui-custom/healthCheck.js 4e10f1c 
  ui/scripts/ui-custom/physicalResources.js 110945e 
  ui/scripts/ui-custom/regions.js 986e009 
  ui/scripts/ui-custom/zoneWizard.js f3a1aae 
  ui/scripts/ui/dialog.js 6c77924 
  ui/scripts/ui/widgets/listView.js c7b4a4d 
  ui/scripts/ui/widgets/multiEdit.js 47e5f43 
  ui/scripts/vpc.js 786cb26 
  ui/scripts/zoneWizard.js 4498534 

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


Testing
---

Tested by replacing the modified javascript , dictionary.jsp and properties 
files.


Thanks,

Vetrivel Chinnasamy

Re: Review Request 24090: Externalized the hard-coded strings from JavaScript files to resource bundles.

[Vetrivel Chinnasamy]

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

(Updated Sept. 12, 2014, 9:53 a.m.)


Review request for cloudstack, Brian Federle and Jessica Wang.


Changes
---

Fixed Conflict. 


Repository: cloudstack-git


Description
---

Externalized the hard-coded strings from JavaScript files to resource bundles. 
Updated the dictionary.jsp file accordingly. Also got the externalized strings 
translated in JA & SC.


Diffs (updated)
-

  client/WEB-INF/classes/resources/messages.properties 4655973 
  client/WEB-INF/classes/resources/messages_ja_JP.properties ed6a1b1 
  client/WEB-INF/classes/resources/messages_zh_CN.properties 2c497bc 
  ui/dictionary.jsp 0102144 
  ui/dictionary2.jsp PRE-CREATION 
  ui/index.jsp 48afa6a 
  ui/modules/vnmcAsa1000v/vnmcAsa1000v.js 621c52a 
  ui/modules/vnmcNetworkProvider/vnmcNetworkProvider.js c9295a3 
  ui/scripts/accounts.js cc4624a 
  ui/scripts/autoscaler.js c8963fd 
  ui/scripts/cloudStack.js 38cf501 
  ui/scripts/configuration.js a70c672 
  ui/scripts/domains.js 488382e 
  ui/scripts/events.js 2731cb6 
  ui/scripts/instances.js 4d536e3 
  ui/scripts/lbStickyPolicy.js 16995f6 
  ui/scripts/network.js 02dd269 
  ui/scripts/projects.js 53b7964 
  ui/scripts/regions.js 368c1bf 
  ui/scripts/sharedFunctions.js 41f5d3a 
  ui/scripts/storage.js f4ab6e1 
  ui/scripts/system.js 54aafe2 
  ui/scripts/templates.js 6dcd6da 
  ui/scripts/ui-custom/autoscaler.js 0aa6c77 
  ui/scripts/ui-custom/healthCheck.js 4e10f1c 
  ui/scripts/ui-custom/physicalResources.js 110945e 
  ui/scripts/ui-custom/regions.js 986e009 
  ui/scripts/ui-custom/zoneWizard.js f3a1aae 
  ui/scripts/ui/dialog.js 6c77924 
  ui/scripts/ui/widgets/listView.js c7b4a4d 
  ui/scripts/ui/widgets/multiEdit.js 47e5f43 
  ui/scripts/vpc.js 786cb26 
  ui/scripts/zoneWizard.js 4498534 

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


Testing
---

Tested by replacing the modified javascript , dictionary.jsp and properties 
files.


Thanks,

Vetrivel Chinnasamy

Re: [ACS441][ACS431] Release-notes

[Sebastien Goasguen]

On Sep 11, 2014, at 10:15 PM, Pierre-Luc Dion  wrote:

> Hi Daan,
> 
> could you create following public Jira filter to start Release-Notes for
> 4.3.1 and 4.4.1.
> 
> 4.4.1 fixed
> project = CLOUDSTACK AND type = Bug AND fixVersion = 4.4.1 AND resolution
> != "\"Unresolved\"" ORDER BY created DESC, priority DESC, key ASC
> 
> 4.4.1 known
> project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.4.1 or
> affectedVersion = 4.4.0) AND resolution is EMPTY AND level = "Public" ORDER
> BY priority DESC, key ASC
> 
> 4.3.1 fixed
> project = CLOUDSTACK AND type = Bug AND fixVersion = 4.3.1 AND resolution
> != "\"Unresolved\"" ORDER BY created DESC, priority DESC, key ASC
> 

I have tried to keep the CHANGES.md file in the 4.3 branch up to date, so it 
should contain the list of bug fixed in 4.3.1

> 4.3.1 known
> project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.3.1 or
> affectedVersion = 4.3.0) AND resolution is EMPTY AND level = "Public" ORDER
> BY priority DESC, key ASC
> 
> 
> Also , does anyone is working on RN of 4.4.1 or 4.3.1? I can work on 4.4.1,
> maybe on the 4.3.1.

Jenkins build is still unstable: simulator-singlerun #348

[jenkins]

See 

Re: [ACS441][ACS431] Release-notes

[Daan Hoogland]

Sebastien, a generated file is more reliable, isn't it? or else one of my
former manageres favorite Stalin quote: "Trust is good, control is better"


On Fri, Sep 12, 2014 at 12:33 PM, Sebastien Goasguen 
wrote:

>
> On Sep 11, 2014, at 10:15 PM, Pierre-Luc Dion  wrote:
>
> > Hi Daan,
> >
> > could you create following public Jira filter to start Release-Notes for
> > 4.3.1 and 4.4.1.
> >
> > 4.4.1 fixed
> > project = CLOUDSTACK AND type = Bug AND fixVersion = 4.4.1 AND resolution
> > != "\"Unresolved\"" ORDER BY created DESC, priority DESC, key ASC
> >
> > 4.4.1 known
> > project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.4.1 or
> > affectedVersion = 4.4.0) AND resolution is EMPTY AND level = "Public"
> ORDER
> > BY priority DESC, key ASC
> >
> > 4.3.1 fixed
> > project = CLOUDSTACK AND type = Bug AND fixVersion = 4.3.1 AND resolution
> > != "\"Unresolved\"" ORDER BY created DESC, priority DESC, key ASC
> >
>
> I have tried to keep the CHANGES.md file in the 4.3 branch up to date, so
> it should contain the list of bug fixed in 4.3.1
>
> > 4.3.1 known
> > project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.3.1 or
> > affectedVersion = 4.3.0) AND resolution is EMPTY AND level = "Public"
> ORDER
> > BY priority DESC, key ASC
> >
> >
> > Also , does anyone is working on RN of 4.4.1 or 4.3.1? I can work on
> 4.4.1,
> > maybe on the 4.3.1.
>
>


-- 
Daan

Re: [ACS441][ACS431] Release-notes

[Sebastien Goasguen]

On Sep 12, 2014, at 6:52 AM, Daan Hoogland  wrote:

> Sebastien, a generated file is more reliable, isn't it? or else one of my
> former manageres favorite Stalin quote: "Trust is good, control is better"
> 

yes and I even wrote the script that pulls the bugs form jira:
https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs-rn.git;a=blob;f=utils/jira.py;h=c4b931de0aade4416f465858a7fea50ab7be01f8;hb=master

But it would be nice if committers would get in the habit of updating the 
CHANGES files when they fix a bug.

Otherwise why do we have a CHANGES file in the first place ?

> 
> On Fri, Sep 12, 2014 at 12:33 PM, Sebastien Goasguen 
> wrote:
> 
>> 
>> On Sep 11, 2014, at 10:15 PM, Pierre-Luc Dion  wrote:
>> 
>>> Hi Daan,
>>> 
>>> could you create following public Jira filter to start Release-Notes for
>>> 4.3.1 and 4.4.1.
>>> 
>>> 4.4.1 fixed
>>> project = CLOUDSTACK AND type = Bug AND fixVersion = 4.4.1 AND resolution
>>> != "\"Unresolved\"" ORDER BY created DESC, priority DESC, key ASC
>>> 
>>> 4.4.1 known
>>> project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.4.1 or
>>> affectedVersion = 4.4.0) AND resolution is EMPTY AND level = "Public"
>> ORDER
>>> BY priority DESC, key ASC
>>> 
>>> 4.3.1 fixed
>>> project = CLOUDSTACK AND type = Bug AND fixVersion = 4.3.1 AND resolution
>>> != "\"Unresolved\"" ORDER BY created DESC, priority DESC, key ASC
>>> 
>> 
>> I have tried to keep the CHANGES.md file in the 4.3 branch up to date, so
>> it should contain the list of bug fixed in 4.3.1
>> 
>>> 4.3.1 known
>>> project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.3.1 or
>>> affectedVersion = 4.3.0) AND resolution is EMPTY AND level = "Public"
>> ORDER
>>> BY priority DESC, key ASC
>>> 
>>> 
>>> Also , does anyone is working on RN of 4.4.1 or 4.3.1? I can work on
>> 4.4.1,
>>> maybe on the 4.3.1.
>> 
>> 
> 
> 
> -- 
> Daan

RE: Problem of build

[Yitao Jiang]

Logs will be more helpful
On Sep 11, 2014 5:40 PM, "Stephen Turner"  wrote:

> Could you send the exact errors?
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: yan_5...@163.com [mailto:yan_5...@163.com]
> Sent: 11 September 2014 08:35
> To: dev
> Subject: Problem of build
>
> If I modify a function and make sure the modify is correct,and run "mvn
> clean install",it will be many kinds of strange error.
>
> who can help me? Thanks very much
>
>
>
> yan_5...@163.com
>

Virtual Machine Instance suddenly not starting

[Giri Prasad]

Hello,

 I created a fresh install of Ubuntu 14.04 LTS and cloudstack 4.1 on 
4-Sep-2014. Uploaded a couple of ISO's into the cs environment. Then created 
some instances based on these ISO. Booted the vm (instance), installed the os 
(centos 6.5). Everything was working fine.

 Today, I started the same Ubuntu server, the cs management server and agent. 
The gui console opens up, and I see two system vm's in 'Running' state.

 I selected the (user) instance, clicked on the start instance button. The 
system runs forever, with the state of the user instance(vm), being shown as 
'Starting'.

The last few lines of the management server log are in : 
http://pastebin.com/tp7SmpPh

It is the same the system setup, and I have changed nothing. Any ideas on, why 
is the user instance not starting?

Thanks & Regards,
Giri

Jenkins build is still unstable: simulator-singlerun #349

[jenkins]

See 

Re: [ACS441][ACS431] Release-notes

[Pierre-Luc Dion]

Thanks Daan, I'll start with that.   I will update CHANGE.md as well.


*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_


On Fri, Sep 12, 2014 at 7:01 AM, Sebastien Goasguen 
wrote:

>
> On Sep 12, 2014, at 6:52 AM, Daan Hoogland 
> wrote:
>
> > Sebastien, a generated file is more reliable, isn't it? or else one of my
> > former manageres favorite Stalin quote: "Trust is good, control is
> better"
> >
>
> yes and I even wrote the script that pulls the bugs form jira:
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs-rn.git;a=blob;f=utils/jira.py;h=c4b931de0aade4416f465858a7fea50ab7be01f8;hb=master
>
> But it would be nice if committers would get in the habit of updating the
> CHANGES files when they fix a bug.
>
> Otherwise why do we have a CHANGES file in the first place ?
>
> >
> > On Fri, Sep 12, 2014 at 12:33 PM, Sebastien Goasguen 
> > wrote:
> >
> >>
> >> On Sep 11, 2014, at 10:15 PM, Pierre-Luc Dion 
> wrote:
> >>
> >>> Hi Daan,
> >>>
> >>> could you create following public Jira filter to start Release-Notes
> for
> >>> 4.3.1 and 4.4.1.
> >>>
> >>> 4.4.1 fixed
> >>> project = CLOUDSTACK AND type = Bug AND fixVersion = 4.4.1 AND
> resolution
> >>> != "\"Unresolved\"" ORDER BY created DESC, priority DESC, key ASC
> >>>
> >>> 4.4.1 known
> >>> project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.4.1 or
> >>> affectedVersion = 4.4.0) AND resolution is EMPTY AND level = "Public"
> >> ORDER
> >>> BY priority DESC, key ASC
> >>>
> >>> 4.3.1 fixed
> >>> project = CLOUDSTACK AND type = Bug AND fixVersion = 4.3.1 AND
> resolution
> >>> != "\"Unresolved\"" ORDER BY created DESC, priority DESC, key ASC
> >>>
> >>
> >> I have tried to keep the CHANGES.md file in the 4.3 branch up to date,
> so
> >> it should contain the list of bug fixed in 4.3.1
> >>
> >>> 4.3.1 known
> >>> project = CLOUDSTACK AND type = Bug AND (affectedVersion = 4.3.1 or
> >>> affectedVersion = 4.3.0) AND resolution is EMPTY AND level = "Public"
> >> ORDER
> >>> BY priority DESC, key ASC
> >>>
> >>>
> >>> Also , does anyone is working on RN of 4.4.1 or 4.3.1? I can work on
> >> 4.4.1,
> >>> maybe on the 4.3.1.
> >>
> >>
> >
> >
> > --
> > Daan
>
>

Jenkins build is still unstable: simulator-singlerun #350

[jenkins]

See 

Review Request 25580: Adding test case to verify fix for issue "Create volume from custom disk offering does not work as expected"

[sanjeev n]

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

Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.


Repository: cloudstack-git


Description
---

@Desc:Create volume from custom disk offering does not work as expected
Step1:Create custom disk offering
Step2:Create Volume with size x
Step3:Attach that volume to a vm
Step4:Create another volume with size y
Step5:Verify that the new volume is created with size Y but not with size X
  


Diffs
-

  test/integration/component/test_escalations_volumes.py db4c3d8 
  tools/marvin/marvin/lib/base.py 04217b2 

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


Testing
---

Yes

@Desc:Create volume from custom disk offering does not work as expected ... === 
TestName: test_13_volume_custom_disk_size | Status : SUCCESS ===
ok

--
Ran 1 test in 303.508s

OK


Thanks,

sanjeev n

how to bring ssvm up in developer installation

[sandeep khandekar]

Dear cloudstackers,

I am trying to install cloudstack 4.2 devloper version using ubuntu 12.04
and virtualbox for devcloud2.
I have added devcloud2 using the following documentation(
http://docs.cloudstack.apache.org/en/master/developer_guide.html)
everything went ok, I am getting the following error.

  [storage.image.TemplateServiceImpl] (AgentTaskPool-1:) Downloading
builtin template tiny Linux to data center: 1
INFO  [storage.endpoint.DefaultEndPointSelector] (AgentTaskPool-1:) No
running ssvm is found, so command will be sent to LocalHostEndPoint
INFO  [storage.endpoint.DefaultEndPointSelector] (StatsCollector-3:) No
running ssvm is found, so command will be sent to LocalHostEndPoint
WARN  [apache.cloudstack.alerts] (CapacityChecker:)  alertType:: 5 //
dataCenterId:: 1 // podId:: 1 // clusterId:: null // message:: System
Alert: Number of unallocated private IPs is low in pod test00 of
availability zone DevCloud0
INFO  [storage.resource.NfsSecondaryStorageResource] (pool-70-thread-1:)
snapshots directory created/exists on Secondary Storage.
INFO  [storage.resource.NfsSecondaryStorageResource] (pool-70-thread-1:)
volumes directory created/exists on Secondary Storage.
INFO  [cloud.secstorage.PremiumSecondaryStorageManagerImpl] (secstorage-1:)
No running secondary storage vms found in datacenter id=1, starting one
INFO  [storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:) No
stopped secondary storage vm is available, need to allocate a new secondary
storage vm
INFO  [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:) Found
a stopped console proxy, bring it up to running pool. proxy vm id : 2
INFO  [cloud.vm.VirtualMachineManagerImpl] (consoleproxy-1:) Insufficient
capacity
com.cloud.exception.InsufficientAddressCapacityException: Unable to get a
management ip addressScope=interface com.cloud.dc.Pod; id=1
at
com.cloud.network.guru.PodBasedNetworkGuru.reserve(PodBasedNetworkGuru.java:121)
at
com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:2166)
at
com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2136)


, will recycle it and start a new one
WARN  [xen.resource.CitrixResourceBase] (DirectAgent-21:) callHostPlugin
failed for cmd: setDNATRule with args add: false,  due to
UNKNOWN_XENAPI_PLUGIN_FUNCTIONsetDNATRule
WARN  [agent.manager.DirectAgentAttache] (DirectAgent-21:) Seq
1-1261830169: Exception Caught while executing command
com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for
cmd: setDNATRule with args add: false,  due to
UNKNOWN_XENAPI_PLUGIN_FUNCTIONsetDNATRule


INFO  [storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:)
Unable to start secondary storage vm for standby capacity, secStorageVm vm
Id : 35, will recycle it and start a new one
INFO  [cloud.secstorage.PremiumSecondaryStorageManagerImpl] (secstorage-1:)
Primary secondary storage is not even started, wait until nex

so how to start primary storage and secondary storage if I have followed
the above link for installation(how to start nfs on ubuntu how to mount nfs
on devcloud) none of the steps are included in doc.


Thankyou..





-- 
SANDEEP KHANDEKAR
Assistant Professor
Department of Computer science and engineering
Sreenidhi Institute of science and Technology
Hyderabad

Jenkins build is still unstable: simulator-singlerun #351

[jenkins]

See 

CentOS KVM systemvm issue

[John Skinner]

I have found that on CloudStack 4.2 + (when we changed to using the 
virtio-socket to send data to the systemvm) when running CentOS 6.X 
cloud-early-config fails. On new systemvm creation there is a high chance for 
success, but still a chance for failure. After the systemvm has been created a 
simple reboot will cause start to fail every time. This has been confirmed on 2 
separate CloudStack 4.2 environments; 1 running CentOS 6.3 KVM, and another 
running CentOS 6.2 KVM. This can be fixed with a simple modification to the 
get_boot_params function in the cloud-early-config script. If you wrap the 
while read line inside of another while that checks if $cmd returns an empty 
string it fixes the issue.

This is a pretty nasty issue for any one running CloudStack 4.2 + on CentOS 6.X

John Skinner
Appcore

Access to non-oss builds

[Pradeep Cloudstack]

We have a customer who is interested in trying out non-oss build (for eg: 
support for VMWare, SRX).Internally, we have built and tested the non-oss 
builds.


What are the licensing implications in distributing such non-oss builds? Does 
it follow Apache license ?
Is there any process involved ?


-Pradeep

Re: CentOS KVM systemvm issue

[Marcus]

Can you provide more info? Is the host running CentOS 6.x, or is your
systemvm? What is rebooted, the host or the router, and how is it rebooted?
 We have what sounds like the same config (CentOS 6.x hosts, stock
community provided systemvm), and are running thousands of virtual routers,
rebooted regularly with no issue (both hosts and virtual routers).  One
setting we may have that you may not is that our system vms are rebuilt
from scratch on every reboot (recreate.systemvm.enabled=true in global
settings), not that I expect this to be the problem, but might be something
to look at.

On Fri, Sep 12, 2014 at 8:49 AM, John Skinner 
wrote:

> I have found that on CloudStack 4.2 + (when we changed to using the
> virtio-socket to send data to the systemvm) when running CentOS 6.X
> cloud-early-config fails. On new systemvm creation there is a high chance
> for success, but still a chance for failure. After the systemvm has been
> created a simple reboot will cause start to fail every time. This has been
> confirmed on 2 separate CloudStack 4.2 environments; 1 running CentOS 6.3
> KVM, and another running CentOS 6.2 KVM. This can be fixed with a simple
> modification to the get_boot_params function in the cloud-early-config
> script. If you wrap the while read line inside of another while that checks
> if $cmd returns an empty string it fixes the issue.
>
> This is a pretty nasty issue for any one running CloudStack 4.2 + on
> CentOS 6.X
>
> John Skinner
> Appcore

Re: CentOS KVM systemvm issue

[Marcus]

You may also want to investigate on whether you are seeing a race condition
with /dev/vport0p1 coming on line and cloud-early-config running. It will
be indicated by a log line in the systemvm /var/log/cloud.log:

log_it "/dev/vport0p1 not loaded, perhaps guest kernel is too old."

Actually, if it has anything to do with the virtio-serial socket that would
probably be logged. Can you open a bug in Jira and provide the logs?

On Fri, Sep 12, 2014 at 9:36 AM, Marcus  wrote:

> Can you provide more info? Is the host running CentOS 6.x, or is your
> systemvm? What is rebooted, the host or the router, and how is it rebooted?
>  We have what sounds like the same config (CentOS 6.x hosts, stock
> community provided systemvm), and are running thousands of virtual routers,
> rebooted regularly with no issue (both hosts and virtual routers).  One
> setting we may have that you may not is that our system vms are rebuilt
> from scratch on every reboot (recreate.systemvm.enabled=true in global
> settings), not that I expect this to be the problem, but might be something
> to look at.
>
> On Fri, Sep 12, 2014 at 8:49 AM, John Skinner 
> wrote:
>
>> I have found that on CloudStack 4.2 + (when we changed to using the
>> virtio-socket to send data to the systemvm) when running CentOS 6.X
>> cloud-early-config fails. On new systemvm creation there is a high chance
>> for success, but still a chance for failure. After the systemvm has been
>> created a simple reboot will cause start to fail every time. This has been
>> confirmed on 2 separate CloudStack 4.2 environments; 1 running CentOS 6.3
>> KVM, and another running CentOS 6.2 KVM. This can be fixed with a simple
>> modification to the get_boot_params function in the cloud-early-config
>> script. If you wrap the while read line inside of another while that checks
>> if $cmd returns an empty string it fixes the issue.
>>
>> This is a pretty nasty issue for any one running CloudStack 4.2 + on
>> CentOS 6.X
>>
>> John Skinner
>> Appcore
>
>
>

Review Request 25585: [CLOUDSTACK-2823] SystemVMs start fail on CentOS 6.4

[David Bierce]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

SystemVMs start fail on CentOS 6


Diffs
-

  systemvm/patches/debian/config/etc/init.d/cloud-early-config 9152df2 

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


Testing
---

Code patch applied to Systemvm.iso and cloud-early inside the systemvm 
template.  Routers start consitently after patched.

Tested against cloudstack 4.2.1
Centos 6.4

Patch is against 4.3 since 4.2+ is effected by the issue.


Thanks,

David Bierce

Question about Marvin

[Mike Tutkowski]

Hi,

I was wondering, do we leverage a code generator at all for building parts
of the Marvin codebase or is code like "StoragePool" all written manually?

Thanks!

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

Jenkins build is still unstable: simulator-singlerun #352

[jenkins]

See 

Re: Access to non-oss builds

[Ian Duffy]

Hi Pradeep,

As far as I know there isn't an issue. The community supplied repos
includes non-oss libraries.

I believe its only an issue if they are hosted on Apache infrastructure.
On 12 Sep 2014 16:29, "Pradeep Cloudstack"
 wrote:

> We have a customer who is interested in trying out non-oss build (for eg:
> support for VMWare, SRX).Internally, we have built and tested the non-oss
> builds.
>
>
> What are the licensing implications in distributing such non-oss builds?
> Does it follow Apache license ?
> Is there any process involved ?
>
>
> -Pradeep
>

Jenkins build is still unstable: simulator-singlerun #353

[jenkins]

See 

Re: IPv6 ~ Basic Network

[John Kinsella]

The neighbor table attack scenario reminds me of VLAN flattening attack 
scenarios of days past - in theory you could blast a switch hard enough that 
the switch’s CPU lowers VLAN tagging priority and the network “flattens” out, 
turning switch into hub. In reality, the vendors quickly realized the situation 
as less-than-optimal and coded around it. 

This thread got me thinking of something else that might be interesting to 
think about: what about having virtual routers proxy DHCP requests[1] for v4 or 
v6? 

John
1: 
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_relaying

On Sep 5, 2014, at 7:52 AM, Wido den Hollander  wrote:

> 
> 
> On 05-09-14 12:42, Nux! wrote:
>> Hi,
>> 
>> I've been thinking about this and apparently there is a big security problem 
>> with this idea, at least my colleagues from the network dept tell me so.
>> If you want to use the router autoconfig thingy you must - as per current 
>> standards - use a /64 on the router interface and this way you expose 
>> yourself to a neighbour table attack - the neighbour table in avg cisco 
>> routers can hold tens of thousands of entries more or less, but it's still 
>> far from the trillions of addresses in a /64. This may seem far fetched but 
>> since 512k day, my colleagues don't want to take any more chances. :-)
> 
> That only works if you actually spawn thousands of instances in that subnet.
> 
> One of the things people told me that you could overflow the neighbour table 
> by sending packets to bogus IPv6 addresses.
> 
> I tried that some weeks ago on a Brocade and Extreme Networks router, but 
> they both have a system of "valid neighbours" and "pending neighbours".
> 
> Only when a neighbour actually responded it goes into the "valid" table and 
> otherwise it is kicked out of the "pending" pretty quickly.
> 
> I could not overflow any table or make them drop traffic to legitimate hosts.
> 
>> They recommend to use DHCPv6 instead with far smaller subnets, which of 
>> course complicates things quite a bit on the cloudstack side...
>> 
> 
> Well, we would still need DHCPv6 to hand out additional options like DNS, but 
> yes. Since with the subnet + MAC you can calculate which IPv6 address the 
> Instance will use based on SLAAC.
> 
> We can program that address into the security groups and that's the IPv6 
> address the guest can use.
> 
> Additional IPs is just a matter of generating a address, storing it and 
> adding it to the SG.
> 
> So Router Advertisements are a very easy option to use.
> 
>> Any thoughts?
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> - Original Message -
>>> From: "John Kinsella" 
>>> To: dev@cloudstack.apache.org
>>> Sent: Wednesday, 20 August, 2014 11:59:27 PM
>>> Subject: Re: IPv6 ~ Basic Network
>>> 
>>> Please do - we started tinkering with ipv6 ages ago, never got it to
>>> production, tho.
>>> 
>>> On Aug 20, 2014, at 3:48 PM, Nux!  wrote:
>>> 
 Thanks Wido for the idea, then. :-)
 I'll gladly share it with you guys should I come up with something that
 works.
 
 Lucian
 
 --
 Sent from the Delta quadrant using Borg technology!
 
 Nux!
 www.nux.ro
 
 
 - Original Message -
> From: "Wido den Hollander" 
> To: dev@cloudstack.apache.org
> Sent: Wednesday, 20 August, 2014 9:36:48 PM
> Subject: Re: IPv6 ~ Basic Network
> 
> 
> 
> On 08/20/2014 10:07 PM, Nux! wrote:
>> Wido,
>> 
>> Can you share your code for this?
>> 
> 
> Oh, I don't have any code. The setups I created have plain IPv6 without
> any security grouping.
> 
> My previous e-mail was just to illustrate what would be required.
> 
> Wido
> 
>> Cheers
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
> 
>>> 
>>> 
>>> 

Re: CentOS KVM systemvm issue

[John Skinner]

Actually, I believe the kernel is the problem. The hosts are running CentOS 6, 
the systemvm is stock template, Debian 7. This does not seem to be an issue on 
Ubuntu KVM hypervisors.

The fact that you are rebuilding systemvms on reboot is exactly why you are not 
seeing this issue. New system VMs are usually successful, it’s when you reboot 
them or start a stopped one where this issue shows up.

The serial port is loading, but I think the behavior is different after initial 
boot because if you access the system VM after you reboot it you do not have 
anything on /proc/cmdline and in /var/cache/cloud/cmdline the file is old and 
does not contain the new control network IP address. However, I am able to net 
cat the serial port between the hypervisor and the systemvm after it comes up - 
but CloudStack will eventually force stop the VM since it doesn’t get the new 
control network IP address it assumes it never started.

Which is why when we wrap that while loop to check for an empty string on $cmd 
it works every time after that.

Change that global setting from true to false, and try to reboot a few routers. 
I guarantee you will see this issue.

John Skinner
Appcore

On Sep 12, 2014, at 10:48 AM, Marcus  wrote:

> You may also want to investigate on whether you are seeing a race condition
> with /dev/vport0p1 coming on line and cloud-early-config running. It will
> be indicated by a log line in the systemvm /var/log/cloud.log:
> 
> log_it "/dev/vport0p1 not loaded, perhaps guest kernel is too old."
> 
> Actually, if it has anything to do with the virtio-serial socket that would
> probably be logged. Can you open a bug in Jira and provide the logs?
> 
> On Fri, Sep 12, 2014 at 9:36 AM, Marcus  wrote:
> 
>> Can you provide more info? Is the host running CentOS 6.x, or is your
>> systemvm? What is rebooted, the host or the router, and how is it rebooted?
>> We have what sounds like the same config (CentOS 6.x hosts, stock
>> community provided systemvm), and are running thousands of virtual routers,
>> rebooted regularly with no issue (both hosts and virtual routers).  One
>> setting we may have that you may not is that our system vms are rebuilt
>> from scratch on every reboot (recreate.systemvm.enabled=true in global
>> settings), not that I expect this to be the problem, but might be something
>> to look at.
>> 
>> On Fri, Sep 12, 2014 at 8:49 AM, John Skinner 
>> wrote:
>> 
>>> I have found that on CloudStack 4.2 + (when we changed to using the
>>> virtio-socket to send data to the systemvm) when running CentOS 6.X
>>> cloud-early-config fails. On new systemvm creation there is a high chance
>>> for success, but still a chance for failure. After the systemvm has been
>>> created a simple reboot will cause start to fail every time. This has been
>>> confirmed on 2 separate CloudStack 4.2 environments; 1 running CentOS 6.3
>>> KVM, and another running CentOS 6.2 KVM. This can be fixed with a simple
>>> modification to the get_boot_params function in the cloud-early-config
>>> script. If you wrap the while read line inside of another while that checks
>>> if $cmd returns an empty string it fixes the issue.
>>> 
>>> This is a pretty nasty issue for any one running CloudStack 4.2 + on
>>> CentOS 6.X
>>> 
>>> John Skinner
>>> Appcore
>> 
>> 
>> 

Re: CentOS KVM systemvm issue

[David Bierce]

John —

I’ve submitted our patch to work around the issue to review board and tied it 
to the original ticket we found.  I submitted it against the 4.3 but I know 
you’ve been testing the patch on 4.2.  If someone could take a look at it for 
sanity, please check.  It looks like it would be an issue in all version of 
cloudstack on CentOS/KVM as a hypervisor.

Review Request 25585: [CLOUDSTACK-2823] SystemVMs start fail on CentOS 6.4




Thanks,
David Bierce
Senior System Administrator  | Appcore

Office +1.800.735.7104
Direct +1.515.612.7801 
www.appcore.com

On Sep 12, 2014, at 1:23 PM, John Skinner  wrote:

> Actually, I believe the kernel is the problem. The hosts are running CentOS 
> 6, the systemvm is stock template, Debian 7. This does not seem to be an 
> issue on Ubuntu KVM hypervisors.
> 
> The fact that you are rebuilding systemvms on reboot is exactly why you are 
> not seeing this issue. New system VMs are usually successful, it’s when you 
> reboot them or start a stopped one where this issue shows up.
> 
> The serial port is loading, but I think the behavior is different after 
> initial boot because if you access the system VM after you reboot it you do 
> not have anything on /proc/cmdline and in /var/cache/cloud/cmdline the file 
> is old and does not contain the new control network IP address. However, I am 
> able to net cat the serial port between the hypervisor and the systemvm after 
> it comes up - but CloudStack will eventually force stop the VM since it 
> doesn’t get the new control network IP address it assumes it never started.
> 
> Which is why when we wrap that while loop to check for an empty string on 
> $cmd it works every time after that.
> 
> Change that global setting from true to false, and try to reboot a few 
> routers. I guarantee you will see this issue.
> 
> John Skinner
> Appcore
> 
> On Sep 12, 2014, at 10:48 AM, Marcus  wrote:
> 
>> You may also want to investigate on whether you are seeing a race condition
>> with /dev/vport0p1 coming on line and cloud-early-config running. It will
>> be indicated by a log line in the systemvm /var/log/cloud.log:
>> 
>> log_it "/dev/vport0p1 not loaded, perhaps guest kernel is too old."
>> 
>> Actually, if it has anything to do with the virtio-serial socket that would
>> probably be logged. Can you open a bug in Jira and provide the logs?
>> 
>> On Fri, Sep 12, 2014 at 9:36 AM, Marcus  wrote:
>> 
>>> Can you provide more info? Is the host running CentOS 6.x, or is your
>>> systemvm? What is rebooted, the host or the router, and how is it rebooted?
>>> We have what sounds like the same config (CentOS 6.x hosts, stock
>>> community provided systemvm), and are running thousands of virtual routers,
>>> rebooted regularly with no issue (both hosts and virtual routers).  One
>>> setting we may have that you may not is that our system vms are rebuilt
>>> from scratch on every reboot (recreate.systemvm.enabled=true in global
>>> settings), not that I expect this to be the problem, but might be something
>>> to look at.
>>> 
>>> On Fri, Sep 12, 2014 at 8:49 AM, John Skinner 
>>> wrote:
>>> 
 I have found that on CloudStack 4.2 + (when we changed to using the
 virtio-socket to send data to the systemvm) when running CentOS 6.X
 cloud-early-config fails. On new systemvm creation there is a high chance
 for success, but still a chance for failure. After the systemvm has been
 created a simple reboot will cause start to fail every time. This has been
 confirmed on 2 separate CloudStack 4.2 environments; 1 running CentOS 6.3
 KVM, and another running CentOS 6.2 KVM. This can be fixed with a simple
 modification to the get_boot_params function in the cloud-early-config
 script. If you wrap the while read line inside of another while that checks
 if $cmd returns an empty string it fixes the issue.
 
 This is a pretty nasty issue for any one running CloudStack 4.2 + on
 CentOS 6.X
 
 John Skinner
 Appcore
>>> 
>>> 
>>> 
> 

Re: CentOS KVM systemvm issue

[Marcus]

Looks good, and I was going to suggest waiting like that if it turned out
to be a race condition. The only thing I would suggest is maybe a sleep so
it doesn't kill CPU if for some reason the system vm never gets cmdline.
On Sep 12, 2014 1:28 PM, "David Bierce"  wrote:

> John —
>
> I’ve submitted our patch to work around the issue to review board and tied
> it to the original ticket we found.  I submitted it against the 4.3 but I
> know you’ve been testing the patch on 4.2.  If someone could take a look at
> it for sanity, please check.  It looks like it would be an issue in all
> version of cloudstack on CentOS/KVM as a hypervisor.
>
> Review Request 25585: [CLOUDSTACK-2823] SystemVMs start fail on CentOS 6.4
>
>
>
>
> Thanks,
> David Bierce
> Senior System Administrator  | Appcore
>
> Office +1.800.735.7104
> Direct +1.515.612.7801
> www.appcore.com
>
> On Sep 12, 2014, at 1:23 PM, John Skinner 
> wrote:
>
> > Actually, I believe the kernel is the problem. The hosts are running
> CentOS 6, the systemvm is stock template, Debian 7. This does not seem to
> be an issue on Ubuntu KVM hypervisors.
> >
> > The fact that you are rebuilding systemvms on reboot is exactly why you
> are not seeing this issue. New system VMs are usually successful, it’s when
> you reboot them or start a stopped one where this issue shows up.
> >
> > The serial port is loading, but I think the behavior is different after
> initial boot because if you access the system VM after you reboot it you do
> not have anything on /proc/cmdline and in /var/cache/cloud/cmdline the file
> is old and does not contain the new control network IP address. However, I
> am able to net cat the serial port between the hypervisor and the systemvm
> after it comes up - but CloudStack will eventually force stop the VM since
> it doesn’t get the new control network IP address it assumes it never
> started.
> >
> > Which is why when we wrap that while loop to check for an empty string
> on $cmd it works every time after that.
> >
> > Change that global setting from true to false, and try to reboot a few
> routers. I guarantee you will see this issue.
> >
> > John Skinner
> > Appcore
> >
> > On Sep 12, 2014, at 10:48 AM, Marcus  wrote:
> >
> >> You may also want to investigate on whether you are seeing a race
> condition
> >> with /dev/vport0p1 coming on line and cloud-early-config running. It
> will
> >> be indicated by a log line in the systemvm /var/log/cloud.log:
> >>
> >> log_it "/dev/vport0p1 not loaded, perhaps guest kernel is too old."
> >>
> >> Actually, if it has anything to do with the virtio-serial socket that
> would
> >> probably be logged. Can you open a bug in Jira and provide the logs?
> >>
> >> On Fri, Sep 12, 2014 at 9:36 AM, Marcus  wrote:
> >>
> >>> Can you provide more info? Is the host running CentOS 6.x, or is your
> >>> systemvm? What is rebooted, the host or the router, and how is it
> rebooted?
> >>> We have what sounds like the same config (CentOS 6.x hosts, stock
> >>> community provided systemvm), and are running thousands of virtual
> routers,
> >>> rebooted regularly with no issue (both hosts and virtual routers).  One
> >>> setting we may have that you may not is that our system vms are rebuilt
> >>> from scratch on every reboot (recreate.systemvm.enabled=true in global
> >>> settings), not that I expect this to be the problem, but might be
> something
> >>> to look at.
> >>>
> >>> On Fri, Sep 12, 2014 at 8:49 AM, John Skinner <
> john.skin...@appcore.com>
> >>> wrote:
> >>>
>  I have found that on CloudStack 4.2 + (when we changed to using the
>  virtio-socket to send data to the systemvm) when running CentOS 6.X
>  cloud-early-config fails. On new systemvm creation there is a high
> chance
>  for success, but still a chance for failure. After the systemvm has
> been
>  created a simple reboot will cause start to fail every time. This has
> been
>  confirmed on 2 separate CloudStack 4.2 environments; 1 running CentOS
> 6.3
>  KVM, and another running CentOS 6.2 KVM. This can be fixed with a
> simple
>  modification to the get_boot_params function in the cloud-early-config
>  script. If you wrap the while read line inside of another while that
> checks
>  if $cmd returns an empty string it fixes the issue.
> 
>  This is a pretty nasty issue for any one running CloudStack 4.2 + on
>  CentOS 6.X
> 
>  John Skinner
>  Appcore
> >>>
> >>>
> >>>
> >
>
>

Jenkins build is still unstable: simulator-singlerun #354

[jenkins]

See 

Re: Review Request 25585: [CLOUDSTACK-2823] SystemVMs start fail on CentOS 6.4

[David Bierce]

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

(Updated Sept. 13, 2014, 1:01 a.m.)


Review request for cloudstack.


Changes
---

Updated Patch to include a sleep while looping on the serial interface waiting 
for messages


Repository: cloudstack-git


Description
---

SystemVMs start fail on CentOS 6


Diffs
-

  systemvm/patches/debian/config/etc/init.d/cloud-early-config 9152df2 

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


Testing
---

Code patch applied to Systemvm.iso and cloud-early inside the systemvm 
template.  Routers start consitently after patched.

Tested against cloudstack 4.2.1
Centos 6.4

Patch is against 4.3 since 4.2+ is effected by the issue.


File Attachments (updated)


Updated Patch which includes a sleep
  
https://reviews.apache.org/media/uploaded/files/2014/09/13/c612e257-c83e-4a8e-8970-44d078838db6__patch.diff


Thanks,

David Bierce

Jenkins build is still unstable: simulator-singlerun #355

[jenkins]

See 

Re: [ACS441][ACS431] Release-notes

[David Nalley]

On Fri, Sep 12, 2014 at 7:01 AM, Sebastien Goasguen  wrote:
>
> On Sep 12, 2014, at 6:52 AM, Daan Hoogland  wrote:
>
>> Sebastien, a generated file is more reliable, isn't it? or else one of my
>> former manageres favorite Stalin quote: "Trust is good, control is better"
>>
>
> yes and I even wrote the script that pulls the bugs form jira:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs-rn.git;a=blob;f=utils/jira.py;h=c4b931de0aade4416f465858a7fea50ab7be01f8;hb=master
>
> But it would be nice if committers would get in the habit of updating the 
> CHANGES files when they fix a bug.
>
> Otherwise why do we have a CHANGES file in the first place ?
>

Every release we say we are going to purge it.

--David

How setting development environment without network connection

[Yitao Jiang]

Hi, stackers
Is there any way that i can setting development environment without network
connnection. I mean i had been once set up everything ok in development
with network. Every time i launch cloudstack using command mvn jetty run it
will update some dependence pom , it  failed without network connection. Is
it configurable that do not update m2 repos locally since they are already
esists