[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New Angular UI for Brooklyn [DISCUSS]

Dear Brooklyners,

Our users at Fujitsu, UShareSoft, and Cloudsoft have generously sponsored the contribution of a new UI for Apache Brooklyn. This is based on the previously-proprietary Cloudsoft AMP UI, for those of you familiar with that.

The proposed newly contributed UI has all the functionality of the existing UI including an inspector, groovy console, and online REST docs. It is much more recent (angular, webpack), modular, easy to develop against, and lovely to look at, and so would be a great contribution based solely on that.

But even better, it provides a lot of new features:

* A visual blueprint composer: drag-and-drop elements from the catalog onto a canvas, with a bi-directional YAML editor

* More live activity update: a kilt view for activities, tailing output from SSH commands

* A bundle-oriented catalog: with search, bundle- or type- view, delete bundles

* An extensible, skinnable, and reusable modular architecture: embed angular directives and components from this project in others, build a branded version of the UI, and/or add your own modules (e.g. to accompany specific blueprints)

The last point in particular I think will be very valuable: it will allow people to use Brooklyn in many more good ways! There are plans to make the Composer embeddable and able to work with other input libraries (think e.g. of pointing it at a Docker repo or an image catalog), and with widgets for configuring items, all ultimately generating Brooklyn blueprints.

Note that this is proposed to replace the existing UI, and as we have already deprecated the non-OSGi build, it is proposed to make this compatible only with the OSGi build.

It is also worth pointing out that the main authors on this UI are already Brooklyn contributors, so there is enough experience among active project members to maintain, explain, and extend this.

Assuming this proposal finds favour, we will open a repo for review purposes (but it will not be a merged via PR, with the actual contribution to come via the IP clearance process [1]), followed by associated PRs in other projects so that everything works seamlessly (which as minor changes to existing code is more suited to PRs than the IP clearance process). Specifically we will:

* Ensure it builds and runs with the new UI in place of the old (note below on the Karaf switch)

* Ensure all tests are passing (esp UI tests)

* Ensure there are effective dev/test pathways and that documentation is updated (in particular for testing the UI and with the UI; this should be much simpler as the new UI can run separately, point at a REST endpoint, and can do incremental updates for UI code changes made while running!)

* Ensure we have IP clearance, license, and are duly diligent in the approval (as this is a large contribution we recognise this will need special attention)

Are there any objections at this point, or any suggestions for other tasks we should do to ensure its smooth integration? Note that this is purely advisory at this stage but we would very much appreciate early sight of any potential obstacles.

Once the above list is complete we will commence the IP clearance process including formal vote.


[1] https://incubator.apache.org/ip-clearance/ip-clearance-template.html