Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus

2017-10-23 Thread Abhijit Kumbhare 
Just commenting on code in a mature project depending on code in non-mature
project & nothing else:

I don't think it was written in the project lifecycle rules that some code
in a mature project cannot depend on some code in incubation or a bootstrap
project. By that logic we would never be able to have the following type of
new functionality added in ODL:

   - that some mature offset 1 or 2 projects desire
   - the new functionality either deserves a new offset 0 project or
   logically needs to go into an existing offset 0 incubation/bootstrap
   project

Also there is at least one instance in ODL where we have some mature
projects (NetVirt, VTN, GBP to name a few) depending on non-mature project
like OpenFlow Plugin (which is in bootstrap state).




On Mon, Oct 23, 2017 at 12:23 PM, Robert Varga  wrote:

> On 23/10/17 21:13, Tom Pantelis wrote:
> > On Mon, Oct 23, 2017 at 2:34 PM, Robert Varga  > > wrote:
> >
> > On 23/10/17 14:37, Tom Pantelis wrote:
> > > Or we get infrautils promoted to "mature" to get around the red
> tape.
> > > What would that take? ...
> >
> > A Graduation Review. Unfortunately
> > https://www.opendaylight.org/project-lifecycle-releases
> > 
> disappeared
> > somewhere (Casey, do you know where?), but it includes things like:
> > - clear scope
> > - history of following the mature release cycle
> > etc.
> >
> >
> > If it disappeared then how important can it be now :) ...  These rules
> > and bureaucracy were put into place a while ago when ODL had a lot more
> > participation. Along with Michael, I question whether it's really
> > relevant anymore...
>
> It is part of our governance and how OpenDaylight is set up. If things
> are not relevant anymore, then our governance needs to change -- and
> that is something the Board/TSC have to tackle *first*, we cannot just
> start ignoring it.
>
> I do not agree with this particular piece being irrelevant -- it is just
> not convenient.
>
> I think everyone knows where I stand on convenience vs. long-term
> sustainability :) and that stance is held supported by many scars.
>
> Regards,
> Robert
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus

2017-10-23 Thread Tom Pantelis 
On Mon, Oct 23, 2017 at 2:34 PM, Robert Varga  wrote:

> On 23/10/17 14:37, Tom Pantelis wrote:
> > Or we get infrautils promoted to "mature" to get around the red tape.
> > What would that take? ...
>
> A Graduation Review. Unfortunately
> https://www.opendaylight.org/project-lifecycle-releases disappeared
> somewhere (Casey, do you know where?), but it includes things like:
> - clear scope
> - history of following the mature release cycle
> etc.
>
>
If it disappeared then how important can it be now :) ...  These rules and
bureaucracy were put into place a while ago when ODL had a lot more
participation. Along with Michael, I question whether it's really relevant
anymore...


> Bye,
> Robert
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus

2017-10-23 Thread Robert Varga 
On 23/10/17 14:37, Tom Pantelis wrote:
> Or we get infrautils promoted to "mature" to get around the red tape.
> What would that take? ...

A Graduation Review. Unfortunately
https://www.opendaylight.org/project-lifecycle-releases disappeared
somewhere (Casey, do you know where?), but it includes things like:
- clear scope
- history of following the mature release cycle
etc.

Bye,
Robert



signature.asc
Description: OpenPGP digital signature
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] SingleFeatureTest (SFT) failure on odl-integration-compatible-with-all due to ConflictingModificationAppliedException: Node was created by other transaction.

2017-10-23 Thread Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) 
Previous story: [2].

> who would have to do what

Ideally, Netconf developers would unify their features,
which does not seem to get done anytime soon [3].

There is a workaround in Int/Dist [4] prepared,
but it keeps SFT unstable, this time due to
(lack of) Karaf 4 memory efficiency [5].

Current road to stability seem to be
fixing various ODL project features (like [6])
to be less taxing on Karaf 4 bundle resolver,
and then merging [4].

> It would be nice if the exception included some context like the path.

I have rebased my old [7].
In this case, it is multiple netconf features trying to update
operational topology status for "controller-config" device.

> How does SFT even pick this up to fail the test?

In general, a "caused by" thrown by featuresService.installFeature.
In this case there was an ISE (visible in surefire report [8]
at 12:27:25,742) coming from here [9] (at least in Nitrogen),
not sure which component gets to throw it.

