On Thu, Dec 9, 2010 at 3:52 PM, Michael Jeanson < mjean...@revolutionlinux.com> wrote:
> Hi all, > > I updated the Ubuntu Lucid packages on launchpad to version 0.4, > they are currently untested and I would appreciate any feedback. > > You can add those packages to your Ubuntu Lucid system by running > the following commands : > > sudo add-apt-repository ppa:shinken-dev/ppa > sudo apt-get update > sudo apt-get install shinken > > For the more adventurous, you can try the daily builds in the > Shinken Daily Builds PPA : > > sudo add-apt-repository ppa:shinken-dev/daily > > I'm also in the process of adding daily builds for maverick and > natty. > Hi, Thanks a lot Michael :) I'm looking at use it as a part of our automatic tests :) Jean > > --- > Michael Jeanson - Revolution Linux > http://www.revolutionlinux.com > > ----- Original Message ----- > > Hi all, > > > > I just uploaded the demo vm fixed by Gerhard on the main site. The > > news is released too ( > > > http://www.shinken-monitoring.org/news/decadent-dragonfly-0-4-is-released-go-prod/ > > if you see problem in my English, ask for a wordpress account, and I > > grand you right to edit the website :) ). > > > > I think you already know what is in this version, if not, look at the > > post :) > > > > Now it's time to focus on the next version(s). There will be steps > > before the 0.5. first, we should look at the properties enhancement. > > Of course, it will ask one people work (I take this ticket) and so > > others can still work on other parts of the code. > > > > The main features for theses versions are : > > > > *Escalation based on time : it will ask new parameters for the > > escalations objects, and the user will have the choice between a > > number of notif escalation, or a time based one (not both). > > > > *criticity : in fact when I talk about result_modulation about > > CRITICAL->WARNING for qualification env, it was a first step to the > > "criticity" dimension. It take some time to make the turn of my head, > > but now it's clear : we need another "dimension" than just > > OK/WARNING/CRITICAL. It's not enough. We do not need to add another > > 0,1,2 states. The "service" can eb critical, but it's "criticity" is > > not so important (qualification env, or slow prod one). When a Warning > > on a TOP criticity env will be to solve in priority (look at the boss > > behind you, he will say to you what solve first ;) ). > > With it, UIs will have a way to make theses high criticity elements > > make the front page. Think at priority inbox from Google : same thing. > > > > *cluster/business correlation : big words for a "small" things after > > all : a service can be an aggregation of several others with and/or > > rules. Like : > > Main_ERP = (database1 | database2) & (app1 | app2) & (loadbalancer1 | > > loadbalancer2) & NFS > > each "sub service" can be a "aggregated" one or a standard one. In > > fact, the only difference between both are just the way of checking > > the state: > > ** if the service got such a rule, it's "checked" internally by > > looking at others state and apply the rule (still regexp....Gerhard, > > I'll need you regexp skills on this :p ) > > ** if not, it's a standard service > > >From a UI point of view, there won't be any difference, it's still a > > >standard service, with the same properties, problem/impact management > > >(database1 will impact Main_ERP for example) and criticity of course. > > >It's a "business addon", but in the core, with just a new property > > >for service. And in the core, we can have all others enhancement. > > > > *downtimes for contacts : admins always take all the inbox mail and > > clic "step as read" when they came back from holidays. We can offer > > them a way to say "hey! I'm on holidays from X to Y, don't send me > > emails thanks." (the rest of the sentence can be "or only for truly > > critical env", but it will be for another version :) ). > > > > We can add all of this in the core. But we will need the help of the > > UIs dev of course like for Thruk or NagVis. So we will have to help > > them and give some code for their projects. And when we see how cool > > theirs tools are, and how useless we are without them, we really > > should give us some time to propose them new features based on all > > theses new features. > > > > For each big feature, we can increment the version (0.4.1, 0.4.2, > > etc). So it will be easier for testers to know which version they got > > :) > > > > Let get back to code guys (and girls), the next version will be a > > great one :) > > > > > > Jean > > > > > ------------------------------------------------------------------------------ > > This SF Dev2Dev email is sponsored by: > > > > WikiLeaks The End of the Free Internet > > http://p.sf.net/sfu/therealnews-com > > _______________________________________________ > > Shinken-devel mailing list > > Shinken-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/shinken-devel > > > ------------------------------------------------------------------------------ > This SF Dev2Dev email is sponsored by: > > WikiLeaks The End of the Free Internet > http://p.sf.net/sfu/therealnews-com > _______________________________________________ > Shinken-devel mailing list > Shinken-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shinken-devel >
------------------------------------------------------------------------------
_______________________________________________ Shinken-devel mailing list Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
