Re: Auto-upgrade with Karaf features

[Guillaume Nodet]

Sorry, the output file only contains the resources, not the wiring.  That
should be fixed.
If you're using 4.1-SNAPSHOT, I can add that quite easily, so please raise
a JIRA issue.
Another option would be to use the --all-wiring option which prints the
wiring to std out, but you'll still have to parse it :-(

2016-11-25 15:00 GMT+01:00 SAI3292 <p.saishrini...@gmail.com>:

> Hi Guillaume,
>
> We ran the commands based on your previous inputs .
> If we run the feature:install command in simulation mode we were getting
> the
> following outputs.
> Cmd: feature:install -u -t -v Admin_App
> Output:
> Removing features: Admin_App/[1.4.1,1.4.1]
> Adding features: Admin_App/[1.5.1,1.5.1]
> Changes to perform:
>   Region: root
> Bundles to uninstall:
>   com.test.product.agent.rna-sample-bundle/1.4.1
> Bundles to install:
>   mvn:com.test.product.agent/rna-sample-bundle/1.5.1
>   Bundles to refresh:
> com.test.product.agent.rna-sample-bundle/1.4.1 (Bundle will be
> uninstalled)
>
> This data is useful to us. But parsing this data would be error prone as
> you
> had suggested before.
>
> We also ran the command with --store option
> Cmd:feature:install --store exported-json -u -t -v Admin_App
>
> The output of the command was redirected to the exported-json file.
> The output is quite huge and doesn't contain the current version of the
> bundle(which we were interested in).
> Is there a way by which we could get the output of the 1st
> command(feature:install  -u -t -v Admin_App) into a JSON format so that we
> could parse the data and get the relevant information.
> Or is there some other options or filters that we need to apply for the
> command to get the precise information.
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.
> com/Auto-upgrade-with-Karaf-features-tp4048761p4048817.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Auto-upgrade with Karaf features

[SAI3292]

Hi Guillaume,

We ran the commands based on your previous inputs .
If we run the feature:install command in simulation mode we were getting the
following outputs.
Cmd: feature:install -u -t -v Admin_App
Output:
Removing features: Admin_App/[1.4.1,1.4.1]
Adding features: Admin_App/[1.5.1,1.5.1]
Changes to perform:
  Region: root
Bundles to uninstall:
  com.test.product.agent.rna-sample-bundle/1.4.1
Bundles to install:
  mvn:com.test.product.agent/rna-sample-bundle/1.5.1
  Bundles to refresh:
com.test.product.agent.rna-sample-bundle/1.4.1 (Bundle will be
uninstalled)

This data is useful to us. But parsing this data would be error prone as you
had suggested before.

We also ran the command with --store option
Cmd:feature:install --store exported-json -u -t -v Admin_App

The output of the command was redirected to the exported-json file. 
The output is quite huge and doesn't contain the current version of the
bundle(which we were interested in).
Is there a way by which we could get the output of the 1st
command(feature:install  -u -t -v Admin_App) into a JSON format so that we
could parse the data and get the relevant information.
Or is there some other options or filters that we need to apply for the
command to get the precise information.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Auto-upgrade-with-Karaf-features-tp4048761p4048817.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Auto-upgrade with Karaf features

[Guillaume Nodet]

2016-11-22 12:32 GMT+01:00 Hari Madhavan :

> Hi All,
>
> We use OSGi with Karaf for a secure and reliable message delivery product
> that is deployed on end-user desktops ( as opposed to servers ) . One of
> the things that is important is to have seamless auto-upgrades of the
> product as new versions are published. There are 2 requirements that we had
> for which I wanted to understand the best solution.
>
>
>- We had decided to stop all activity in the product before starting
>the upgrade. This would cause a small delay for the end-user but as
>upgrades do not happen often it is acceptable as long as we do it only
>during upgrades. The process that we would follow is as follows
>- Check if there is an update available for a feature
>   - If updates are available
>  - complete currently running transactions
>  - shutdown all services
>  - pull down the updates from the server ( Nexus )
>  - install the updates
>
> How can we find whether there is an feature upgrade to be installed ? Is
> there an event on feature:repo-refresh that we can bind to which will tell
> us that the feature has an upgrade ? Alternatively can we invoke
> feature:install when it runs with -t -v parameters through an API interface
> as that would also enable us to confirm whether an attempt to upgrade would
> bring new versions or not.
>
>
Note that your feature repositories should be versioned correctly.  So you
could use the mvn url handler to check if there's a new version of the
repository to use.  Then use the published FeaturesService to simulate the
changes.  It's not really easy to detect if there are any changes, as none
of the methods of the FeaturesService return a useful result.
One way without changing the code would be to use the setOutputFile method
which has the effect of writing the output of the resolver to a file in
json format.  You can then read the file, extract the list of bundles and
compare them to the list of current bundles to see if there are any
changes.