Vratko.

[2] https://lists.opendaylight.org/pipermail/release/2017-October/012728.html
[3] https://jira.opendaylight.org/browse/NETCONF-479
[4] https://git.opendaylight.org/gerrit/64410
[5] https://jira.opendaylight.org/browse/ODLPARENT-125
[6] https://jira.opendaylight.org/browse/INTDIST-92
[7] https://git.opendaylight.org/gerrit/48118
[8] 
https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/distribution/features/singles/odl-integration-compatible-with-all/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz
[9] 
https://github.com/opendaylight/netconf/blob/release/nitrogen/netconf/sal-netconf-connector/src/main/java/org/opendaylight/netconf/sal/connect/netconf/sal/NetconfDeviceTopologyAdapter.java#L243

From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Tom Pantelis
Sent: 23 October, 2017 15:24
To: Michael Vorburger 
Cc: controller-dev 
Subject: Re: [controller-dev] SingleFeatureTest (SFT) failure on 
odl-integration-compatible-with-all due to 
ConflictingModificationAppliedException: Node was created by other transaction.



On Mon, Oct 23, 2017 at 8:41 AM, Michael Vorburger 
> wrote:
Hello,

Any idea who would have to do what to precent SFT from (only occassionally?!) 
failing on odl-integration-compatible-with-all due to 
ConflictingModificationAppliedException: Node was created by other transaction, 
as seen on 
https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/console.log.gz
 for https://git.opendaylight.org/gerrit/#/c/63466/ ?

It would be nice if the exception included some context like the path. Does 
this test install all netconf features? I've seen such sporadic issues with the 
callhome feature when it's installed with all the other netconf features.

How does SFT even pick this up to fail the test? Log scraping?  Or was it a 
"caused by" thrown on blueprint startup?


Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com | IRC: vorburger @freenode | 
~ = http://vorburger.ch

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] SingleFeatureTest (SFT) failure on odl-integration-compatible-with-all due to ConflictingModificationAppliedException: Node was created by other transaction.

2017-10-23 Thread Michael Vorburger 
+netconf-dev:

On Mon, Oct 23, 2017 at 3:24 PM, Tom Pantelis  wrote:

> On Mon, Oct 23, 2017 at 8:41 AM, Michael Vorburger 
> wrote:
>
>> Hello,
>>
>> Any idea who would have to do what to precent SFT from (only
>> occassionally?!) failing on odl-integration-compatible-with-all due to
>> ConflictingModificationAppliedException: Node was created by other
>> transaction, as seen on https://logs.opendaylight.o
>> rg/releng/jenkins092/infrautils-distribution-check-oxygen/
>> 144/console.log.gz for https://git.opendaylight.org/gerrit/#/c/63466/ ?
>>
>
> It would be nice if the exception included some context like the path.
> Does this test install all netconf features? I've seen such sporadic issues
> with the callhome feature when it's installed with all the other netconf
> features.
>
> How does SFT even pick this up to fail the test? Log scraping?  Or was it
> a "caused by" thrown on blueprint startup?
>

No, no log scraping in SFT.. it must be a "caused by" thrown by a BP
constructor..

You can see interesting background on
https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/distribution/features/singles/odl-integration-compatible-with-all/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz
...

>From what I gathered, it must be the
org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceTopologyAdapter,
NB its constructor -> initDeviceData() -> commitTransaction() -> with the
onFailure() doing a throw new IllegalStateException() in
Futures.addCallback() by MoreExecutors.directExecutor(), right? BTW:
Wouldn't that code better be sync and just do a block get() on the Tx? And
handle a ConflictingModificationAppliedException with a retry?

