Jump to: navigation, search

Difference between revisions of "Merlin"

(Development)
(Development)
 
(2 intermediate revisions by the same user not shown)
Line 23: Line 23:
 
=Development=
 
=Development=
 
* [[Merlin/Roadmap|Project Roadmap]]
 
* [[Merlin/Roadmap|Project Roadmap]]
 +
* [[Merlin/FAQ|A poor-man docs]]
 
* [https://github.com/stackforge/merlin Source code]
 
* [https://github.com/stackforge/merlin Source code]
 
* [https://etherpad.openstack.org/p/merlin-development Etherpad discussions]
 
* [https://etherpad.openstack.org/p/merlin-development Etherpad discussions]
 
* [https://launchpad.net/merlin Bug and feature tracker]
 
* [https://launchpad.net/merlin Bug and feature tracker]
* [[Merlin/MistralScreenshots| Merlin Workbook Builder screenshots]
+
* [[Merlin/MistralScreenshots| Merlin Workbook Builder screenshots]]
** Ping me if you can't see access the link
 
  
 
==Outdated Stuff (for the sake of history)==
 
==Outdated Stuff (for the sake of history)==

Latest revision as of 13:23, 24 June 2015

Summary

Openstack is known as a system 'made by developers for developers'. When it comes to UX, it sometimes means that one should read comprehensive documentation (or even worse, find out the state of things through examining the source code) just in order to provide correct input data. That is especially true for projects, which employ their own YAML-based DSLs to describe the input data (like Heat, Murano or Mistral). Such data may include a lot of inter-dependencies, constraints and other things that make it very easy for inexperienced developer to make an error. And once they make the error, they face another daunting task: find out what's wrong with the data.

A good UI makes it easier to compose correct YAML input which won't cause cryptic errors. It does so by replacing snippets of YAML document with a composable visual elements, limiting the available input choices to the ones that are compatible for sure, and providing sensible validation hints for the dependencies that are not so unambiguous. Such graphical representation may be less flexible than the raw YAML document, but it doesn't have to entirely replace the existing UI - e.g. to compose a new HOT template one can use the new UI alongside with the old one, watching as the changes in the graphical model are reflected in the YAML document.

It may be tempting to propose a single UI for all Openstack projects requiring complex input data, but even three aforementioned projects are so different that such goal is clearly a lost cause. Still it would be viable to create a client-side framework for building such UIs - so the different projects could utilize it. The project Merlin aims to provide such framework, which may be eventually integrated into Horizon or used by it as a third-party library (like D3.js).

Who will benefit from Merlin

  • (grouped by experience)
    • novice Openstack users, for which it is too hard too provide correct input data by themselves
    • more experienced people who are already familiar with the domain field of project they're using, but do need a quick solution instead of fine-tuning
  • (grouped by role)
    • Openstack developers,
    • Devops,
    • End users running some applications on cloud.

Use Cases

Development

Outdated Stuff (for the sake of history)

Communication

You can contact Merlin team at IRC channel #openstack-merlin at FreeNode.