Hi, I have a question on js-openstacklib. If it is intended for browsers, there will be lots of issues with cross-domain security policy, browser cannot just go to any REST resource it wants. There is either some server-side proxy required or cooperation of the all the REST services we want to talk to. How we want to handle the cross-domain stuff?
Anton On Thu, Apr 21, 2016 at 5:35 PM, Michael Krotscheck <[email protected]> wrote: > 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? > > Michael > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
