Open Stack

Hello there, Anton-

In Mitaka, most of OpenStack's services have landed CORS support. While
it's not yet "Automagic" (i.e. it still requires some manual
configuration), we no longer have to rely on any server component to render
a user interface.

The big outstanding things we need to do for CORS support to be awesome, is
to make sure it lands in newer API's (like Freezer), and to figure out a
sane and idempotent way for our middleware to configure itself from the
trusted-dashboards list in keystone.

Michael

On Thu, May 12, 2016 at 12:35 AM Anton Zemlyanov <azemlyanov at mirantis.com>
wrote:

> 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
>>
>> __________________________________________________________________________
> 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/07804900/attachment.html>