Re: Error when taking host out of maintenance

[Travis Graham]

Are you using the new systemvm image?

On Oct 1, 2013, at 1:37 PM, Maurice Lawler  wrote:

> Since upgrading, and restarting system VM's, nothing is coming back online. 
> System VM's are still in starting state, nothing in the way of error messages 
> in the logs. Did you or anyone else encounter this and if so, how was it 
> resolved.
> 
> 
> On 10/1/13, 1:19 PM, Marcus Sorensen wrote:
>> I've gotten errors canceling maintenance too, but it still worked (host was
>> enabled afterward) so I haven't dug into it yet.
>> On Oct 1, 2013 10:57 AM, "Maurice Lawler"  wrote:
>> 
>>> Anyone able to dycpher what htis is trying to tell me ?
>>> 
>>> - Maurice
>>> 
>>> 013-10-01 12:54:41,347 DEBUG [cloud.deploy.**DeploymentPlanningManagerImpl]
>>> (Job-Executor-10:job-188 = [ 9552b42a-eac5-4744-8323-**d71eb78bc0fb ])
>>> MessageBus message: host reserved capacity released for VM: 1, checking if
>>> host reservation can be released for host:1
>>> 2013-10-01 12:54:41,354 DEBUG [cloud.resource.**ResourceManagerImpl]
>>> (Job-Executor-10:job-188 = [ 9552b42a-eac5-4744-8323-**d71eb78bc0fb ])
>>> Sent resource event EVENT_CANCEL_MAINTENANCE_AFTER to listener
>>> CapacityManagerImpl_**EnhancerByCloudStack_55a560e8
>>> 2013-10-01 12:54:41,354 ERROR [cloud.async.**AsyncJobManagerImpl]
>>> (Job-Executor-10:job-188 = [ 9552b42a-eac5-4744-8323-**d71eb78bc0fb ])
>>> Unexpected exception while executing org.apache.cloudstack.api.**
>>> command.admin.host.**CancelMaintenanceCmd
>>> com.cloud.utils.exception.**CloudRuntimeException: Internal error
>>> cancelling maintenance.
>>> at com.cloud.resource.**ResourceManagerImpl.**cancelMaintenance(**
>>> ResourceManagerImpl.java:1156)
>>> at org.apache.cloudstack.api.**command.admin.host.**
>>> CancelMaintenanceCmd.execute(**CancelMaintenanceCmd.java:101)
>>> at com.cloud.api.ApiDispatcher.**dispatch(ApiDispatcher.java:**158)
>>> at com.cloud.async.**AsyncJobManagerImpl$1.run(**
>>> AsyncJobManagerImpl.java:531)
>>> at java.util.concurrent.**Executors$RunnableAdapter.**
>>> call(Executors.java:471)
>>> at java.util.concurrent.**FutureTask$Sync.innerRun(**
>>> FutureTask.java:334)
>>> at java.util.concurrent.**FutureTask.run(FutureTask.**java:166)
>>> at java.util.concurrent.**ThreadPoolExecutor.runWorker(**
>>> ThreadPoolExecutor.java:1146)
>>> at java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
>>> ThreadPoolExecutor.java:615)
>>> at java.lang.Thread.run(Thread.**java:679)
>>> 2013-10-01 12:54:41,356 DEBUG [cloud.async.**AsyncJobManagerImpl]
>>> (Job-Executor-10:job-188 = [ 9552b42a-eac5-4744-8323-**d71eb78bc0fb ])
>>> Complete async job-188 = [ 9552b42a-eac5-4744-8323-**d71eb78bc0fb ],
>>> jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Internal
>>> error cancelling maintenance.
>>> 2013-10-01 12:54:42,380 DEBUG [cloud.api.ApiServlet]
>>> (catalina-exec-21:null) ===START===
>>> -- GET command=queryAsyncJobResult&**jobId=9552b42a-eac5-4744-8323-**
>>> d71eb78bc0fb&response=json&**sessionkey=e3ePddUCCz2xG%**
>>> 2FTvAbZ8jspIpvw%3D&_=**1380646468186
>>> 
> 

Re: System VM

[Travis Graham]

Here are the correct links for 4.2.0:

Xenserver : 
http://download.cloud.com/templates/4.2/systemvmtemplate-2013-07-12-master-xen.vhd.bz2
  
KVM  :
http://download.cloud.com/templates/4.2/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
  
VMware   : http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova 

Travis

On Oct 2, 2013, at 7:00 PM, Maurice Lawler  wrote:

> Hello,
> 
> Going through the install, I noticed the system VM template hasnt changed 
> URL. Is it safe to assume to utilize this one:
> 
> # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt 
> -m /mnt/secondary -u 
> http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 
> -h kvm -s  -F
> 
> 
> Or should I be utilizing another?
> 
> - Maurice

Re: System VM

[Travis Graham]

Hey Marcus,

The docs were split out today to make them easier to work on. I'll be going
through them later tonight to fix things like this and sending out a diff
to get them corrected as soon as possible.

Travis

On Wednesday, October 2, 2013, Marcus Sorensen wrote:

> For 4.2 that doesn't work. If the docs say that, we need to fix it.
>
> On Wed, Oct 2, 2013 at 5:00 PM, Maurice Lawler 
> >
> wrote:
> > Hello,
> >
> > Going through the install, I noticed the system VM template hasnt changed
> > URL. Is it safe to assume to utilize this one:
> >
> > #
> /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt
> > -m /mnt/secondary -u
> >
> http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
> > -h kvm -s  -F
> >
> >
> > Or should I be utilizing another?
> >
> > - Maurice
>

[DOCS] CS-docs patch

[Travis Graham]

Here is a patch for the "Deployment Architecture Overview" section until things 
get setup in Review Board for the new repo or there's a GitHub mirror that pull 
requests can be sent to for review. Will the github mirror and PR route be 
supported in tandem with the Review Board process or not at all?

It adds in links to other docs it only loosely referenced by name and adds the 
Primary Storage info about being zone wide for 4.2.

Travis

Re: [DOCS] CS-docs patch

[Travis Graham]

Hello Prasanna,

After sending this out yesterday I realized it would probably get stripped so 
Chip recommended opening issues in Jira and attaching the patches there.

I've created two issues and attached patches as well as attaching a patch to 
another issue that came in about the docs:

* CLOUDSTACK-4799
* CLOUDSTACK-4800
* CLOUDSTACK-4797

Until there's an easier way to get the patches out I'll stick to Jira and send 
out an email to dev@ about the patch so anyone can review and apply the changes.

Thanks,
Travis

On Oct 4, 2013, at 12:37 AM, Prasanna Santhanam  wrote:

> On Thu, Oct 03, 2013 at 02:10:26PM -0400, Travis Graham wrote:
>> Here is a patch for the "Deployment Architecture Overview" section
>> until things get setup in Review Board for the new repo or there's a
>> GitHub mirror that pull requests can be sent to for review. Will the
>> github mirror and PR route be supported in tandem with the Review
>> Board process or not at all?
>> 
>> It adds in links to other docs it only loosely referenced by name
>> and adds the Primary Storage info about being zone wide for 4.2.
>> 
>> Travis
> Attachments are stripped
> 
> Please paste the contents of your patch in plaintext with the subject
> [PATCH]. Also ensure you've created your patch using git format-patch
> so I can apply it readily and attribute credit to you.
> 
> I'd love to have PRs via github but that's upto asf infra and not
> project specific to answer.
> 
> 
> Thanks,
> 
> 
>> 
> 
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

