Hi all, Please find my comments inline,
Sent from my mobile. On Oct 9, 2013 6:50 AM, "Sanjiva Weerawarana" <[email protected]> wrote: > > Hi Dale, > > On Tue, Oct 8, 2013 at 9:37 PM, Chalfant, Dale (DTI) < [email protected]> wrote: >> >> Team: >> >> >> >> Some things to consider for long-term roadmap: >> >> >> >> System documentation (such as system diagrams / deployment diagrams) go into repository (ideally an ITIL configuration management database/CMDB). This information is used along with rules to form build scripts. Certain instances are hibernated for quick startup (higher cost than building from scratch, but lower cost than active). > > > This is an interesting next step definitely. We currently have a CMDB too - that the manager writes to - but its fairly rudimentary yet. Right now we are dealing with atomic service deployment only I believe. The next step is to have a composite model that takes an entire system and deploys it as a whole. Lakmal can you clarify what we can do in that regard right now - in terms of inter-cartridge dependencies etc.. > > My suggestion is to do this improvement (support for composite apps - that's where even specs like CAMP come in) next. We had some some for CAR (WSO2's composite application archive) format but I'm not sure what status its in. > >> Metering is performed on the boxes and we balance resources based on acceleration rather than some threshold. If a box is running 95% CPU and has been doing so for a while, that is a good thing, not an indicator of needing another box per se, but if the box is at 5% then quickly is climbing (high acceleration), we would want to fire up a hibernated box and get another in the pipeline. > > > Yes +1. This is easily implementable in the proposed new architecture - basically a CEP query which says if the rate of change of system load stays at 5% over a few minute interval then fire up another one type query. Great point that rate of change is more important than the actual current load. Nice thinking indeed. Currently we use requests in-flight as an indicator to scale up, scale down. I think we can apply same logic for this aspect as well, which means using rate of changing average requests in-flight in addition to current number of requests in-flight. I would like to volunteer for auto scaling(with rules engine) implementation. We can use Lb statistics(requests in-flight) as well as instance load details like CPU, memory... Thanks. > > Sanjiva. > -- > Sanjiva Weerawarana, Ph.D. > Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ > email: [email protected]; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 650 265 8311 > blog: http://sanjiva.weerawarana.org/ > > Lean . Enterprise . Middleware
