<div dir="ltr">This post contains the current working draft of the JavaScript roadmap which myself and Beth Elwell will be working on in Newton. It’s a big list, and we need help - Overall themes for this cycle are Consistency, Interoperability, and engaging with the JavaScript community at large. Our end goal is to build the foundations of a JavaScript ecosystem, which permits the creation of entirely custom interfaces.<br><br>Note: We are not trying to replace Horizon, we are aiming to help those downstream who need something more than “Vanilla OpenStack”. If you'd like to have a discussion on this point, I'd be happy to have that under a different subject.<div><br></div><div>Continue Development: ironic-webclient<br><br>The ironic-webclient will release its first version during the Newton cycle. We’re awfully close to having the basic set of features supported, and with some excellent feedback from the OpenStack UX team, will also have a sexy new user interface that’s currently in the review queue. Once this work is complete, we will begin extracting common components into a new project, named…</div><div><br>New: js-openstacklib<br><br>This new project will be incubated as a single, gate-tested JavaScript API client library for the OpenStack API’s. Its audience is software engineers who wish to build their own user interface using modern javascript tools. As we cannot predict downstream use cases, special care will be taken to ensure the project’s release artifacts can eventually support both browser and server based applications.<br><br>Philosophically, we will be taking a page from the python-openstackclient book, and avoid creating a new project for each of OpenStack’s services. We can make sure our release artifacts can be used piecemeal, however trying to maintain code consistency across multiple different projects is a hard lesson that others have already learned for us. Let’s not do that again.<br><br></div><div>New: js-generator-openstack<br><br>Yeoman is JavaScript’s equivalent of cookiecutter, providing a scaffolding engine which can rapidly set up, and maintain, new projects. Creating and maintaining a yeoman generator will be a critical part of engaging with the JavaScript community, and can drive adoption and consistency across OpenStack as well. Furthermore, it is sophisticated enough that it could also support many things that exist in today’s Python toolchain, such as dependency management, and common tooling maintenance.<br><br>Development of the yeoman generator will draw in lessons learned from OpenStack’s current UI Projects, including Fuel, StoryBoard, Ironic, Horizon, Refstack, and Health Dashboard, and attempt to converge on common practices across projects.<br><br></div><div>New (exploration): js-npm-publish-xstatic<br><br>This project aims to bridge the gap between our JavaScript projects, and Horizon’s measured migration to AngularJS. We don’t believe in duplicating work, so if it is feasible to publish our libraries in a way that Horizon may consume (via the existing xstatic toolchain), then we certainly should pursue that. The notable difference is that our own projects, such as js-openstacklib, don’t have to go through the repackaging step that our current xstatic packages do; thus, if it is possible for us to publish to npm and to xstatic/pypi at the same time, that would be best.<br><br></div><div>New: Xenial Build Nodes<br><br>As of two weeks ago, OpenStack’s Infrastructure is running a version of Node.js and npm more recent than what is available on Trusty LTS. Ultimately, we would like to converge this version on Node4 LTS, the release version maintained by the Node foundation. The easiest way to do this is to simply piggyback on Infra’s impending adoption of Xenial build nodes, though some work is required to ensure this transition goes smoothly.</div><div><br>Maintain: eslint-config-openstack<br><br>eslint has updated to version 2.x, and no more rule bugfixes are being landed in 1.x. eslint-config-openstack will follow in kind, updating itself to use eslint 2.x. We will releases this version as eslint-config-openstack v2.0.0, and continue to track the eslint version numbers from there. Downstream projects are encouraged to adopt this, as it is unlikely that automated dependency updates for JavaScript projects will land this cycle.<br><br></div><div>Maintain: NPM Mirrors<br><br>We are currently synchronizing all npm packages to our AFS master disks, which should be the final step in getting functional npm mirrors. Some minor tweaking will be required to make them functional, and they will need to be maintained throughout the next cycle. Issues raised in the #openstack-infra channel will be promptly addressed.<br><br>This includes work on both the js-openstack-registry-hooks project and the js-afs-blob-store project, which are two custom components we use to drive our mirrors.</div><div><br>Maintain: oslo_middleware.cors<br><br>CORS landed in mitaka, and we will continue to maintain it going forward. In the Newton cycle, we have the following new features planned:</div><div><br>- Automatic allowed_origin detection from Keystone (zero-config).<br>- More consistent use of set_defaults.</div><div>- Configuration maintenance as projects deprecate X-* headers in accordance with RFC 6648.<br><br></div><div>Stretch: Docs<br><br>Documentation is important. Usable documentation is even more important. The tricky bit is that OpenStack’s documentation is all python/sphinx based, and we have not yet investigated whether it’s possible to bridge the two languages. If you have time to explore this intersection, we’d be happy to hear your findings.<br><br>That concludes it for the Newton Cycle. As you can see, there’s a lot of work to do. Can you help?</div><div><br></div><div>Michael</div></div>