Re: Hypervisor Questions

[Travis Graham]

Was that a limitation caused by the primary storage only being available to a 
single cluster and not zone wide like 4.2.0 provides?

Travis

On Oct 4, 2013, at 1:52 PM, Mike Tutkowski  wrote:

> Maybe this is a silly question, but if CS handles Live Migrations, are we
> still constrained to migrating VMs from one host to another in the same
> cluster?
> 
> Same question for HA.
> 
> 
> On Wed, Oct 2, 2013 at 8:42 AM, Clayton Weise  wrote:
> 
>> AFAIK, no, but it's a great RFE that I would vote for.
>> 
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: Tuesday, October 01, 2013 9:26 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: Hypervisor Questions
>> 
>> Oh, and, yes, when I referred to HA, it was (as you said) with the meaning
>> of a host going offline and VMs being restarted on other hosts (perhaps in
>> a prioritized order if there are an insufficient number of resources to
>> support all of the VMs that were running on the downed host).
>> 
>> Does CS support assigning a priority to a VM in case not all VMs can be
>> restarted on the remaining resources?
>> 
>> 
>> On Tue, Oct 1, 2013 at 6:35 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com
>>> wrote:
>> 
>>> Thanks, Clayton!
>>> 
>>> Yeah, copy/paste mistake there. :) I meant it as you said.
>>> 
>>> 
>>> On Tue, Oct 1, 2013 at 4:54 PM, Clayton Weise 
>> wrote:
>>> 
 First, I think you meant to put XenServer, KVM, and VMware and not
 XenServer 3 times in a row.  That being said I think in all cases
 (somebody correct me if I'm wrong here) it goes something like this:
 
 Live Migration: Request is made by CS but carried out by the HV.
 High Availability: More accurately it's "recovery after host failure"
 because it's still a disruptive action when a host goes sideways, but
 by default this is handled by CS.  I _think_ there's an option to let
 the HV handle this but I'm not totally sure.
 DRS: Managed by CS through one of several methods with the global
 setting vm.allocation.algorithm (see below)
 
 'random', 'firstfit', 'userdispersing', 'userconcentratedpod_random',
 'userconcentratedpod_firstfit' : Order in which hosts within a
 cluster will be considered for VM/volume allocation.
 
 That being said, after deployment there isn't any further DRS
 monitoring; it's only done at the time an instance is instantiated.
 
 -Clayton
 
 -Original Message-
 From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
 Sent: Tuesday, October 01, 2013 3:00 PM
 To: dev@cloudstack.apache.org
 Subject: Hypervisor Questions
 
 Hi,
 
 I was wondering if people could clarify for me what CloudStack
 manages versus what the hypervisor manages in terms of live
 migration, high availability, and distributed resource scheduling?
 
 I know it is probably different for XenServer, VMware, and KVM.
 
 Can people fill in the info below (managed by the management server,
 the hypervisor, or some combination of both)?
 
 XenServer
   Live migration:
   High availability:
   Distributed Resource Scheduling:
 
 XenServer
   Live migration:
   High availability:
   Distributed Resource Scheduling:
 
 XenServer
   Live migration:
   High availability:
   Distributed Resource Scheduling:
 
 Thanks!
 
 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the
 cloud
 *(tm)*
 
>>> 
>>> 
>>> 
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkow...@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the
>>> cloud
>>> *(tm)*
>>> 
>> 
>> 
>> 
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud
>> *(tm)*
>> 
> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Re: System VM

[Travis Graham]

From the perspective of a new community member being able to contribute to a 
separate repo that doesn't touch the app code is nice because that would open 
up the possibility of being a committer for the doc repo and separate that silo 
of work. Also less volatile in the fact that people, like me, who don't want to 
or can't mess with the actual Java side of the house and potentially having to 
deal with funky rebase issues and keeping up to date in the fast moving target 
state that the main code stays in.

There's talk of splitting the Release Manager out into separate roles with one 
head RM and sub RM's within their area of responsibility. I think this would 
help on that front as well. Having a lead Docs person (I think that's David?) 
who can oversee the whole process but can delegate things out to community 
members who are willing to take on the work.

That's my initial thoughts, I'm sure I could think of more advantages later 
once I work through more of the docs process. It's been interesting so far.

Travis

On Oct 4, 2013, at 1:55 PM, Chip Childers  wrote:

> On Fri, Oct 04, 2013 at 05:43:16PM +, Jessica Tomechak wrote:
>> Hi guys,
>> Not arguing against it, but I would be very much interested in your 
>> reasoning behind why having docs in a separate repo makes them easier to 
>> work on. What have we experienced since this time last year which has led us 
>> to reverse the original decision to keep docs in the same repo with code?
>> 
>> And having mentioned this, also thanks to y'all for taking care of doing the 
>> actual split and setting up the new repo.
>> 
>> Jessica T.
> 
> Documentation has a different lifecycle from the code, since docs aren't
> usually complete anywhere near feature complete.
> 
> Also, having it in a different repo will help contributors more easily
> work with the documentation.  We are seeing a number of new folks in the
> community that want to help on that front.  
> 
> -chip

Re: Document Issues

[Travis Graham]

Here is the relevant section from the 4.2.0 docs:

* 
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Admin_Guide/add-password-management-to-templates.html

Travis

On Oct 5, 2013, at 11:52 AM, Maurice Lawler  wrote:

> Hello,
> 
> I am attempting to recall how to setup a template to enable password resets. 
> However, upon searching for 'password' in the documents I get the error as 
> shown in the attached screen shots.
> 
> 
> - Maurice

Re: DOC ACS 4.2 - Need of CSP with xenserver 6.2 for EIP

[Travis Graham]

CSP was included in XS 6.1 forward so there's no need to install it.

Travis

On Oct 7, 2013, at 11:58 AM, benoit lair  wrote:

> Hi,
> 
> I'm reading the docs of ACS 4.2, and about Xenserver CSP (ch 8.2.7 :
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/citrix-xenserver-installation.html
> )
> 
> Do we still need a CSP fo xenserver 6.2 (per example for EIP and ELB) with
> acs 4.2 ?
> 
> If yes, what is the link providing the good CSP ?
> 
> Thanks a lot.
> 
> Regards, Benoit.

Re: [DISCUSS] Components in JIRA and bug assignment

[Travis Graham]

I don't think we need to add another tool for this. I'm sure Jira is fully 
capable of doing what's needed, it's just finding the right configuration and 
the person who knows how to get things setup to work.

Travis

On Oct 8, 2013, at 9:15 AM, Frankie Onuonga  wrote:

> +1 I think we need another tool to do this .
> Maybe set up trac or RT.
> 
> 
> Sent from my Windows Phone
> 
> From: Alena Prokharchyk
> Sent: ‎10/‎4/‎2013 10:12 PM
> To: dev@cloudstack.apache.org; Musayev, 
> Ilya
> Subject: Re: [DISCUSS] Components in JIRA and bug assignment
> 
> On 10/4/13 10:37 AM, "Musayev, Ilya"  wrote:
> 
>>> On Fri, Oct 04, 2013 at 05:11:32PM +, Musayev, Ilya wrote:
 Question to JIRA experienced admins, we can preserve "assign to me"
>>> option, and if unassigned goto "component" maintainer?
>>> 
>>> Absolutely.  Initial assignment does not equal the actual assignee.
>>> Component-based assignment is just a way to skip the unassigned phase,
>>> but people can reassign to themselves or others.
>>> 
>>> -chip
>> 
>> Chip, thanks for the answer.
>> 
>> So far, I've yet to see someone speaking negatively on this proposal. We
>> do need  better structure - that will also help us being productive.
>> 
>> Please kindly respond with +1, 0 or -1
>> 
>> If -1, please explain why.
>> 
>> Thanks
>> ilya
>> 
>> 
> 
> 
> +1
> 
> -Alena.
> 

Re: Typo in KVM docs

[Travis Graham]

Yep, that's a typo. Should be 16059 like libvirtd.conf has by default.

If you'll open a Jira for it I'll submit a patch the docs.

Travis

On Oct 8, 2013, at 2:44 PM, Mike Tutkowski  wrote:

> Hi,
> 
> I see the KVM install guide says:
> 
> tcp_port = "16059"
> 
> 
> I'm wondering if this is correct or if it should be 16509, which is what is
> in /etc/libvirt/libvirtd.conf by default.
> 
> Thanks,
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Re: Typo in KVM docs

[Travis Graham]

That's what I get for not fact checking. Dagnabbit.

On Tuesday, October 8, 2013, Francois Gaudreault wrote:

> Ok great, I wasn't sure since Travis kinda made the same typo like the
> docs ;P
>
> Thanks!
>
> Francois
>
> On 10/8/2013, 4:27 PM, Mike Tutkowski wrote:
>
>> We decided it is 16509 (which is what is the default and was - at one
>> point - written incorrectly in the documentation as 16059).
>>
>>
>> On Tue, Oct 8, 2013 at 2:19 PM, Francois Gaudreault <
>> fgaudrea...@cloudops.com <mailto:fgaudrea...@cloudops.com>> wrote:
>>
>> Ok now I am mixed up :P
>>
>> libvirtd.conf has 16509 by default. (at least on CentOS)
>>
>> So is it 16509 or 16059? :P
>>
>> Francois
>>
>>
>> On 10/8/2013, 2:58 PM, Mike Tutkowski wrote:
>>
>> I was actually looking at what's on the web for 4.2 (even
>> though I'm
>> developing on master).
>>
>> When I went to find this isssue in 4.3, it appears the problem
>> has been
>> corrected.
>>
>>
>> On Tue, Oct 8, 2013 at 12:56 PM, Chip Childers
>> > <mailto:chip.child...@sungard.com>>wrote:
>>
>> Careful which branch you are working on Mike.  I think
>> that David's plan is
>> that we are baselines on 4.2 in the new docs repo, and he
>> was going to then
>> pull from 4.2 into master (again, in the new repo).
>>
>>
>> On Tue, Oct 8, 2013 at 2:54 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com
>> <mailto:mike.tutkow...@solidfire.com>
>>
>> wrote:
>> I have some other KVM docs that I've been updating as
>> I do my development
>> work, so I should be able to modify this, as well.
>>
>> Thanks!
>>
>>
>> On Tue, Oct 8, 2013 at 12:51 PM, Travis Graham
>> mailto:tgra...@tgraham.us>>
>>
>> wrote:
>>
>> Yep, that's a typo. Should be 16059 like
>> libvirtd.conf has by default.
>>
>> If you'll open a Jira for it I'll submit a patch
>> the docs.
>>
>> Travis
>>
>> On Oct 8, 2013, at 2:44 PM, Mike Tutkowski <
>>
>> mike.tutkow...@solidfire.com
>> <mailto:mike.tutkow...@solidfire.com>
>>
>> wrote:
>>
>> Hi,
>>
>> I see the KVM install guide says:
>>
>> tcp_port = "16059"
>>
>>
>> I'm wondering if this is correct or if it
>> should be 16509, which is
>>
>> what
>>
>> is
>>
>> in /etc/libvirt/libvirtd.conf by default.
>>
>> Thanks,
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> <mailto:mike.tutkow...@solidfire.com>
>> o: 303.746.7302 
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/**
>> solution/overview/?video=play<http://solidfire.com/solution/overview/?video=play>
>> >
>> *™*
>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> <mailto:mike.tutkow...@solidfire.com>
>> o: 303.746.7302 
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/**
>> solution/overview/?video=play<http://solidfire.com/solution/overview/?video=play>
>> >
>> *™*
>>
>>
>>
>>
>>
>> -- Francois Gaudreault
>> Architecte de Solution Cloud | Cloud Solutions Architect
>> fgaudrea...@cloudops.com <mailto:fgaudrea...@cloudops.com>
>> 514-629-6775 
>> - - -
>> CloudOps
>> 420 rue Guy
>> Montréal QC  H3J 1S6
>> www.cloudops.com <http://www.cloudops.com>
>> @CloudOps_
>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com <mailto:mike.tutkow...@solidfire.com>
>> o: 303.746.7302
>> Advancing the way the world uses the cloud <http://solidfire.com/**
>> solution/overview/?video=play<http://solidfire.com/solution/overview/?video=play>
>> >**/™/
>>
>
>
> --
> Francois Gaudreault
> Architecte de Solution Cloud | Cloud Solutions Architect
> fgaudrea...@cloudops.com
> 514-629-6775
> - - -
> CloudOps
> 420 rue Guy
> Montréal QC  H3J 1S6
> www.cloudops.com
> @CloudOps_
>
>

