Open Stack

Hello Timur,

I have been developing a graphical Heat Orchestration Template builder. I
first heard about the Merlin project around a week ago and found that what
I have developed in the past few months is in line with what Merlin is
trying to accomplish.

Some of the features of the template builder (described further down)
could be used as part of the UI framework Merlin aims to produce. However,
its most important and useful component is a JavaScript library I have
developed called Barricade.js, which powers the template builder’s data
layer.

Barricade.js aims to solve the problem of using JSON data across a web
app. It creates data model objects out of JSON using a predefined schema
(which looks similar to the schema used in your Murano Dynamic UI). This
removes the disadvantages with JSON and introduces some very important
advantages:

- Encapsulation. JSON values can be set to any type or deleted entirely,
which either causes errors when UI components expect these values to exist
or be of a certain type, or forces the UI components to constantly check
for correctness. Barricade instead wraps around the JSON and provides
accessor methods to ensure type-safe data manipulation. Additionally,
Barricade objects are observable, so changes made to their data trigger
events that can be subscribed to by UI components.

- Normalization. Whenever properties that are defined in the schema are
missing in the JSON, Barricade will fill them in with default values. This
way, UIs will always have valid values where they expect them, making
their design much simpler. Optional properties are extremely common in
Heat templates.

- Metadata. Anything extra attached to JSON must be handled carefully
(such as when converting back to the original YAML format). By wrapping
the JSON with Barricade, metadata and convenience methods that UI
components can use can be defined. For instance, the datatype of any value
or a description to go along with each property in a Heat resource.

- Validation. Soon, the schema will allow defining validators that will
run whenever a new value is attempted to be set on data. Messages about
failed validation will be available so that the UI can display it. This
system seems to be very similar to dynamic UI’s.

What this all boils down to is that all of the logic required to ensure
JSON’s integrity is rolled into Barricade instead of sprinkled into all of
the UI code. This way, UI components can be confident in the data that
they are working with, which makes their code more concise and faster to
develop.

Barricade seems like a great fit for Merlin because the projects it
targets (Heat, Solum, Mistral, Murano) use YAML files that can be used
with Barricade once they are converted to JSON.


About the template builder (see screenshots attached):

- Uses an interactive canvas (powered by a D3.js force-directed graph) to
display Heat resources and the dependencies in between them. New resources
can be drag-and-dropped from a panel onto the canvas. Different resource
types are attracted to different respective areas so that they
automatically arrange themselves in a familiar network topology hierarchy.
 A form/panel is displayed when a resource on the canvas is clicked so
that the resource’s properties can be edited.

- Has two―way data binding provided by Knockout.js interfacing with
Barricade.js so that editing values in forms automatically updates the
topology on the canvas (e.g. Changing resource IDs or creating/removing
dependencies between resources).

- Allows for direct-editing of the template (via text input) and loading
templates via URLs.


Please, let me know if you would like a demo of the template builder and
Barricade!

Thanks,
Drago Rosson




On 8/18/14, 5:19 AM, "Timur Sufiev" <tsufiev at mirantis.com> wrote:

>David,
>
>I'm happy to hear that :)! After thinking a bit, I came up with the
>following strategy for further Merlin development: make all the
>commits into a separate repository (stackforge/merlin) at least until
>the PoC is ready. This will allow to keep project history more
>granular instead of updating one large commit inside openstack/horizon
>gerrit (thus also lessening the burden on Horizon reviewers). Once the
>Merlin proceeds from the experimental/PoC phase to the implementing of
>a more elaborated spec, it will be just the time for it to join with
>the Horizon.
>
>On Wed, Aug 13, 2014 at 2:48 AM, Lyle, David <david.lyle at hp.com> wrote:
>> On 8/6/14, 1:41 PM, "Timur Sufiev" <tsufiev at mirantis.com> wrote:
>>
>>>Hi, folks!
>>>
>>>Two months ago there was an announcement in ML about gathering the
>>>requirements for cross-project UI library for
>>>Heat/Mistral/Murano/Solum [1]. The positive feedback in related
>>>googledoc [2] and some IRC chats and emails that followed convinced me
>>>that I'm not the only person interested in it :), so I'm happy to make
>>>the next announcement.
>>>
>>>The project finally has got its name - 'Merlin' (making complex UIs is
>>>a kind of magic), Openstack wiki page [3] and all other stuff like
>>>stackforge repo, launchpad page and IRC channel (they are all
>>>referenced in [3]). For those who don't like clicking the links, here
>>>is quick summary.
>>>
>>>Merlin aims to provide a convenient client side framework for building
>>>rich UIs for Openstack projects dealing with complex input data with
>>>lot of dependencies and constraints (usually encoded in YAML format
>>>via some DSL) - projects like Heat, Murano, Mistral or Solum. The
>>>ultimate goal for such UI is to save users from reading comprehensive
>>>documentation just in order to provide correct input data, thus making
>>>the UI of these projects more user-friendly. If things go well for
>>>Merlin, it could be eventually merged into Horizon library (I¹ll spare
>>>another option for the end of this letter).
>>>
>>>The framework trying to solve this ambitious task is facing at least 2
>>>challenges:
>>>(1) enabling the proper UX patterns and
>>>(2) dealing with complexities of different projects' DSLs.
>>>
>>>Having worked on DSL things in Murano project before, I'm planning at
>>>first to deal with the challenge (2) in the upcoming Merlin PoC. So,
>>>here is the initial plan: design an in-framework object model (OM)
>>>that could translated forth and back into target project's DSL. This
>>>OM is meant to be synchronised with visual elements shown on browser
>>>canvas. Target project is the Heat with its HOT templates - it has the
>>>most well-established syntax among other projects and comprehensive
>>>documentation.
>>>
>>>Considering the challenge (1), not being a dedicated UX engineer, I'm
>>>planning to start with some rough UI concepts [4] and gradually
>>>improve them relying on community feedback, and especially, Openstack
>>>UX group. If anybody from the UX team (or any other team!) is willing
>>>to be involved to a greater degree than just giving some feedback,
>>>you're are enormously welcome! Join Merlin, it will be fun :)!
>>>
>>>Finally, with this announcement I¹d like to start a discussion with
>>>Horizon community. As far as I know, Horizon in its current state
>>>lacks such UI toolkit as Merlin aims to provide. Would it be by any
>>>chance possible for the Merlin project to be developed from the very
>>>beginning as part of Horizon library? This choice has its pros and
>>>cons I¹m aware of, but I¹d like to hear the opinions of Horizon
>>>developers on that matter.
>>
>> I would like to see this toolset built into Horizon. That will make it
>> accessible to integrated projects like Heat that Horizon already
>>supports,
>> but will also allow other projects to use the horizon library as a
>> building block to providing managing project specific DSLs.
>>
>> David
>>
>>>
>>>[1]
>>>http://lists.openstack.org/pipermail/openstack-dev/2014-June/037054.html
>>>[2]
>>>https://docs.google.com/a/mirantis.com/document/d/19Q9JwoO77724RyOp7XkpY
>>>mA
>>>Lwmdb7JjoQHcDv4ffZ-I/edit#
>>>[3] https://wiki.openstack.org/wiki/Merlin
>>>[4] https://wiki.openstack.org/wiki/Merlin/SampleUI
>>>
>>>--
>>>Timur Sufiev
>>>
>>>_______________________________________________
>>>OpenStack-dev mailing list
>>>OpenStack-dev at lists.openstack.org
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>-- 
>Timur Sufiev
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-------------- next part --------------
A non-text attachment was scrubbed...
Name: simple_template_showing_hierarchy.png
Type: image/png
Size: 131424 bytes
Desc: simple_template_showing_hierarchy.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/52d6ced7/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: editing_resource_properties_and_direct_template_editing.png
Type: image/png
Size: 150765 bytes
Desc: editing_resource_properties_and_direct_template_editing.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/52d6ced7/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: complex_template_and_outputs.png
Type: image/png
Size: 192283 bytes
Desc: complex_template_and_outputs.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/52d6ced7/attachment-0005.png>