>
>- We wanted to have an option of running an upgrade installer at the
>time of upgrade where the structure of some of the persistent data stores (
>databases , preference files ) related to the product are updated to be
>consistent with the new version of the bundle that manages this data store.
>To do this we defined an upgrade interface that is implemented in bundles
>that need some client side changes to be done at the time of upgrade. We
>plan to invoke this service interface after the upgraded bundle has been
>installed by providing the earlier version of the bundle as a parameter,
> so that the upgrade service implementation within the bundle can serially
>do all upgrade changes from that version to the current version.  To do
>this before installing a feature , I'd like to know the original version of
>each bundle which has changed. This information is available when
>feature:install is run with a -v parameter. How can we programatically
>access that information ?
>
> If you use the method I indicated above to see if there are any changes,
you should have the list of old and new bundles.

Btw, if you prefer, you can use the verbose flag instead of the json
written file.  In order to grab the output which is written to System.out,
you'd have to use the org.apache.felix.service.threadio.ThreadIO service in
order to set the thread based system streams with your own stream to grab
the output.  But you'd have to parse the output which is more error prone I
think.


> Apologies for the long mail and thanks in advance for your suggestions.
>
> Regards
> Hari
>
>
> Regards
> Hari
>
> Hari Madhavan,
> Director - ERP Practice,
> Promantia Global Consulting LLP 
> Ph: +91 9845147731
> *Openbravo Gold Partner*
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: Auto-upgrade with Karaf features

[Hari Madhavan]

Thanks JB.

The programming interface to feature:install is what we require , so that
we can get the output of the simulation in a stream or a  data structure
and parse it to check whether the feature:install  would have any upgrades.

I suppose I can go to the git repository and get the commands and tests
around the service to get some samples to work with... Will check that out.
Is there any other sample that you would suggest ?

Regards
Hari

On Tue, Nov 22, 2016 at 5:21 PM, Jean-Baptiste Onofré 
wrote:

> Hi Hari,
>
> feature:repo-refresh will reload the features XML if it has changed.
> However, the feature might be updated even if the features XML didn't
> change (for instance if you use SNAPSHOT in the feature).
>
> So, basically, we don't have an event today providing the "diff" between
> an installed feature and the resolved feature.
>
> feature:install -u with -t -v is possible and should provide the details
> that you can parse.
>
> Do you want to do it programmatically or by "scripting" ?
>
> For the second point, you can call the feature service to get details,
> providing the same as in the feature:install command (which actually use
> the feature service).
>
> Regards
> JB
>
> On 11/22/2016 12:32 PM, Hari Madhavan wrote:
>
>> Hi All,
>>
>> We use OSGi with Karaf for a secure and reliable message delivery
>> product that is deployed on end-user desktops ( as opposed to servers )
>> . One of the things that is important is to have seamless auto-upgrades
>> of the product as new versions are published. There are 2 requirements
>> that we had for which I wanted to understand the best solution.
>>
>>   * We had decided to stop all activity in the product before starting
>> the upgrade. This would cause a small delay for the end-user but as
>> upgrades do not happen often it is acceptable as long as we do it
>> only during upgrades. The process that we would follow is as follows
>>   o Check if there is an update available for a feature
>>   o If updates are available
>>   + complete currently running transactions
>>   + shutdown all services
>>   + pull down the updates from the server ( Nexus )
>>   + install the updates
>>
>> How can we find whether there is an feature upgrade to be installed
>> ? Is there an event on feature:repo-refresh that we can bind to
>> which will tell us that the feature has an upgrade ? Alternatively
>> can we invoke feature:install when it runs with -t -v parameters
>> through an API interface as that would also enable us to confirm
>> whether an attempt to upgrade would bring new versions or not.
>>
>>   * We wanted to have an option of running an upgrade installer at the
>> time of upgrade where the structure of some of the persistent data
>> stores ( databases , preference files ) related to the product are
>> updated to be consistent with the new version of the bundle that
>> manages this data store. To do this we defined an upgrade interface
>> that is implemented in bundles that need some client side changes to
>> be done at the time of upgrade. We plan to invoke this service
>> interface after the upgraded bundle has been installed by providing
>> the earlier version of the bundle as a parameter,  so that the
>> upgrade service implementation within the bundle can serially do all
>> upgrade changes from that version to the current version.  To do
>> this before installing a feature , I'd like to know the original
>> version of each bundle which has changed. This information is
>> available when feature:install is run with a -v parameter. How can
>> we programatically access that information ?
>>
>> Apologies for the long mail and thanks in advance for your suggestions.
>>
>> Regards
>> Hari
>>
>>
>> Regards
>> Hari
>>
>> Hari Madhavan,
>> Director - ERP Practice,
>> Promantia Global Consulting LLP 
>> Ph: +91 9845147731
>> *Openbravo Gold Partner*
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
Hari Madhavan,
Director - ERP Practice,
Promantia Global Consulting LLP 
Ph: +91 9845147731
*Openbravo Gold Partner*

Re: Auto-upgrade with Karaf features

[Jean-Baptiste Onofré]

Hi Hari,

feature:repo-refresh will reload the features XML if it has changed.
However, the feature might be updated even if the features XML didn't 
change (for instance if you use SNAPSHOT in the feature).


So, basically, we don't have an event today providing the "diff" between 
an installed feature and the resolved feature.


feature:install -u with -t -v is possible and should provide the details 
that you can parse.


Do you want to do it programmatically or by "scripting" ?

For the second point, you can call the feature service to get details, 
providing the same as in the feature:install command (which actually use 
the feature service).


Regards
JB

On 11/22/2016 12:32 PM, Hari Madhavan wrote:

Hi All,

We use OSGi with Karaf for a secure and reliable message delivery
product that is deployed on end-user desktops ( as opposed to servers )
. One of the things that is important is to have seamless auto-upgrades
of the product as new versions are published. There are 2 requirements
that we had for which I wanted to understand the best solution.

  * We had decided to stop all activity in the product before starting
the upgrade. This would cause a small delay for the end-user but as
upgrades do not happen often it is acceptable as long as we do it
only during upgrades. The process that we would follow is as follows
  o Check if there is an update available for a feature
  o If updates are available
  + complete currently running transactions
  + shutdown all services
  + pull down the updates from the server ( Nexus )
  + install the updates

How can we find whether there is an feature upgrade to be installed
? Is there an event on feature:repo-refresh that we can bind to
which will tell us that the feature has an upgrade ? Alternatively
can we invoke feature:install when it runs with -t -v parameters
through an API interface as that would also enable us to confirm
whether an attempt to upgrade would bring new versions or not.

  * We wanted to have an option of running an upgrade installer at the
time of upgrade where the structure of some of the persistent data
stores ( databases , preference files ) related to the product are
updated to be consistent with the new version of the bundle that
manages this data store. To do this we defined an upgrade interface
that is implemented in bundles that need some client side changes to
be done at the time of upgrade. We plan to invoke this service
interface after the upgraded bundle has been installed by providing
the earlier version of the bundle as a parameter,  so that the
upgrade service implementation within the bundle can serially do all
upgrade changes from that version to the current version.  To do
this before installing a feature , I'd like to know the original
version of each bundle which has changed. This information is
available when feature:install is run with a -v parameter. How can
we programatically access that information ?

Apologies for the long mail and thanks in advance for your suggestions.

Regards
Hari


Regards
Hari

Hari Madhavan,
Director - ERP Practice,
Promantia Global Consulting LLP 
Ph: +91 9845147731
*Openbravo Gold Partner*


--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Auto-upgrade with Karaf features

[Hari Madhavan]

Hi All,

We use OSGi with Karaf for a secure and reliable message delivery product
that is deployed on end-user desktops ( as opposed to servers ) . One of
the things that is important is to have seamless auto-upgrades of the
product as new versions are published. There are 2 requirements that we had
for which I wanted to understand the best solution.


   - We had decided to stop all activity in the product before starting the
   upgrade. This would cause a small delay for the end-user but as upgrades do
   not happen often it is acceptable as long as we do it only during upgrades.
   The process that we would follow is as follows
   - Check if there is an update available for a feature
  - If updates are available
 - complete currently running transactions
 - shutdown all services
 - pull down the updates from the server ( Nexus )
 - install the updates

How can we find whether there is an feature upgrade to be installed ? Is
there an event on feature:repo-refresh that we can bind to which will tell
us that the feature has an upgrade ? Alternatively can we invoke
feature:install when it runs with -t -v parameters through an API interface
as that would also enable us to confirm whether an attempt to upgrade would
bring new versions or not.


   - We wanted to have an option of running an upgrade installer at the
   time of upgrade where the structure of some of the persistent data stores (
   databases , preference files ) related to the product are updated to be
   consistent with the new version of the bundle that manages this data store.
   To do this we defined an upgrade interface that is implemented in bundles
   that need some client side changes to be done at the time of upgrade. We
   plan to invoke this service interface after the upgraded bundle has been
   installed by providing the earlier version of the bundle as a parameter,
so that the upgrade service implementation within the bundle can serially
   do all upgrade changes from that version to the current version.  To do
   this before installing a feature , I'd like to know the original version of
   each bundle which has changed. This information is available when
   feature:install is run with a -v parameter. How can we programatically
   access that information ?

Apologies for the long mail and thanks in advance for your suggestions.

Regards
Hari


Regards
Hari

Hari Madhavan,
Director - ERP Practice,
Promantia Global Consulting LLP 
Ph: +91 9845147731
*Openbravo Gold Partner*