Re: Review Request 14381: KVM: add connect/disconnect capabilities to StorageAdaptors so that external storage services can attach/detach devices on-demand

[Travis Graham]

Might be this one:

* 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSVM,+templates,+Secondary+storage+troubleshooting

Travis

On Oct 8, 2013, at 11:04 PM, Mike Tutkowski  
wrote:

> CS MS can ping the SSVM's public IP address.
> 
> SSVM can ping CS MS.
> 
> I think we had a nice debug document for SSVM mentioned on a CS
> e-mail...I'll try to find it.
> 
> 
> On Tue, Oct 8, 2013 at 8:29 PM, Marcus Sorensen  wrote:
> 
>> You could start by trying to ping them from mgmt server, or trying to VNC
>> to them if the OS isn't up. I'm assuming you prepped a current system vm
>> template (maybe you're even reusing a secondary storage). If you can ping
>> their 169.254 addresses, you can "cloudstack-ssh 169.254.x.x" as root on
>> the kvm host to get in
>> On Oct 8, 2013 7:31 PM, "Mike Tutkowski" 
>> wrote:
>> 
>>> Looks like I'll have to dig up that doc on debugging SSVM...it's been
>>> about 30 mins since the VMs came up.
>>> 
>>> 
>>> On Tue, Oct 8, 2013 at 7:29 PM, Marcus Sorensen wrote:
>>> 
 You may just have to wait a bit. That means the VMS are started but the
 services aren't up. Usually takes 5-10 min to get both up in my fusion vm.
 If that doesn't get better you may have to log into the system VMS and see
 what's going on.
 On Oct 8, 2013 7:25 PM, "Mike Tutkowski" 
 wrote:
 
> Doh! I didn't restart the necessary service after exporting my NFS
> share.
> 
> The system VMs come up now; however, SSVM has a dash (-) for its Agent
> State and the CS MS console keeps printing out the following:
> 
> INFO  [o.a.c.s.e.DefaultEndPointSelector]
> (StatsCollector-3:ctx-018adc41) No running ssvm is found, so command will
> be sent to LocalHostEndPoint
> 
> 
> On Tue, Oct 8, 2013 at 4:35 PM, Marcus Sorensen 
> wrote:
> 
>> Can you mount the secondary storage from your KVM host?
>> On Oct 8, 2013 4:01 PM, "Mike Tutkowski" 
>> wrote:
>> 
>>> Although the host is added to KVM, I do see the following issues in
>>> the CS MS console (any thoughts on this?):
>>> 
>>> WARN  [c.c.u.d.Merovingian2] (secstorage-1:ctx-c1c573ee) Was unable
>>> to find lock for the key template_spool_ref2 and thread id 2049868806
>>> INFO  [c.c.v.VirtualMachineManagerImpl] (secstorage-1:ctx-c1c573ee)
>>> Unable to contact resource.
>>> com.cloud.exception.StorageUnavailableException: Resource
>>> [StoragePool:1] is unreachable: Unable to create
>>> Vol[1|vm=1|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
>>> org.libvirt.LibvirtException: internal error Child process (/bin/mount
>>> 192.168.233.10:/mnt/secondary/template/tmpl/1/3
>>> /mnt/334b3c4e-764b-362a-be2c-ebe8c490d0a9) status unexpected: exit 
>>> status 32
>>> at
>>> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1027)
>>> at
>>> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069)
>>> at
>>> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830)
>>> at
>>> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:649)
>>> at
>>> com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261)
>>> at
>>> com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:693)
>>> at
>>> com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1265)
>>> at
>>> com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123)
>>> at
>>> com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50)
>>> at
>>> com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:101)
>>> at
>>> com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)
>>> at
>>> com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:78)
>>> at
>>> com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:71)
>>> at
>>> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
>>> at
>>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>>> at
>>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>>> at
>>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>>> at
>>> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
>>> at
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>>> at java.util.co

