On Tue, Feb 26, 2013 at 12:43 PM, Rohit Yadav <bhais...@apache.org> wrote: > On Tue, Feb 26, 2013 at 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? > > Updates on few of them: > >> >> CLOUDSTACK-1228Unable to Create System Vm's in the VMware Hypervisor >> setup.Venkata Siva Vijayendra Bhamidipati > > Can be due to incorrect packaging, an issue was fixed in > CLOUDSTACK-1244, this needs to be re-tested. > >> CLOUDSTACK-1244fail to push sysmvm.iso onto xen hostAbhinandan Prateek > > Fixed and tested, works. > >> >> CLOUDSTACK-1252Failed to download default template in VMwareAlex Huang >> >> CLOUDSTACK-1264System VM does not have default route.Jayapal Reddy > > Both above ones may have been affected due to CLOUDSTACK-1244. We need > to re-test and see if they are still valid. > >> >> CLOUDSTACK-1276Remove autoscanning for 4.1Kelven Yang
Oh, forgot to mention. There was virtually no difference memory-wise using xml or autoscanning+annotation approach. Regards. > > This is frivolous, the fix is simple and we've a way to quickly fix > it. But from my memory hunt and peck tests; (there was only one agent > being behind mgmt server issue [1]) > Usage of master: > 852 MB > > Usage of 4.1 with Kelven's fix: > 417 MB during load time (peak) > 377 MB (runtime, after deploying a basic zone on devcloud) > > We want Kelven's fix from CLOUDSTACK-1339 on master. > > [1] > https://issues.apache.org/jira/browse/CLOUDSTACK-1339?focusedCommentId=13586870&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13586870 > > Regards. > >> >> 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 >>>
