Upgrading blueprint versions of instances

[Alex Heneveld <al...@cloudsoftcorp.com>]

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

Re: Upgrading blueprint versions of instances

[Aled Sage <al...@gmail.com>]

Alex,

Excellent, this will be really useful!

For the GUI support, I agree with your proposal: representing the 
management server(s) and parts of the server internals as entities. That 
will give us a lot of code re-use; improvements there will then benefit 
the GUI for other applications as well.

Aled


On 09/02/2015 15:22, Alex Heneveld wrote:
>
> 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
>