Re: Docs have moved

[Travis Graham]

Have the 4.2 branch changes been merged into master now?

Which branch should we be submitting patches off of?

Travis

On Oct 10, 2013, at 11:10 AM, Ian Duffy  wrote:

>> Actually I think the jobs are broken now. I'm not too clear on the
>> publican changes. Can someone take a look and fix the publican
>> arguments?
> 
> Current looking at this.
> midonet, niciranvp and release notes are back building.
> 
> Should be able to get the quick install guide back up too, I had to
> push a publican config for it.
> 
> The "build-docs-install-master" appears to have syntax errors. Not
> sure how to resolve them.
> 
> On 10 October 2013 13:47, Prasanna Santhanam  wrote:
>> On Thu, Oct 10, 2013 at 05:57:58PM +0530, Prasanna Santhanam wrote:
>>> On Wed, Oct 02, 2013 at 03:15:23PM -0400, David Nalley wrote:
 Per our earlier discussion, now that 4.2 has released, I moved the
 docs for 4.2 to their own repo, and will be doing the same for master
 in the next day or so as I clean things up.
 
 The new repo is:
 
 https://git-wip-us.apache.org/repos/asf/cloudstack-docs.git
 
>>> 
>>> Fixed all the build jobs on jenkins to point to the right repo.
>>> http://jenkins.buildacloud.org/view/master/
>> 
>> Actually I think the jobs are broken now. I'm not too clear on the
>> publican changes. Can someone take a look and fix the publican
>> arguments?
>> 
>>> 
 The master branch is pretty desolate until I catch up, but 4.2 is
 fully populated.
 
 --David
>>> 
>>> --
>>> Prasanna.,
>>> 
>>> 
>>> Powered by BigRock.com
>> 
>> --
>> Prasanna.,
>> 
>> 
>> Powered by BigRock.com
>> 

Re: [ACS43] [DISCUSS] Release management tasks up for grabs

[Travis Graham]

Animesh,

I'm volunteering to help out with the docs. I've put a hold on fixing things 
until there's a Review Board in place for cloudstack-docs to make it easier to 
submit patches.

Travis

On Oct 11, 2013, at 7:01 PM, Animesh Chaturvedi  
wrote:

> Folks 
> 
> As per the thread [1] release management for CloudStack is complex and runs 
> into many tasks and it is hard for one person to do it all.
> 
> While I am taking the overall release management for 4.3 release there are 
> several areas where we need volunteers:
> 
> 
> I have put down my thoughts please review and refine as appropriate. 
> 
> # Review board management#
> 
> - Context: We are lagging severely behind on the reviews of the patches 
> submitted and have around 100 pending reviews
> - Task Duties:
>   * Periodically check on review board [2] for pending reviews
>   * If reviewers are not called out for the patch direct the submitter to our 
> component maintainers page [3] and help identify the appropriate reviewer
>   * Follow up with submitter if they have not responded to review comments in 
> 5 days
>   * Follow up with reviewers if they have not attended to reviews where they 
> are called out
>   * Reminders can be sent out by either replying to review emails or adding 
> comments in review board for the patches
>   * Check if a reviewer is overloaded with many pending reviews and call out 
> in mailing list that another reviewer to help out is needed
>   * Remind the submitter if the BugId, targeted branch is missing
>   * Remind the submitter to close out the review when the patch has been 
> accepted and submitted in the appropriate branch
>   * Close out the review if it submitter for some reason is not able to close 
> it out (Administrator privilege is needed) 
>   * More details are mentioned in Review board guidelines [4]
> - We probably need two volunteers one for code contribution and one for test 
> patches contribution 
> 
> 
> # Documentation management#
> 
> During ACS 4.2 several folks raised questions on insufficient or incorrect 
> documentation, this is an area where we need multiple volunteers to come 
> forward and help fix documentation
> 
> 
> # Jira issues management #
> 
> As per thread [5] as community now we have agreed to assign issues. There are 
> few things that need to be done to keep the number of unassigned issues  to a 
> manageable number:
> 
> 1. Refine our component list
> 2. Make the primary maintainers the owners of the components in JIRA, so that 
> new issues for the components go to the primary maintainers first instead of 
> being unassigned. 
> 3. Check with INFRA if a workflow can be setup where if an assigned issue is 
> not change to InProgres in a week it goes back to un-assigned or to primary 
> maintainer of the component (whichever the community prefers)
> 
> Workflow:
> 1. The primary maintainers can redistribute the issues to other community 
> members
> 2. If the assignee can fix the issue promptly they should change the status 
> to "In Progress" indicating that issue is being worked on
> 3. If for whatever reason the assignee is not able to fix the issue they 
> should either un-assign or ask someone else to pick up the issue.
> 
> Bug triage:
> The more hands we can get for bug triage the better it would be so if you 
> want to help out please step up.
> 
> 
> 
> # Release announcement preparation #
> 
> When we are ready to release there are several activities that need to be 
> done and we need help.
> * Preparing release statement
> * Preparing press plan
> * Building docs
> * Publishing docs to the site
> 
> 
> 
> I am sure I may have omitted few important activities feel free to add them 
> to the list
> 
> 
> [1] http://markmail.org/thread/gkrq2inc2bkupner
> [2] https://reviews.apache.org/dashboard/
> [3] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintainers+Per+Component
> [4] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guidelines
> 
> [5] http://markmail.org/thread/vtwod332xqwdmll7
> 
> 
> Thanks
> Animesh
> Committer Apache CloudStack
> anim...@apache.org
> 

