[openstack-dev] JavaScript RoadMap for OpenStack Newton

Michael Krotscheck krotscheck at gmail.com
Thu Apr 21 14:35:46 UTC 2016

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.

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.

Continue Development: ironic-webclient

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…

New: js-openstacklib

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.

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.

New: js-generator-openstack

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.

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.

New (exploration): js-npm-publish-xstatic

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.

New: Xenial Build Nodes

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.

Maintain: eslint-config-openstack

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.

Maintain: NPM Mirrors

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.

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.

Maintain: oslo_middleware.cors

CORS landed in mitaka, and we will continue to maintain it going forward.
In the Newton cycle, we have the following new features planned:

- Automatic allowed_origin detection from Keystone (zero-config).
- More consistent use of set_defaults.
- Configuration maintenance as projects deprecate X-* headers in accordance
with RFC 6648.

Stretch: Docs

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.

That concludes it for the Newton Cycle. As you can see, there’s a lot of
work to do. Can you help?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160421/0cb6c326/attachment.html>

More information about the OpenStack-dev mailing list