Hi Jeremiah,
Thanks for the feedback. As suggested we can plan a conference call with
concerned members sometime early next week to decide on collaboration items
and way going forward. Could you please suggest a list of participants for
this, if possible. I shall arrange for a conference call and share the
details. It will be nice to meet face to face either at ALS or Genivi AMM.
I shall explore this possibility and update you if it would be possible.
PS: I am away from office till Friday. I may not be able to check the mails
regularly, please expect some delay in response.
Regards
Abhishek
Send IVI mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.tizen.org/listinfo/ivi
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of IVI digest..."
Today's Topics:
1. Re: [genivi-lifecycle] Proposal for new component in Tizen
IVI (Jeremiah Foster)
2. Re: Proposal for new component in Tizen IVI (Abhishek Sharma)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 May 2014 14:41:43 +0200
From: Jeremiah Foster <[email protected]>
To: Abhishek Sharma <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>, "cpgs ."
<[email protected]>, "[email protected]"
<[email protected]>, Purnendu Sinha
<[email protected]>
Subject: Re: [genivi-lifecycle] Proposal for new component in Tizen
IVI
Message-ID:
<cadvdrbgqecteb8xe6dzw-f5bitpmpf3cvixmxrlsrcobnuy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, May 5, 2014 at 12:21 PM, Abhishek Sharma <[email protected]
>wrote:
> Dear all,
>
> Based on feedback received from Tizen IVI community, David Yates and
> Jean-Pierre (see the enclosed email), we looked into GENIVI Node Health
> Monitor (NHM) activities and performed a gap analysis highlighting scopes
> wherein we could contribute and minimize duplication of work in this
> context.
>
Many thanks for your work on this Abhishek. This seems like a very good gap
analysis and provides a roadmap for going forward.
>
> Attached please find the excel sheet which summarizes our initial
> requirement analysis against existing features in NHM.
>
> Any feedback on this would be appreciate. We look forward to collaboration
> on this development.
>
I imagine the next step is to break down the gap analysis into work
packages? Then we can speak amongst ourselves and those who're interested
to see who implements the work packages and how?
What I think is important to note there is some positive collaboration
around this subject matter and I'd like to keep the momentum going so you
can get the functionality you're looking for. I wonder if we can gather the
various people involved on a telephone call or at a meeting? Is it possible
to meet at a conference in the near future, like GENIVI's AMM in Gothenburg
or the Automotive Linux Summit in Tokyo? If we all spoke in person we might
be able to find a collaborative path forward.
The next steps I can see are perhaps NHM bringing in functionality and
features and testing NHM in Tizen IVI. I imagine some of the functionality
you seek might live in systemd as well, not sure how that gets implemented,
someone who works on the systemd list might be able to say if they're
amendable to a patch along the lines you've proposed.
@JP Bogler -- Do you know of anyone testing NHM on Tizen? I can see this:
https://review.tizen.org/git/?p=profile/ivi/node-startup-controller.git;a=summarywhich
makes a bit worried that there may be some patches that need merging.
Regards,
Jeremiah
>
> Regards,
> Abhishek
>
> ------------
> Date: Tue, 22 Apr 2014 11:24:58 +0200
> From: Jean-Pierre Bogler <[email protected]>
> To: [email protected]
> Subject: Re: Re: Proposal for new component in Tizen IVI
> Message-ID:
> <
> cae5myjgcazkiwssta01vmfnosc2ztpgkrffbbdvr1d6det8...@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Dear All,
>
> I developed the "NodeHealthMonitor" (NHM), which is hosted at GENIVI.
> David Yates recently
> informed me about the ongoing discussion. Therefore, I joined the mailing
> list. At all I can see a lot of similiarities between the component
> proposed
> by Abhishek and the NHM we currently have at GENIVI. The NHM sources are
> available at:
>
> http://git.projects.genivi.org/?p=lifecycle/node-health-monitor.git
>
> Here is a short summary on what the NHM does (copied from nhm-main.c):
>
> "The Node Health Monitor will usually be started by systemd and will
> interact with application plug-ins to inform it that a component has
failed
> in the system. He will be responsible for:
>
> - providing an interface with which plug-ins can register failures:
> - name of the failing service, used to identify and track failures
> - tracking failure statistics over multiple LCs for system and
> components
> - NHM will maintain a count of the number of failures in the current
life
> cycle
> as well as statistics on number of failures in last X life cycles
(i.e.
> 3
> failures in last 32 life cycles)
> - observe the life cycle accordingly to catch unexpected system restarts
> - provide an interface for plug-ins to read system/component error
counts
> - provide an interface for plug-ins to request a node restart
>
> Additionally the Node Health Monitor will test a number of product defined
> criteria with the aim to ensure that userland is stable and functional.
> It will be able to validate that:
> - defined file is present
> - defined processes are still running
> - a user defined process can be executed with an expected result
> - communication on defined dbus (bus address) is possible"
>
> In accordance with this, the NHM should be a good basis for the component
> proposed by Abhishek, altough I see the following differences:
>
> 1. NHM only cares about the systemd property "ActiveState".
> Additional tracking of the other properties would need to be
> implemented.
> 2. NHM stores data using GENIVI PCL. A configure switch
> might need to be introduced to use the POSIX API.
> 3. NHM offers "userland checks". They are not harnfuld, since they can
> be deactivated. => This is no issue at all.
>
> In conclusion, I would recommend to collect the Use Cases as suggested by
> Jeremiah and Igor and invite you all to also check the NHM documentation
> and
> code to look for differences and possibilities on how to solve them.
>
> Best rgards
> Jean-Pierre
> ------------------------------
>
> _______________________________________________
> genivi-lifecycle mailing list
> [email protected]
> https://lists.genivi.org/mailman/listinfo/genivi-lifecycle
>
>
--
=============================================
Jeremiah C. Foster
GENIVI Community Manager
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: [email protected]
=============================================
=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.tizen.org/pipermail/ivi/attachments/20140505/82d70690/attachment-0001.html
>
------------------------------
Message: 2
Date: Mon, 05 May 2014 15:51:13 +0530
From: Abhishek Sharma <[email protected]>
To: [email protected]
Cc: [email protected], [email protected],
[email protected], [email protected]
Subject: Re: Proposal for new component in Tizen IVI
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear all,
Based on feedback received from Tizen IVI community, David Yates and
Jean-Pierre (see the enclosed email), we looked into GENIVI Node Health
Monitor (NHM) activities and performed a gap analysis highlighting scopes
wherein we could contribute and minimize duplication of work in this
context.
Attached please find the excel sheet which summarizes our initial
requirement analysis against existing features in NHM.
Any feedback on this would be appreciate. We look forward to collaboration
on this development.
Regards,
Abhishek
------------
Date: Tue, 22 Apr 2014 11:24:58 +0200
From: Jean-Pierre Bogler <[email protected]>
To: [email protected]
Subject: Re: Re: Proposal for new component in Tizen IVI
Message-ID:
<cae5myjgcazkiwssta01vmfnosc2ztpgkrffbbdvr1d6det8...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Dear All,
I developed the "NodeHealthMonitor" (NHM), which is hosted at GENIVI.
David Yates recently
informed me about the ongoing discussion. Therefore, I joined the mailing
list. At all I can see a lot of similiarities between the component proposed
by Abhishek and the NHM we currently have at GENIVI. The NHM sources are
available at:
http://git.projects.genivi.org/?p=lifecycle/node-health-monitor.git
Here is a short summary on what the NHM does (copied from nhm-main.c):
"The Node Health Monitor will usually be started by systemd and will
interact with application plug-ins to inform it that a component has failed
in the system. He will be responsible for:
- providing an interface with which plug-ins can register failures:
- name of the failing service, used to identify and track failures
- tracking failure statistics over multiple LCs for system and
components
- NHM will maintain a count of the number of failures in the current life
cycle
as well as statistics on number of failures in last X life cycles (i.e.
3
failures in last 32 life cycles)
- observe the life cycle accordingly to catch unexpected system restarts
- provide an interface for plug-ins to read system/component error counts
- provide an interface for plug-ins to request a node restart
Additionally the Node Health Monitor will test a number of product defined
criteria with the aim to ensure that userland is stable and functional.
It will be able to validate that:
- defined file is present
- defined processes are still running
- a user defined process can be executed with an expected result
- communication on defined dbus (bus address) is possible"
In accordance with this, the NHM should be a good basis for the component
proposed by Abhishek, altough I see the following differences:
1. NHM only cares about the systemd property "ActiveState".
Additional tracking of the other properties would need to be
implemented.
2. NHM stores data using GENIVI PCL. A configure switch
might need to be introduced to use the POSIX API.
3. NHM offers "userland checks". They are not harnfuld, since they can
be deactivated. => This is no issue at all.
In conclusion, I would recommend to collect the Use Cases as suggested by
Jeremiah and Igor and invite you all to also check the NHM documentation and
code to look for differences and possibilities on how to solve them.
Best rgards
Jean-Pierre
------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NHM.pdf
Type: application/pdf
Size: 121597 bytes
Desc: not available
URL: <
http://lists.tizen.org/pipermail/ivi/attachments/20140505/3b0f7509/attachment.pdf
>
------------------------------
Subject: Digest Footer
_______________________________________________
IVI mailing list
[email protected]
https://lists.tizen.org/listinfo/ivi
------------------------------
End of IVI Digest, Vol 27, Issue 6
**********************************
_______________________________________________
IVI mailing list
[email protected]
https://lists.tizen.org/listinfo/ivi