[DOC] Jira Issues that can be reviewed and closed

[Travis Graham]

Here is a list of Jira issues against the docs that can be reviewed and closed 
if the outcome is acceptable:

CLOUDSTACK-4844 -- Corrected download link for MSI file, removed MSI link from 
Linux section
CLOUDSTACK-4805 -- Added the missing Ubuntu steps
CLOUDSTACK-4782 -- Already corrected in 4.2.0 docs
CLOUDSTACK-4692 -- Fix references to componentContext.xml


Since we're still waiting on the addition of cloudstack-docs to Review Board 
I'm sending out this update as a review request to start closing out some of 
the doc issues in Jira.


Travis

[DOC] Another Jira issue that can be reviewed and closed

[Travis Graham]

Another patch:

CLOUDSTACK-4609 -- Updates Pod and Cluster references in CS hierarchy

Travis

[DOC] Fix typo in doc for apt-get install cloudstack-management command

[Travis Graham]

This fixes the typo referenced in CLOUDSTACK-4161.

Travis

Re: [DOC] Jira Issues that can be reviewed and closed

[Travis Graham]

Hello Prasanna,

I'm fine with marking the issues that are no longer an issue as fixed and 
closing them, but the ones that have patches that haven't been reviewed/applied 
I'm leaving open and making someone with commit access to the docs repo aware a 
patch is out there to be applied.

Until the patch makes its way in I'll leave the tickets open.

I'm going through the open docs issues now and closing out the ones that are no 
longer a problem.

Travis

On Oct 15, 2013, at 1:03 AM, Prasanna Santhanam  wrote:

> On Mon, Oct 14, 2013 at 11:43:33PM -0400, Travis Graham wrote:
>> Here is a list of Jira issues against the docs that can be reviewed and 
>> closed if the outcome is acceptable:
>> 
>> CLOUDSTACK-4844 -- Corrected download link for MSI file, removed MSI link 
>> from Linux section
>> CLOUDSTACK-4805 -- Added the missing Ubuntu steps
>> CLOUDSTACK-4782 -- Already corrected in 4.2.0 docs
>> CLOUDSTACK-4692 -- Fix references to componentContext.xml
> 
> Hi - you should have access to assign these tickets to yourself and
> mark them as fixed. Ideally, the reporter of the ticket will verify
> and close the issue.
> 
>> 
>> 
>> Since we're still waiting on the addition of cloudstack-docs to
>> Review Board I'm sending out this update as a review request to
>> start closing out some of the doc issues in Jira.
>> 
>> 
>> Travis
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 

Review Request 14783: [CLOUDSTACK-4844] Docs show incorrect URL for Windows password reset service download

[Travis Graham]

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

Review request for cloudstack.


Repository: cloudstack-docs


Description
---

(Section 12.13.2) Removes the windows MSI link from the linux section and 
corrects the MSI link in the windows section.


Diffs
-

  en-US/linux-installation.xml 14a2f51 
  en-US/windows-installation.xml bcecc80 

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


Testing
---


Thanks,

Travis Graham

Review Request 14784: [CLOUDSTACK-4805] Installation instructions drops support for Ubuntu

[Travis Graham]

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

Review request for cloudstack.


Repository: cloudstack-docs


Description
---

(section 4.5.7.2) reflect steps for RHEL/CentOS and Ubuntu.


Diffs
-

  en-US/nfs-shares-on-management-server.xml 881ca8d 

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


Testing
---


Thanks,

Travis Graham

Review Request 14785: [CLOUDSTACK-4692] Release notes refer to componentsContext.xml instead of componentContext.xml

[Travis Graham]

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

Review request for cloudstack.


Repository: cloudstack-docs


Description
---

Corrects the two references in Release Notes.


Diffs
-

  release-notes/en-US/Release_Notes.xml a65cca9 

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


Testing
---


Thanks,

Travis Graham

Review Request 14786: [CLOUDSTACK-4609] [doc] Review Comments on Dedicated Resources: POD, CLUSTER

[Travis Graham]

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

Review request for cloudstack.


Repository: cloudstack-docs


Description
---

(sections 2.3 and 2.4) Updated references to organization unit within 
CloudStack for Pods and Clusters


Diffs
-

  en-US/about-clusters.xml d2f0220 
  en-US/about-pods.xml 57ae1a3 

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


Testing
---


Thanks,

Travis Graham

Re: DevCloud Error

[Travis Graham]

Here was the last from the thread you're thinking of, no resolution follow up, 
so I don't know if it fixed things previously:



Hi Min,

1/ I just pulled the latest code from master and used marvin, it went fine.  
Are you still facing this issue? Make sure your local setup is clean and marvin 
installed with latest pull.

2/  It seems you don't have codes.py file available under 
python/site-packages/.../marvin folder? Ideally it will get installed when you 
run your build. If its still an issue, run python setup.py install from 
tools/marvin/ folder and see if it works around.

Thanks!
Santhosh


On Nov 4, 2013, at 3:27 PM, Mike Tutkowski  wrote:

> Hi,
> 
> I feel like I may have missed an e-mail related to this error, but can't
> seem to locate it in my e-mail.
> 
> Anyone know why I get this error when running the following:
> 
> cd documents/cloudstack/src/cloudstack/tools/devcloud ; python
> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> 
> Traceback (most recent call last):
>  File "../marvin/marvin/deployDataCenter.py", line 19, in 
>import configGenerator
>  File
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/configGenerator.py",
> line 22, in 
>from marvin.codes import *
> ImportError: No module named codes
> 
> Thanks!
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Re: Review Request 14786: [CLOUDSTACK-4609] [doc] Review Comments on Dedicated Resources: POD, CLUSTER

[Travis Graham]

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

(Updated Nov. 7, 2013, 1:52 p.m.)


Review request for cloudstack and Joe Brockmeier.


Repository: cloudstack-docs


Description
---

(sections 2.3 and 2.4) Updated references to organization unit within 
CloudStack for Pods and Clusters


Diffs
-

  en-US/about-clusters.xml d2f0220 
  en-US/about-pods.xml 57ae1a3 

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


Testing
---


Thanks,

Travis Graham

Re: Review Request 14785: [CLOUDSTACK-4692] Release notes refer to componentsContext.xml instead of componentContext.xml

[Travis Graham]

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

(Updated Nov. 7, 2013, 1:52 p.m.)


Review request for cloudstack and Joe Brockmeier.


Repository: cloudstack-docs


Description
---

Corrects the two references in Release Notes.


Diffs
-

  release-notes/en-US/Release_Notes.xml a65cca9 

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


Testing
---


Thanks,

Travis Graham

Re: Review Request 14784: [CLOUDSTACK-4805] Installation instructions drops support for Ubuntu

[Travis Graham]

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

(Updated Nov. 7, 2013, 1:53 p.m.)


Review request for cloudstack and Joe Brockmeier.


Repository: cloudstack-docs


Description
---

(section 4.5.7.2) reflect steps for RHEL/CentOS and Ubuntu.


Diffs
-

  en-US/nfs-shares-on-management-server.xml 881ca8d 

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


Testing
---


Thanks,

Travis Graham

Re: Review Request 14783: [CLOUDSTACK-4844] Docs show incorrect URL for Windows password reset service download

[Travis Graham]

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

(Updated Nov. 7, 2013, 1:53 p.m.)


Review request for cloudstack and Joe Brockmeier.


Repository: cloudstack-docs


Description
---

(Section 12.13.2) Removes the windows MSI link from the linux section and 
corrects the MSI link in the windows section.


Diffs
-

  en-US/linux-installation.xml 14a2f51 
  en-US/windows-installation.xml bcecc80 

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


Testing
---


Thanks,

Travis Graham

Re: Review Request 14784: [CLOUDSTACK-4805] Installation instructions drops support for Ubuntu

[Travis Graham]

> On Nov. 7, 2013, 2:38 p.m., Sebastien Goasguen wrote:
> > this does not seem to apply. Can you please pull the latest and see what's 
> > going on 
> > 
> > thanks

Do you want this based against master or 4.2? The patch was originally created 
against 4.2.


- Travis


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


On Nov. 7, 2013, 1:53 p.m., Travis Graham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14784/
> ---
> 
> (Updated Nov. 7, 2013, 1:53 p.m.)
> 
> 
> Review request for cloudstack and Joe Brockmeier.
> 
> 
> Repository: cloudstack-docs
> 
> 
> Description
> ---
> 
> (section 4.5.7.2) reflect steps for RHEL/CentOS and Ubuntu.
> 
> 
> Diffs
> -
> 
>   en-US/nfs-shares-on-management-server.xml 881ca8d 
> 
> Diff: https://reviews.apache.org/r/14784/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Travis Graham
> 
>

[DOCS] 4.2.1 Release Notes rework

[Travis Graham]

I'm kicking off the thread to discuss the work that's needed for the 4.2.1 
Release Notes.

Radhika has asked for help getting the 4.2.1 RN updated and Alok and I have 
volunteered so far to help out. Sebastian has asked to hold off on the release 
until after the Amsterdam meet up which would provide time to get some 
meatspace work done on the 4.2.1 RN during a hackathon.

I'm in favor of the short release delay to get a better final doc product out 
the door that would greatly reduce the confusion and have a nice side effect of 
giving the upgrade process some much needed love by doing the hands on work to 
document every step along the way and solidify what needs to be addressed from 
the current RN format.

I also think the 4.2.0 RN need an overhaul to get them up to speed and make 
them useful. It was a known stick spot before 4.2.0 was released and I think 
4.2.1 is right time to seriously take a look at the upgrade section and do it 
some justice. Too many people trashed their production systems because of some 
unknown gotchas that surfaced and I think that really shook the confidence 
people had in new releases.

Attention to detail in the code quality that's being released is getting some 
much needed love and I think everyone who is willing and able to pay it forward 
to the docs needs to surface. Some pretty big steps have been take to make this 
process much easier have been taken and I think we need to pick it up and run 
with it.


I'm able to setup and test the upgrade process for Ubuntu and CentOS KVM as the 
hypervisors and the same for the Management server and possibly XenServer, but 
I don't have the resources available to test VMware things.

That's my $0.02,
Travis

Re: [ASF4.2.1] Release Notes

[Travis Graham]

I think that's an acceptable middle ground. I would prefer to have the 
artifacts to test the upgrade procedures with and with a designated committer 
to review, commit and release the docs as progress is made we should all be 
able to call this approach a win.

I've yet to get any kind of environment setup to roll my own release and I 
would prefer not to have that overhead just to test the upgrade and make 
improvements to the docs.

Does Jenkins have current {stable} artifacts that can be used to install 4.2.1 
and test with for upgrades?

Travis

On Nov 14, 2013, at 10:53 AM, Simon Weller  wrote:

> I agree completely.
> I've spent the last couple of evenings trying to get a KVM lab upgraded from 
> 4.1 to 4.2.1 by registering the new template first using the name in the 
> upgrade*.java, and I've had zero success getting the SSVM to come back up. 
> However, if I don't install the new template prior to upgrade and replace the 
> existing template, and do some database manipulation (thanks to Kelsey's  
> documented experiences in CLOUDSTACK-4826), I can get the SSVM to come up 
> fine. Maybe I'm missing something here, but without reliable documented steps 
> of what is meant to work, it's hard to test the upgrade process.
> 
> - Si
> 
> 
> From: Chip Childers 
> Sent: Thursday, November 14, 2013 9:40 AM
> To: dev@cloudstack.apache.org
> Cc: Abhinandan Prateek; Alok Kumar Singh
> Subject: Re: [ASF4.2.1] Release Notes
> 
> On Thu, Nov 14, 2013 at 09:42:11AM -0500, Sebastien Goasguen wrote:
>> Anyway we can wait next week to release.
>> 
>> quite a few of us will be together in Amsterdam, we can dedicate a hackathon 
>> session to 4.2.1 , make sure RN are good, upgrade path etc…then test….
>> 
>> I'd recommend keeping the vote open until then.
>> 
>> -sebastien
> 
> +1 to Seb's idea (although I already voted)

Re: [DOCS] feedback

[Travis Graham]

I agree on splitting the docs out into their own repo that pull requests can be 
sent to as bugs in the docs are found or different installations are tested and 
documented.

With the current state of the docs being one of the greatest barriers to entry 
for new CloudStackers, or even when running into problems while trying to 
upgrade, I think it's a problem that can't wait to be solved months from now in 
a 4.3 release.

I've spent weeks breaking and fixing various combinations of CS 4.0.2 -> 4.1.1, 
CentOS and Ubuntu, XenServer and KVM, NFS and local storage, and Basic and 
Advanced networking just to learn how to install and setup a working CS 
environment because  Everyone knows there's a doc shortage, lets fix it.

The fact that the mailing list(s) gets the same questions about SSVM and CPVM 
not spinning up a few times per week and the complexity of setting up the 
different network types should be enough to want to create very detailed 
documentation for different setups with a prominent troubleshooting section.

Using something like GitHub issues would allow people to create issues that can 
be closed out with a PR/commit that updates the docs to address problems as 
opposed to saturating the mailing list with the same questions. And it would 
give others trying to help a place to point people for answers.


Travis

On Sep 4, 2013, at 9:22 AM, Chip Childers  wrote:

> On Wed, Sep 04, 2013 at 12:26:36AM +, Animesh Chaturvedi wrote:
>> [Animesh>] Any change should be done post 4.2
>> 
> 
> Actually, now's the time IMO.  Master is the 4.3 target at this point, so
> shouldn't we make larger changes now?  (moving docs to their own repo and
> re-designing any tooling choices seems like a large change)

Re: cpvm and ssvm but no host entries

[Travis Graham]

That is weird, do you have entries for them in the console_proxy and 
secondary_storage_vm tables?

Have you tried to destroy them and let the Management server recreate them to 
see if that creates the entry in the hosts table?

Travis

On Sep 4, 2013, at 7:38 PM, Darren Shepherd  wrote:

> So I'm trying to setup a cloudstack environment from scratch.  Not a devcloud 
> environment, but more like a production setup.  Anyhow, so I managed to get 
> the cpvm and ssvm running, but there is no host entry for them.  Is that 
> supposed to happen?
> 
> Darren

Re: There is no upgrade path from 4.1.1 to 4.2.0

[Travis Graham]

Is there a problem with applying the sql changes as micro timestamped updates 
and keeping a schema version in the db based on the timestamp?

In Ruby on Rails that's how migrations are created, as timestamped ruby file 
that defines the changes, for example 20130818033029_add_user_roles.rb. When a 
migration is ran all migrations timestamped before the last schema_migration 
entry are skipped and only the unapplied migration files are applied to the db.

There's an up and down method that allows for things to be rolled back if 
something doesn't apply correctly so all changes are reversible, as long as 
there isn't data corruption or one way trapdoor type data changes that happen.

This also allows for partial migrations, you can migrate up to a specified 
migration based on it's timestamp, and the reverse is also true, you can 
rollback to a specific version if needed.

The likelihood of a timestamp collision is so astronomically impossible that it 
isn't a concern. This works well for large code bases being worked on by 
countless developers adding features and doing what devs do.

The version table could track the timestamps and there wouldn't be any fuss 
over patch releases with hot fixes vs point releases or major releases that get 
pushed out causing any problems.

Travis

On Sep 11, 2013, at 6:48 PM, Darren Shepherd  
wrote:

> On 09/11/2013 09:12 AM, Alex Huang wrote:
>> 
>> As for separating db version from release version.  In general I agree with 
>> that.  Again, it's a practical thing.  Currently, cloudstack db changes with 
>> every release so even if you separate them basically they just advance in a 
>> parallel path anyways.  I don't see any time soon where cloudstack db schema 
>> will stabilize to a point where there's just code changes without schema 
>> changes.  When we see that happening, we should break apart the schema from 
>> the release version.
>> 
> 
> I'd have to disagree.  First, in a maintenance release, why are you changing 
> the scheme to begin with?  But, if you do, you can do the following.  Say 4.1 
> was schema 42 and 4.2 in now schema version 50.  If you do a 4.1.1 release 
> that needs a schema change you change the schema in version 51.  And then you 
> install schema 51 on 4.1.
> 
> Schemas should always be backwards compatible in that old code should run on 
> new schema.  I don't think it is the case today as the presence of "clean up" 
> SQL files seems to indicate you are breaking that approach (but I don't 
> really know).
> 
> There's other approaches too.  I really don't think we should do too much to 
> continue to enhance our current approach.  I'd really prefer we just move to 
> flyway.  Regarding hotfixes, here's how flyway can handle it 
> http://flywaydb.org/documentation/faq.html#hot-fixes
> 
> I don't have the time at the moment to help move to flyway, so if somebody 
> else does, great.  Otherwise I'll get to it eventually.
> 
> Darren
> 
> 

Re: Creating an instance with ssh key pair

[Travis Graham]

Will this only pull down one key pair or can it pull down many? We have a need 
to pull in our keys as well as all of our customers keys.

If the script can only pull down one, we can make it work, but would be nice to 
pull down all keys from the project an instance is associated with.

Travis

On Sep 12, 2013, at 11:55 AM, Sangeetha Hariharan 
 wrote:

> To deploy Vm using ssh key pairs  you will need to use a template that has 
> SSH Key Gen Scripts in it.
> Only then you will be able to  ssh into the instance using ssh key.
> 
> -Thanks
> Sangeetha
> 
> 
> -Original Message-
> From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] 
> Sent: Thursday, September 12, 2013 5:00 AM
> To: dev@cloudstack.apache.org
> Subject: Creating an instance with ssh key pair
> 
> Hello all,
> 
> If I create an instance providing ssh key pair while creation, and using a 
> "normal template" from the cloudstack setup, then will the SSH to vm using 
> the keyPairFlieLocation always work?
> 
> Or the template which I am using for creating the instance has to be 
> supporting SSH keys? as explained in 5.2.1 section at 
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/using-sshkeys.html
> 
> In short, Is the SSH using keyPairFileLocation -  template dependent or will 
> it always work if I provide ssh key pair while creating instance and use 
> normal template?
> 
> Regards,
> Gaurav

Re: persistence layer

[Travis Graham]

MariaDB is a drop in replacement for MySQL, so it can be used with or without 
the JOOQ changes.

Travis

On Nov 25, 2013, at 5:20 AM, Sebastien Goasguen  wrote:

> 
> On Nov 23, 2013, at 4:13 PM, Laszlo Hornyak  wrote:
> 
>> Wouldn't it be a lot of work to move to JOOQ? All queries will have to be
>> rewritten.
>> 
>> 
> 
> An a non-java developer question: Will that help support different databases 
> ? like moving to MariaDB ?
> 
>> 
>> On Sat, Nov 23, 2013 at 11:32 AM, Darren Shepherd <
>> darren.s.sheph...@gmail.com> wrote:
>> 
>>> Going to an ORM is not as simple as you would expect.  First, one can make
>>> a strong argument that ORM is not the right solution, but that can be
>>> ignored right now.
>>> 
>>> You have to look at the context of ACS and figure out what technology is
>>> the most practical to adopt.  ACS does not have ORM today.  It has a custom
>>> query api, object mapping, and change tracking for simple CRUD.   Honestly
>>> these features are quite sufficient for ACS needs.  The problem, and why we
>>> should change it, is that the current framework is custom, limited in
>>> functionality, undocumented, and generally a barrier to people developing
>>> on ACS.  So jOOQ is a somewhat similar approach but it is just far far
>>> better, has a community of users that have developed over 3-4 years, is
>>> well documented, and honestly just a very well thought out framework.
>>> 
>>> Darren
>>> 
 On Nov 22, 2013, at 6:50 PM, Alex Ough  wrote:
 
 All,
 
 I'm very interested in converting the current DAO framework to an ORM. I
 didn't have any experience with java related ORMs, but I've done quite
>>> lots
 of works with Django and LINQ. So can you add me if this project is
>>> started?
 
 Thanks
 Alex Ough
 
 
 On Fri, Nov 22, 2013 at 7:06 AM, Daan Hoogland >>> wrote:
 
> Had a quick look, It looks alright. One question/doubt: will we thigh
> ourselves more to mysql if we code sql more directly instead of
> abstracting away from it so we can leave db choice to the operator in
> the future!?!?
> 
> On Thu, Nov 21, 2013 at 7:03 AM, Darren Shepherd
>  wrote:
>> I've done a lot of analysis on the data access layer, but just haven't
> had time to put together a discuss/recommendation.  In the end I'd
>>> propose
> we move to jOOQ.  It's an excellent framework that will be very natural
>>> to
> the style of data access that CloudStack uses and we can slowly migrate
>>> to
> it.  I've hacked up some code and proven that I can get the two
>>> frameworks
> to seamlessly interoperate.  So you can select from a custom DAO and
>>> commit
> with jOOQ or vice versa.  Additionally jOOQ will work with the existing
> pojos we have today.
>> 
>> Check out jOOQ and let me know what you think of it.  I know for most
> people the immediate thought would be to move to JPA, but the way we
> managed "session" is completely incompatible with JPA and will require
> constant merging.  Additionally mixing our custom DAO framework with a
>>> JPA
> solution looks darn near impossible.
>> 
>> Darren
>> 
>>> On Nov 11, 2013, at 8:33 PM, Laszlo Hornyak >>> 
> wrote:
>>> 
>>> Hi,
>>> 
>>> What are the general directions with the persistence system?
>>> What I know about it is:
>>> - It works with JPA (javax.persistence) annotations
>>> - But rather than integrating a general JPA implementation such us
>>> hibernate, eclipselink or OpenJPA it uses its own query generator and
> DAO
>>> classes to generate SQL statements.
>>> 
>>> Questions:
>>> - Are you planing to use JPA? What is the motivation behind the custom
> DAO
>>> system?
>>> - There are some capabilities in the DAO system that are not used.
> Should
>>> these capabilities be maintained or is it ok to remove the support for
>>> unused features in small steps?
>>> 
>>> --
>>> 
>>> EOF
> 
> 
>>> 
>> 
>> 
>> 
>> -- 
>> 
>> EOF
> 

