Open Stack

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 <krotscheck at gmail.com>
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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160512/5b7d0d94/attachment.html>