brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: Upgrading blueprint versions of instances
Date Mon, 09 Feb 2015 16:53:32 GMT
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
>


Mime
View raw message