brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Upgrading blueprint versions of instances
Date Mon, 09 Feb 2015 15:22:22 GMT

Hi folks,

A big feature people have requested is to make it easier to change the 
version of a blueprint being used to manage a given entity or application.

Here's the use case:

* I installed MyAppBlueprint v1 to the catalog, and deployed an instance.
* I now have an updated MyAppBlueprint v2, which I've installed to the 
catalog.
* I know that v2 is compatible with my existing deployments, and want to 
switch the management logic

With OSGi versioning support @neykov has done a great job of making the 
catalog support multiple versions, and allowing us to run multiple 
versions of the same blueprint at the same time. `catalogItemId` makes 
it clear which version -- and which code -- is in charge of any one entity.

PR #506 [1] solves the technical side of allowing us to reload something 
already being managed and start managing it with a different version of 
the blueprint, without interrupting Brooklyn or interrupting management 
of other entities.  I think it also cleans up a lot of the management 
semantics (and makes room for a per-entity MANAGED_ELSEWHERE state).

Instructions for testing (and test cases) are in the notes for that PR. 
  Please try, and comments welcome.

A few known issues:

* You can only kick it off programmatically.
* If it fails, you get errors in the logs and the old entities remain in 
place; no GUI feedback.
* If there are any tasks to do as part of this upgrade, it can be 
tedious to define these.

To solve these I've been thinking what is the right sort of API model 
and GUI support.  I am thinking that the simplest way is to expose a 
"Server Internals" entity tree, with an entity for rebind and rebind 
problems.  (We can also hook web server controls and entitlements in 
here.)  We'd hide this in the Apps view, and give REST shortcuts, and 
then basically we get sensors/effectors with a serviceable GUI in here, 
and on top of which we could build nicer GUI support in time.

Thoughts on this?

Best
Alex


[1]  https://github.com/apache/incubator-brooklyn/pull/506


Mime
View raw message