Also, somehow it feels something in SFT is slightly off somewhere, because
ideally really it should show that "IllegalStateException:
RemoteDevice{controller-config} Transaction(init) not committed correctly
at
org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceTopologyAdapter"
instead of (only) its "...ConflictingModificationAppliedException..." cause
- but I'm struggling to find the wrong getCause in odlparent's
bundles-test-lib or features4-test behind this! :-( If you can spot it,
please shout so we can fix it and make get a clearer pointer to the
offender more directly, next time.
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

[controller-dev] 答复: [release] OpenDaylight Issue: CONTROLLER-1770 (Bugzilla 9163)(Internet mail)

2017-10-23 Thread 管振航 
Hi All,

Thank you for your attention and contribution to this issue,the conditions for 
the recurrence of this issue are rather complicated,so I agree with Mr 
Pantelis’s poinion that this is only an edge case.

We did not push our fix after submitting the bug,mainly because we hope to get 
your comments and then push it.

Thank you again for your discussion and analysis on this issue,we will push our 
code later.

In addition,we have also accumulated some other bug fixes and code 
optimizations that will be submitted to the community in later days.

Yours,
Guan

发件人: An Ho [mailto:an...@huawei.com]
发送时间: 2017年10月21日 1:02
收件人: Tom Pantelis 
抄送: kevinzhguan(管振航) ; controller-dev 
; Release 
; Kit Lou ; Ryan 
Goulding 
主题: RE: [release] OpenDaylight Issue: CONTROLLER-1770 (Bugzilla 9163)(Internet 
mail)

Hi Tom Pantelis,

Many Thanks for your expert analysis of the bug and its severity.  Your quick 
response was very much appreciated.

I originally raised the severity based on the concerns raised in the bug 
description, however upon further review I may have erred.

Based on your analysis that this is only an edge case [1], I agree with your 
correct assessment that it should be downgraded appropriately and have updated 
the spreadsheet to reflect the new status of the bug.

Also, Many Thanks to all the folks who kindly contributed their feedback to 
this bug.

Best Regards,
An Ho

[1] https://lists.opendaylight.org/pipermail/release/2017-October/012741.html



From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Friday, October 20, 2017 7:54 AM
To: Kit Lou >; An Ho 
>
Cc: kevinzhg...@tencent.com; controller-dev 
>;
 Release >
Subject: Re: [release] OpenDaylight Issue: CONTROLLER-1770 (Bugzilla 9163)



On Fri, Oct 20, 2017 at 10:31 AM, Kit Lou 
> wrote:
Hello Guan,

You submitted this issue (Bugzilla [1], JIRA [2]) a month ago and indicated you 
had a patch ready for review.

Could you please provide a link to the patch?  Your contribution is appreciated.

In you opinion,  is this a blocker bug (as we are unsure why this bug got 
elevated 2 days ago from normal severity to blocker)?


It was An Ho that elevated it - we should be asking him.


Best Regards,
Kit Lou

[1] 
https://docs.google.com/sphttps://bugs.opendaylight.org/show_bug.cgi?id=9163
  

[2] 
https://docs.google.com/sphttps://jira.opendaylight.org/browse/CONTROLLER-1770

___
release mailing list
rele...@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/release

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] SingleFeatureTest (SFT) failure on odl-integration-compatible-with-all due to ConflictingModificationAppliedException: Node was created by other transaction.

2017-10-23 Thread Tom Pantelis 
On Mon, Oct 23, 2017 at 8:41 AM, Michael Vorburger 
wrote:

> Hello,
>
> Any idea who would have to do what to precent SFT from (only
> occassionally?!) failing on odl-integration-compatible-with-all due to
> ConflictingModificationAppliedException: Node was created by other
> transaction, as seen on https://logs.opendaylight.org/releng/jenkins092/
> infrautils-distribution-check-oxygen/144/console.log.gz for
> https://git.opendaylight.org/gerrit/#/c/63466/ ?
>

It would be nice if the exception included some context like the path. Does
this test install all netconf features? I've seen such sporadic issues with
the callhome feature when it's installed with all the other netconf
features.

How does SFT even pick this up to fail the test? Log scraping?  Or was it a
"caused by" thrown on blueprint startup?


>
> Tx,
> M.
> --
> Michael Vorburger, Red Hat
> vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus

2017-10-23 Thread Michael Vorburger 
On Mon, Oct 23, 2017 at 2:37 PM, Tom Pantelis  wrote:

