Following are fixed:
CLOUDSTACK-1244 fail to push sysmvm.iso onto xen host
CLOUDSTACK-1289 [F5-SRX-InlineMode] Usage stats are not generated for
Juniper SRX Firewall in in line mode
For the following it has been verified on Xen and it seems to be working
on VMWare:
CLOUDSTACK-1264 System VM does not have default route.Jayapal Reddy ---
Xen there are no issues, verifying on VMWare.
Need more info like did it fail on KVM ?
-abhi
On 26/02/13 3:37 AM, "Chip Childers" <chip.child...@sungard.com> wrote:
>Yup, having 9 blockers (as of a moment ago) is pretty bad.
>
>Here's the list FWIW... the last one needs someone to grab it and fix
>it. Others with blocker bugs, can you please at least update it with
>current status?
>
>CLOUDSTACK-1228Unable to Create System Vm's in the VMware Hypervisor
>setup.Venkata Siva Vijayendra Bhamidipati
>
>CLOUDSTACK-1244fail to push sysmvm.iso onto xen hostAbhinandan Prateek
>
>CLOUDSTACK-1252Failed to download default template in VMwareAlex Huang
>
>CLOUDSTACK-1264System VM does not have default route.Jayapal Reddy
>
>CLOUDSTACK-1276Remove autoscanning for 4.1Kelven Yang
>
>CLOUDSTACK-1289[F5-SRX-InlineMode] Usage stats are not generated for
>Juniper SRX Firewall in inlinemodeKishan Kavala
>
>CLOUDSTACK-1357Duplicate <jobstatus> inside DeployVM's job response
>virtualmachine object Was: (Autoscale: Provisioned VMs from Netscaler
>not being added to lb vserver, provserver fails with
>provserver_err_asynctaskpoll)Vijay Venkatachalam
>
>CLOUDSTACK-1382vm deploy fails with Error "cannot find
>DeployPlannerSelector for vm"for frank zhang
>
>CLOUDSTACK-1386BASIC zone SSVM fail to start due to exception Unassigned
>
>On Mon, Feb 25, 2013 at 10:36:17AM -0800, Sudha Ponnaganti wrote:
>> Chip,
>>
>> Would like to raise concern that even blockers are not being addressed
>>in time for QA to run automation and move ahead with testing of
>>features. I will post the features ( very minimal numbers ) tested so
>>far. This is a risk unless developers take the defects seriously and fix
>>them and let us move ahead. Blockers are being sitting there for more
>>than 10 days without any resolution.
>>
>> As for next escalation point, I would recommend to remove features
>>where defects are not being addressed. There is no point in putting code
>>in which is not usable and these are blocking other working features
>>which we could not even get to.
>>
>> Thanks
>> /Sudha
>>
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.child...@sungard.com]
>> Sent: Monday, February 25, 2013 8:27 AM
>> To: cloudstack-dev@incubator.apache.org
>> Subject: [ACS41] Schedule reminder!
>>
>> Hi all,
>>
>> Friendly reminder about our schedule. Thursday is the last day of this
>>phase of QA / bug-fix work. We defined it as:
>>
>> 2013-02-28
>> Docs Completion Target (except release notes and translations) (Docs
>> may be included in the release after this date, after consensus on
>> each addition that the inclusion does not reduce release quality).
>>
>> Release Branch moves to limited updates only (only commits allowed
>> in would be release blockers fixes, translation updates, etc...)
>>
>> I'd like to get as many bugs resolved as possible (as well as ensure
>>that the blockers that Sudha has shared this morning are addressed as
>>quickly as possible).
>>
>> After Thursday, we're going to want to move to a very limited amount of
>>change within the 4.1 branch. Given that, now's the time to knock down
>>the blockers... but also as many of the other priority bugs as possible.
>>
>> If you have 4.1 bugs assigned to you, please take a moment today to try
>>to get them resolved (or at least triaged). If you don't have any bugs
>>assigned, then pick some of the unassigned ones! We're trying to not
>>work like a corporate dev team, where managers assign the bugs. That
>>means that personal initiative to pick up work and resolve issues is
>>going to be key to getting our bug count down!
>>
>> Also, if we can get the DEB packaging wrapped up and in the branch by
>>EOD Thursday, that would go a long way to ensuring that we will be
>>working with a stable source tree for the rest of the process. (Wido /
>> Noa: ping!)
>>
>> Thanks all!
>>
>> -chip
>>
