Upgrading blueprint versions of instances

[Alex Heneveld]

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

[Aled Sage]

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

[Richard Downer]

Alex,

This is the old, deprecated, Google group for Brooklyn - please can you post your message to d...@brooklyn.incubator.apache.org?

Thanks

Richard.

--
You received this message because you are subscribed to the Google Groups "brooklyn-dev (DEPRECATED)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Richard Downer • Principal Engineer • Cloudsoft Corporation • http://www.cloudsoftcorp.com

GitHub richardcloudsoft • Twitter @FrontierTown

[Alex Heneveld]

Oops - address book #fail !  Thanks.

--A

To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Richard Downer • Principal Engineer • Cloudsoft Corporation • http://www.cloudsoftcorp.com

GitHub richardcloudsoft • Twitter @FrontierTown

--
You received this message because you are subscribed to the Google Groups "brooklyn-dev (DEPRECATED)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to brooklyn-dev...@googlegroups.com.