> On Mon, Oct 23, 2017 at 8:35 AM, Tom Pantelis 
> wrote:
>
>> On Mon, Oct 23, 2017 at 5:35 AM, Faseela K 
>> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>>Thanks for reviewing the patch, and giving comments.
>>>
>>>But there is a comment from Robert that this adds dependency of a
>>> mature project to an incubation project J Would like to know whether it
>>> is completely not possible. In that case, we have to find out other ways to
>>> achieve this.
>>>
>>
>> I don't really know the rules/philosophies/history with incubation
>> projects and dependencies and what it takes or means to be "mature" (or if
>> really matters anymore with ODL). However I don't think we shouldn't let
>> bureaucracy impede progress so I'm fine with the dependency. We should be
>> able to  freely use infrautils - prior to it we used yangtools as a kind of
>> dumping ground for generic components (that had nothing to do with yang)
>> b/c we had no where else to put them. infrautils *should* serve that
>> purpose now. But if it's a showstopper then the
>> proposed DatastoreStatusMonitor could actually reside anywhere since it
>> just uses JMX.
>>
>
> Or we get infrautils promoted to "mature" to get around the red tape. What
> would that take? ...
>

If this just about writing the word "mature" instead of "incubting"
somewhere (where?) then let's do it..

PS: Personally I think these sort of things are fairly meaningless, so I
have little interest in them.


> Thanks,
>>>
>>> Faseela
>>>
>>>
>>>
>>> *From:* Tom Pantelis [mailto:tompante...@gmail.com]
>>> *Sent:* Thursday, October 12, 2017 4:28 PM
>>> *To:* Faseela K 
>>> *Cc:* Anil Vishnoi ; Muthukumaran K <
>>> muthukumara...@ericsson.com>; infrautils-...@lists.opendaylight.org;
>>> controller-dev@lists.opendaylight.org; R Srinivasan E <
>>> r.e.sriniva...@ericsson.com>; Dayavanti Gopal Kamath <
>>> dayavanti.gopal.kam...@ericsson.com>
>>> *Subject:* Re: [controller-dev] Expose Datastore health to applications
>>> via infrautils.diagstatus
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Oct 12, 2017 at 6:36 AM, Faseela K 
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> So here is how diagstatus module works – any application should register
>>> as a “service” with the framework, report an initial status(using the APIs
>>> provided by diagstatus).
>>>
>>> There is another OsgiService “ServiceStatusProvider” exposed, and if
>>> applications implement the same, that will be called everytime an external
>>> request is made to get the current service status.
>>>
>>> In looking at the API, it appears an app would register with the
>>> DiagStatusService and invoke report each time its status changes. An app
>>> can also register a ServiceStatusProvider to report its status when
>>> queried. It seems this is an alternative to interacting with the
>>> DiagStatusService in looking at the DiagStatusServiceImpl which always
>>> calls updateServiceStatusMap to query the ServiceStatusProviders from the
>>> get* methods. Given that, why would an app need to explicitly register and
>>> push its status to the DiagStatusService? Why not just advertise a
>>> ServiceStatusProvider? This seems simpler. In that case,
>>> DiagStatusServiceImpl doesn't need to maintain the statusMap - it would
>>> just query the ServiceStatusProvider(s) on demand. Or am I missing
>>> something?
>>>
>>>
>>>
>>> For services like “DATASTORE” only the pull model is required, just
>>> register the service and implement ServiceStatusProvider.
>>>
>>> There are some usecases in genius, where a push model was preferred, and
>>> hence we have kept both the options open.
>>>
>>>
>>>
>>> OK.  By "just register the service" I assume you mean just advertise a 
>>> ServiceStatusProvider
>>> OSGi service. It is not necessary to explicitly register with the 
>>> DiagStatusService
>>> as that is implicit by advertising a ServiceStatusProvider.
>>>
>>>
>>>
>>> The code in DiagStatusServiceImpl does not enforce explicit registration
>>> - one can just call report w/o a prior register call - not sure if that was
>>> the original intent.  Similarly a ServiceStatusProvider's status is
>>> reported even if it didn't explicitly call register.
>>>
>>>
>>>
>>> Right Tom, the original intent was to allow only services who do
>>> explicit registration. But it is not enforced yet, wanted to get inputs on
>>> how the apps would be interested to go about this. Michael recently
>>> modified the implementation to allow deregistration only for those who
>>> actually registered. We were thinking on enforcing the same everywhere, but
>>> just thought of sharing the idea to apps before doing the same.
>>>
>>>
>>>
>>> It seems the only reason for explicit registration would be to remove
>>> it from being reported on unregistration. But this could also be effected
>>> by reporting that as

