brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject Re: Upgrading blueprint versions of instances
Date Mon, 09 Feb 2015 16:53:32 GMT

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.


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 
> 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]

View raw message