Re: Router requires upgrade. Unable to send command to router Error

[Travis Graham]

Use the links from the Install Guide instead.

http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/management-server-install-flow.html#prepare-system-vm-template

Travis

On Nov 25, 2013, at 3:01 PM, Will Stevens  wrote:

> In trying to troubleshoot I think I have found another issue.  I went looking 
> for a 'more official' source for the system templates.  I found this: 
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Release_Notes/upgrade-instructions.html#upgrade-from-3.0.x-to-4.0
> 
> Which gives a system vm template of (for xen server): 
> http://download.cloud.com/templates/4.2/systemvmtemplate-2013-07-12-master-xen.vhd.bz2
> 
> Unfortunately, those system vm templates do not come up (check the attached 
> files for images).  Basically, the file system comes up as Read Only...
> 
> I will go back to the buildacloud system templates to see if I can get them 
> working...  
> 
> Would love to have someone confirm where we should be getting the System VM 
> Templates from for 4.2+.
> 
> Still trying to get System VM Templates to work on 4.3.  If anyone has this 
> working, please post how you get them working and where you got them from.
> 
> Thanks,
> 
> Will
> 
> 
> On Fri, Nov 22, 2013 at 7:43 AM, Will Stevens  wrote:
> I will try this as a temporary solution.  Thank you...
> 
> Will
> 
> 
> On Fri, Nov 22, 2013 at 6:57 AM, Murali Reddy  wrote:
> 
> Don¹t understand problem well enough for clean fix, but I updated
> 'template_version' from 3.0 to 4.3 of the VR in the domain_router table
> that resolved the issue for me.
> 
> On 22/11/13 3:50 PM, "Will Stevens"  wrote:
> 
> >Has anyone been able to resolve this issue?  This is holding up my ability
> >to launch VMs and test the fixes to my plugin.  I need to resolve this
> >issue to move forward...
> >
> >@Syed, are you still stuck on this as well?
> >
> >Cheers,
> >
> >Will
> >
> >
> >On Wed, Nov 20, 2013 at 5:18 PM, Syed Ahmed  wrote:
> >
> >> OK here is how far I got debugging this. I think I am missing a small
> >> thing. I hope you guys can help.
> >>
> >> So my VM template has the correct version.
> >>
> >> root@eng-ns-dev-cs1: /export/secondary/template/tmpl/1/1 # strings
> >> f3fc75d9-0240-4c71-a3bf-fb65652e4763.vhd  | grep Cloudstack
> >>
> >> Cloudstack Release*  4.2.0*Tue Nov 19 23:22:37 UTC 2013
> >>
> >>
> >> But in the database I see the following ( table domain_router )
> >>
> >> *** 4. row ***
> >>  id: 11
> >>  element_id: 4
> >>  public_mac_address: 06:48:a8:00:00:68
> >>   public_ip_address: 172.30.91.102
> >>  public_netmask: 255.255.255.0
> >>   guest_netmask: NULL
> >>guest_ip_address: NULL
> >> is_redundant_router: 0
> >>priority: 0
> >>  is_priority_bumpup: 0
> >> redundant_state: UNKNOWN
> >>stop_pending: 0
> >>role: VIRTUAL_ROUTER
> >>template_version:*Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST 2012*
> >> scripts_version: 725d5e5901a62c68aed0dd3463023518
> >>  vpc_id: NULL
> >> 4 rows in set (0.00 sec)
> >>
> >>
> >>
> >> I guess this is populated from the VM that gets created. On the xen the
> >>vm
> >> is r-11. I see the following version on that VM
> >>
> >> root@r-11-VM:~# cat /etc/cloudstack-release
> >> Cloudstack Release 3.0 Mon Feb  6 15:10:04 PST 2012
> >>
> >>
> >> This means that Xen is not picking up the template present in the
> >> secondary storage. Does Xen cache the vhd files locally to avoid coming
> >>to
> >> the secondary storage? If so, how can I disable that?
> >>
> >> Also, I was looking at UpgradeRouterTemplateCmd API which basically goes
> >> through all the VRs and reboots them. It expects that when the reboot is
> >> completed, the router should have picked up the 4.2.0 version of the
> >> template ( see line 4072 in VirtualNetworkApplianceManagerImpl.java ) I
> >> try to do the reboot manually but the template remains the same. Do you
> >> guys have any more suggestions?
> >>
> >> Thanks,
> >> -Syed
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed 20 Nov 2013 12:55:04 PM EST, Wei ZHOU wrote:
> >>
> >>>
> >>> FYI.
> >>>
> >>> I upgraded from 2.2.14 to 4.2.1. The CPVM, SSVM and VRs are working
> >>>after
> >>> running *cloudstack-sysvmadm to recreate.*
> >>>
> >>>
> >>> 2013/11/20 Syed Ahmed 
> >>>
> >>>
>  +1 Same error. The secondary storage VM and the Console proxy VM seem
> to
>  be coming up alright. I see this error only when starting the virtual
>  router which is preventing me from creating any instances.
> 
> 
>  On Wed 20 Nov 2013 11:14:47 AM EST, Will Stevens wrote:
> 
> 
> > I am having the same problem. I got the latest system VMs from:
> > http://jenkins.buildacloud.org/view/master/job/build-systemvm-master/
> > lastSuccessfulBuild/artifact/tools/appliance/dist/
> >
> > Are these the wrong System VM Templates? If so, where should I get

Re: 4.2.1 anytime soon?

[Travis Graham]

Have you tried backing out each commit until it builds clean to see what
broke things?

Travis

On Thursday, November 28, 2013, sebgoa wrote:

> moved to dev@
>
> I have been checking on this, and the release notes don't build, there is
> some freaking weird error with publican :(
> Staring at it all morning did not help...
>
> If anyone feels like it, check out the docs repo and try to build the
> release notes on the 4.2 branch….
>
> thanks,
>
> ps: need a break...
>
> -sebastien
>
>
>
> On Nov 28, 2013, at 12:19 PM, Nux! > wrote:
>
> > On 28.11.2013 05:24, Animesh Chaturvedi wrote:
> >> Animesh> Here is the list of issues that are fixed
> >> https://issues.apache.org/jira/issues/?filter=12325707. This being a
> >> maintenance release there are no new features
> >
> > Great, thanks! :)
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
>
>