[controller-dev] SingleFeatureTest (SFT) failure on odl-integration-compatible-with-all due to ConflictingModificationAppliedException: Node was created by other transaction.

2017-10-23 Thread Michael Vorburger 
Hello,

Any idea who would have to do what to precent SFT from (only
occassionally?!) failing on odl-integration-compatible-with-all due to
ConflictingModificationAppliedException: Node was created by other
transaction, as seen on
https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/console.log.gz
for https://git.opendaylight.org/gerrit/#/c/63466/ ?

Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com | IRC: vorburger @freenode | ~ = http://vorburger.ch
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus

2017-10-23 Thread Tom Pantelis 
On Mon, Oct 23, 2017 at 8:35 AM, Tom Pantelis  wrote:

>
>
> On Mon, Oct 23, 2017 at 5:35 AM, Faseela K  wrote:
>
>> Hi all,
>>
>>
>>
>>Thanks for reviewing the patch, and giving comments.
>>
>>But there is a comment from Robert that this adds dependency of a
>> mature project to an incubation project J Would like to know whether it
>> is completely not possible. In that case, we have to find out other ways to
>> achieve this.
>>
>
> I don't really know the rules/philosophies/history with incubation
> projects and dependencies and what it takes or means to be "mature" (or if
> really matters anymore with ODL). However I don't think we shouldn't let
> bureaucracy impede progress so I'm fine with the dependency. We should be
> able to  freely use infrautils - prior to it we used yangtools as a kind of
> dumping ground for generic components (that had nothing to do with yang)
> b/c we had no where else to put them. infrautils *should* serve that
> purpose now. But if it's a showstopper then the proposed 
> DatastoreStatusMonitor
> could actually reside anywhere since it just uses JMX.
>
>


Or we get infrautils promoted to "mature" to get around the red tape. What
would that take? ...


>
>>
>> Thanks,
>>
>> Faseela
>>
>>
>>
>> *From:* Tom Pantelis [mailto:tompante...@gmail.com]
>> *Sent:* Thursday, October 12, 2017 4:28 PM
>> *To:* Faseela K 
>> *Cc:* Anil Vishnoi ; Muthukumaran K <
>> muthukumara...@ericsson.com>; infrautils-...@lists.opendaylight.org;
>> controller-dev@lists.opendaylight.org; R Srinivasan E <
>> r.e.sriniva...@ericsson.com>; Dayavanti Gopal Kamath <
>> dayavanti.gopal.kam...@ericsson.com>
>> *Subject:* Re: [controller-dev] Expose Datastore health to applications
>> via infrautils.diagstatus
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 12, 2017 at 6:36 AM, Faseela K 
>> wrote:
>>
>>
>>
>>
>>
>> So here is how diagstatus module works – any application should register
>> as a “service” with the framework, report an initial status(using the APIs
>> provided by diagstatus).
>>
>> There is another OsgiService “ServiceStatusProvider” exposed, and if
>> applications implement the same, that will be called everytime an external
>> request is made to get the current service status.
>>
>> In looking at the API, it appears an app would register with the
>> DiagStatusService and invoke report each time its status changes. An app
>> can also register a ServiceStatusProvider to report its status when
>> queried. It seems this is an alternative to interacting with the
>> DiagStatusService in looking at the DiagStatusServiceImpl which always
>> calls updateServiceStatusMap to query the ServiceStatusProviders from the
>> get* methods. Given that, why would an app need to explicitly register and
>> push its status to the DiagStatusService? Why not just advertise a
>> ServiceStatusProvider? This seems simpler. In that case,
>> DiagStatusServiceImpl doesn't need to maintain the statusMap - it would
>> just query the ServiceStatusProvider(s) on demand. Or am I missing
>> something?
>>
>>
>>
>> For services like “DATASTORE” only the pull model is required, just
>> register the service and implement ServiceStatusProvider.
>>
>> There are some usecases in genius, where a push model was preferred, and
>> hence we have kept both the options open.
>>
>>
>>
>> OK.  By "just register the service" I assume you mean just advertise a 
>> ServiceStatusProvider
>> OSGi service. It is not necessary to explicitly register with the 
>> DiagStatusService
>> as that is implicit by advertising a ServiceStatusProvider.
>>
>>
>>
>> The code in DiagStatusServiceImpl does not enforce explicit registration
>> - one can just call report w/o a prior register call - not sure if that was
>> the original intent.  Similarly a ServiceStatusProvider's status is
>> reported even if it didn't explicitly call register.
>>
>>
>>
>> Right Tom, the original intent was to allow only services who do explicit
>> registration. But it is not enforced yet, wanted to get inputs on how the
>> apps would be interested to go about this. Michael recently modified the
>> implementation to allow deregistration only for those who actually
>> registered. We were thinking on enforcing the same everywhere, but just
>> thought of sharing the idea to apps before doing the same.
>>
>>
>>
>> It seems the only reason for explicit registration would be to remove it
>> from being reported on unregistration. But this could also be effected by
>> reporting that as a STOPPED status, which might be useful to report. In any
>> event, explicit reg/unreg via the DiagStatusService  API would only be
>> needed/enforced when pushing status.  Advertising a ServiceStatusProvider
>> OSGi service is an implicit registration and removal of the OSGi service is
>> an implicit unregistration.
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Faseela
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus

2017-10-23 Thread Tom Pantelis 
On Mon, Oct 23, 2017 at 5:35 AM, Faseela K  wrote:

> Hi all,
>
>
>
>Thanks for reviewing the patch, and giving comments.
>
>But there is a comment from Robert that this adds dependency of a
> mature project to an incubation project J Would like to know whether it
> is completely not possible. In that case, we have to find out other ways to
> achieve this.
>

I don't really know the rules/philosophies/history with incubation projects
and dependencies and what it takes or means to be "mature" (or if really
matters anymore with ODL). However I don't think we shouldn't let
bureaucracy impede progress so I'm fine with the dependency. We should be
able to  freely use infrautils - prior to it we used yangtools as a kind of
dumping ground for generic components (that had nothing to do with yang)
b/c we had no where else to put them. infrautils *should* serve that
purpose now. But if it's a showstopper then the
proposed DatastoreStatusMonitor could actually reside anywhere since it
just uses JMX.


>
>
> Thanks,
>
> Faseela
>
>
>
> *From:* Tom Pantelis [mailto:tompante...@gmail.com]
> *Sent:* Thursday, October 12, 2017 4:28 PM
> *To:* Faseela K 
> *Cc:* Anil Vishnoi ; Muthukumaran K <
> muthukumara...@ericsson.com>; infrautils-...@lists.opendaylight.org;
> controller-dev@lists.opendaylight.org; R Srinivasan E <
> r.e.sriniva...@ericsson.com>; Dayavanti Gopal Kamath <
> dayavanti.gopal.kam...@ericsson.com>
> *Subject:* Re: [controller-dev] Expose Datastore health to applications
> via infrautils.diagstatus
>
>
>
>
>
>
>
> On Thu, Oct 12, 2017 at 6:36 AM, Faseela K  wrote:
>
>
>
>
>
> So here is how diagstatus module works – any application should register
> as a “service” with the framework, report an initial status(using the APIs
> provided by diagstatus).
>
> There is another OsgiService “ServiceStatusProvider” exposed, and if
> applications implement the same, that will be called everytime an external
> request is made to get the current service status.
>
> In looking at the API, it appears an app would register with the
> DiagStatusService and invoke report each time its status changes. An app
> can also register a ServiceStatusProvider to report its status when
> queried. It seems this is an alternative to interacting with the
> DiagStatusService in looking at the DiagStatusServiceImpl which always
> calls updateServiceStatusMap to query the ServiceStatusProviders from the
> get* methods. Given that, why would an app need to explicitly register and
> push its status to the DiagStatusService? Why not just advertise a
> ServiceStatusProvider? This seems simpler. In that case,
> DiagStatusServiceImpl doesn't need to maintain the statusMap - it would
> just query the ServiceStatusProvider(s) on demand. Or am I missing
> something?
>
>
>
> For services like “DATASTORE” only the pull model is required, just
> register the service and implement ServiceStatusProvider.
>
> There are some usecases in genius, where a push model was preferred, and
> hence we have kept both the options open.
>
>
>
> OK.  By "just register the service" I assume you mean just advertise a 
> ServiceStatusProvider
> OSGi service. It is not necessary to explicitly register with the 
> DiagStatusService
> as that is implicit by advertising a ServiceStatusProvider.
>
>
>
> The code in DiagStatusServiceImpl does not enforce explicit registration -
> one can just call report w/o a prior register call - not sure if that was
> the original intent.  Similarly a ServiceStatusProvider's status is
> reported even if it didn't explicitly call register.
>
>
>
> Right Tom, the original intent was to allow only services who do explicit
> registration. But it is not enforced yet, wanted to get inputs on how the
> apps would be interested to go about this. Michael recently modified the
> implementation to allow deregistration only for those who actually
> registered. We were thinking on enforcing the same everywhere, but just
> thought of sharing the idea to apps before doing the same.
>
>
>
> It seems the only reason for explicit registration would be to remove it
> from being reported on unregistration. But this could also be effected by
> reporting that as a STOPPED status, which might be useful to report. In any
> event, explicit reg/unreg via the DiagStatusService  API would only be
> needed/enforced when pushing status.  Advertising a ServiceStatusProvider
> OSGi service is an implicit registration and removal of the OSGi service is
> an implicit unregistration.
>
>
>
>
>
> Thanks,
>
> Faseela
>
>
>
>
>
>
>
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus

2017-10-23 Thread Faseela K 
Hi all,

   Thanks for reviewing the patch, and giving comments.
   But there is a comment from Robert that this adds dependency of a mature 
project to an incubation project ☺ Would like to know whether it is completely 
not possible. In that case, we have to find out other ways to achieve this.

Thanks,
Faseela

From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Thursday, October 12, 2017 4:28 PM
To: Faseela K 
Cc: Anil Vishnoi ; Muthukumaran K 
; infrautils-...@lists.opendaylight.org; 
controller-dev@lists.opendaylight.org; R Srinivasan E 
; Dayavanti Gopal Kamath 

Subject: Re: [controller-dev] Expose Datastore health to applications via 
infrautils.diagstatus



On Thu, Oct 12, 2017 at 6:36 AM, Faseela K 
> wrote:


So here is how diagstatus module works – any application should register as a 
“service” with the framework, report an initial status(using the APIs provided 
by diagstatus).
There is another OsgiService “ServiceStatusProvider” exposed, and if 
applications implement the same, that will be called everytime an external 
request is made to get the current service status.
In looking at the API, it appears an app would register with the 
DiagStatusService and invoke report each time its status changes. An app can 
also register a ServiceStatusProvider to report its status when queried. It 
seems this is an alternative to interacting with the DiagStatusService in 
looking at the DiagStatusServiceImpl which always calls updateServiceStatusMap 
to query the ServiceStatusProviders from the get* methods. Given that, why 
would an app need to explicitly register and push its status to the 
DiagStatusService? Why not just advertise a ServiceStatusProvider? This seems 
simpler. In that case, DiagStatusServiceImpl doesn't need to maintain the 
statusMap - it would just query the ServiceStatusProvider(s) on demand. Or am I 
missing something?

For services like “DATASTORE” only the pull model is required, just register 
the service and implement ServiceStatusProvider.
There are some usecases in genius, where a push model was preferred, and hence 
we have kept both the options open.

OK.  By "just register the service" I assume you mean just advertise a 
ServiceStatusProvider OSGi service. It is not necessary to explicitly register 
with the DiagStatusService as that is implicit by advertising a 
ServiceStatusProvider.

The code in DiagStatusServiceImpl does not enforce explicit registration - one 
can just call report w/o a prior register call - not sure if that was the 
original intent.  Similarly a ServiceStatusProvider's status is reported even 
if it didn't explicitly call register.

Right Tom, the original intent was to allow only services who do explicit 
registration. But it is not enforced yet, wanted to get inputs on how the apps 
would be interested to go about this. Michael recently modified the 
implementation to allow deregistration only for those who actually registered. 
We were thinking on enforcing the same everywhere, but just thought of sharing 
the idea to apps before doing the same.

It seems the only reason for explicit registration would be to remove it from 
being reported on unregistration. But this could also be effected by reporting 
that as a STOPPED status, which might be useful to report. In any event, 
explicit reg/unreg via the DiagStatusService  API would only be needed/enforced 
when pushing status.  Advertising a ServiceStatusProvider OSGi service is an 
implicit registration and removal of the OSGi service is an implicit 
unregistration.


Thanks,
Faseela




___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev