Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Thomas Goirand]

On 05/12/2016 06:27 PM, Michael Krotscheck wrote:
> Responses inline:
> 
> On 04/21/2016 04:35 PM, Michael Krotscheck wrote:
> > 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.
> 
> 
> Update: We're now on xenial. Yay 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.
> 
> While this is a nice intention, I'd like to remind folks that
> historically, all JS and Node stuff have been maintained in Debian. So
> the work to maintain packages are done in Sid. So best would be to make
> sure the toolchain works there, as this is the way to go also for
> getting stuff pushed to Ubuntu (ie: via Debian).
> 
> 
> That sounds great, though at this time I do not believe that we're
> gating on debian.

This has nothing to do with what I'm discussing. But yeah, we could
start thinking about gating on Debian Sid! :)

What I was saying, is that for packages to reach Ubuntu, we must
contribute them in Debian Sid first, which is where the work is done.

> Has anyone agreed to do the work to include debian
> nodes in infra?

It's already there. It took me a *very* long time to get it done.

> With that in mind, does Debian have exemption rules for
> frequently-updating packages like Firefox?

No. But you can use Sid or Testing, and there, updates are fast. Sid and
Testing have NodeJS 4.4.3, and Experimental has 6.0.0.

> If so, did Node receive one of these exemptions?

No way. But we can always upload to stable-backports. That's what it is
for, in fact.

> With Node4 LTS now in maintenance, and Node6 LTS
> officially released, that'll make it tricky for us to stick with
> whatever's in Sid. Non-compatible LTS cycles make for an unhappy infra.

See above. Sid and Experimental are moving targets.

> With that in mind, we've just started the
> 'js-generator-openstack' project, which will evolve to handle dependency
> version maintenance, tooling updates, and new project bootstrapping. I
> expect that most of the discussions about "What tools do we use" will
> happen there.

I just hope we find a way to avoid this path:
http://www.commitstrip.com/en/2016/05/10/a-moment-of-nostalgia/

:)

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Jeremy Stanley]

On 2016-05-12 16:27:43 + (+), Michael Krotscheck wrote:
[...]
> Has anyone agreed to do the work to include debian nodes in infra?
> I know we've got Centos7 and Fedora23 now, adding Debian doesn't
> seem like a huge stretch.

We have "debian-jessie" images and workers in Nodepool already. Once
usage picks up a bit, I expect to see Stretch/Sid added as well.

> With that in mind, does Debian have exemption rules for
> frequently-updating packages

It used to have something called "volatile" but more recent releases
use some combination of "updates" and "backports" suites to achieve
this.

> like Firefox?

The "iceweasel" (unbranded Firefox) package in Debian is based on
ESR versions to mostly avoid that madness.

> If so, did Node receive one of these exemptions?

Doesn't look like it. The latest "nodejs" package available in
Jessie is based on 0.10.29, though Stretch (testing for the next
release) and Sid (unstable) have 4.3.x versions presently. Also
nodejs 6.0.0 is available in experimental.

> With Node4 LTS now in maintenance, and Node6 LTS officially released,
> that'll make it tricky for us to stick with whatever's in Sid.
> Non-compatible LTS cycles make for an unhappy infra.
[...]

Looks like with Stretch and beyond we can rely on not having to
import/pin/backport a nodejs 4.x package, but in Jessie we'll likely
need a workaround still.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Michael Krotscheck]

Responses inline:

On 04/21/2016 04:35 PM, Michael Krotscheck wrote:
> > 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.
>

Update: We're now on xenial. Yay 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.
>
> While this is a nice intention, I'd like to remind folks that
> historically, all JS and Node stuff have been maintained in Debian. So
> the work to maintain packages are done in Sid. So best would be to make
> sure the toolchain works there, as this is the way to go also for
> getting stuff pushed to Ubuntu (ie: via Debian).
>

That sounds great, though at this time I do not believe that we're gating
on debian. Has anyone agreed to do the work to include debian nodes in
infra? I know we've got Centos7 and Fedora23 now, adding Debian doesn't
seem like a huge stretch.

With that in mind, does Debian have exemption rules for frequently-updating
packages like Firefox? If so, did Node receive one of these exemptions?
With Node4 LTS now in maintenance, and Node6 LTS officially released,
that'll make it tricky for us to stick with whatever's in Sid.
Non-compatible LTS cycles make for an unhappy infra.


> I'm hereby volunteering to help if we need JS or Node packaging to
> happen. I haven't started yet working on that (like packaging Gulp, see
> later in this message...) but I will, sooner or later.
>

Woot! Thank you!


> As I understand, the way to package NPM stuff is to use npm2deb. Once
> we have npm packages pushed as NodeJS package, they would later on
> be aggregated by some tools. Fuel uses Gulp and RequireJS to do that.
> I'd be nice if we were standardizing on some tooling, so that downstream
> package maintainers wouldn't have to do the work multiple times. Has
> this discussion already happened?


The discussion has happened for _some_ tools (eslint), however under
OpenStack's governance we can only 'suggest' what people should use, not
enforce it. With that in mind, we've just started the
'js-generator-openstack' project, which will evolve to handle dependency
version maintenance, tooling updates, and new project bootstrapping. I
expect that most of the discussions about "What tools do we use" will
happen there.

Michael
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Thomas Goirand]

Hi,

If I may bring some insights from the distro's viewpoint...

On 04/21/2016 04:35 PM, Michael Krotscheck wrote:
> 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.

While this is a nice intention, I'd like to remind folks that
historically, all JS and Node stuff have been maintained in Debian. So
the work to maintain packages are done in Sid. So best would be to make
sure the toolchain works there, as this is the way to go also for
getting stuff pushed to Ubuntu (ie: via Debian).

I'm hereby volunteering to help if we need JS or Node packaging to
happen. I haven't started yet working on that (like packaging Gulp, see
later in this message...) but I will, sooner or later.

As I understand, the way to package NPM stuff is to use npm2deb. Once we
have npm packages pushed as NodeJS package, they would later on be
aggregated by some tools. Fuel uses Gulp and RequireJS to do that. I'd
be nice if we were standardizing on some tooling, so that downstream
package maintainers wouldn't have to do the work multiple times. Has
this discussion already happened?

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Michael Krotscheck]

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 
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 
> 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: 

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Anton Zemlyanov]

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 
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 

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Michael Krotscheck]

On Thu, Apr 21, 2016 at 10:21 AM Monty Taylor  wrote:

> Neat! Maybe let's find a time at the summit to sit down and look through
> things. I'm guessing that adding a second language consumer to the
> config will raise a ton of useful questions around documentation, data
> format, etc - but those will likely be super valuable to find, document
> or fix.


Fair warning- I'm not volunteering to fix that. I'm ok using an established
format, but [big honkin' list of JS work] is going to take precedence.

Michael
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Monty Taylor]

On 04/21/2016 10:35 AM, Michael Krotscheck wrote:



On Thu, Apr 21, 2016 at 8:28 AM Monty Taylor > wrote:

On 04/21/2016 10:05 AM, Hayes, Graham wrote:
 > On 21/04/2016 15:39, Michael Krotscheck wrote:
 >> 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.

I'd love to chat about js-openstacklib supporting clouds.yaml files for
config.


I see absolutely ZERO reason why we shouldn't just use an existing
configuration format. Except, well, maybe this: https://xkcd.com/927/

The only existing user of a custom config file we have right now is
ironic-webclient, and its code is really more "how do I load it" rather
than "how do I parse it. Updating it should not be difficult, and as we
don't have a release yet, I don't anticipate any backwards compatibility
issues.

Code, for reference:
http://git.openstack.org/cgit/openstack/ironic-webclient/tree/app/js/modules/openstack/configuration.js


Neat! Maybe let's find a time at the summit to sit down and look through 
things. I'm guessing that adding a second language consumer to the 
config will raise a ton of useful questions around documentation, data 
format, etc - but those will likely be super valuable to find, document 
or fix.


Woohoo


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Monty Taylor]

On 04/21/2016 10:32 AM, Michael Krotscheck wrote:

On Thu, Apr 21, 2016 at 8:10 AM Hayes, Graham > wrote:

On 21/04/2016 15:39, Michael Krotscheck wrote:

python-openstackclient does require the creation of a new repo for each
project (unless you are one of the chosen few).

Does this mean you will accept all projects to the library, or just
selected projects?


In a perfect world, we'd accept everyone. I have some questions about
things like "Does devstack fall down if we try to gate on every service
ever", and how to package things so we can meet both the "gimme
everything" and the "I just want one service" users, however those
strike me as solvable problems.


FWIW, our policy in shade for adding new service support has been that 
adding the service to our existing devstack gate jobs does not break 
things, and that all new code must come with functional tests that run 
against a live devstack with the service in question enabled. So far it 
has worked well - we have not had a large land rush of people trying to 
get stuff in, but when they have showed up there has been a clear 
expectation on what it means that has nothing to do with whether or not 
I like the service.


A case in point that worth mentioning ... last cycle Yolanda started 
work on adding magnum support to shade - but adding magnum to our 
devstack config at that time increased the failure rate too much because 
the magnum devstack config was downloading atomic images from fedora. So 
- we disabled it again ... and yolanda went and worked with 
diskimage-builder to add support for building atomic images. And then we 
added a job that builds atomic images and uploads them to tarballs.o.o 
and then made sure the magnum devstack could consume those.


Now that all of those things are true, we're about to re-enable magnum 
support because we're confident that having magnum in our gate is a 
solid thing.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Michael Krotscheck]

On Thu, Apr 21, 2016 at 8:28 AM Monty Taylor  wrote:

> On 04/21/2016 10:05 AM, Hayes, Graham wrote:
> > On 21/04/2016 15:39, Michael Krotscheck wrote:
> >> 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.
>
> I'd love to chat about js-openstacklib supporting clouds.yaml files for
> config.
>

I see absolutely ZERO reason why we shouldn't just use an existing
configuration format. Except, well, maybe this: https://xkcd.com/927/

The only existing user of a custom config file we have right now is
ironic-webclient, and its code is really more "how do I load it" rather
than "how do I parse it. Updating it should not be difficult, and as we
don't have a release yet, I don't anticipate any backwards compatibility
issues.

Code, for reference:
http://git.openstack.org/cgit/openstack/ironic-webclient/tree/app/js/modules/openstack/configuration.js

Michael
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Michael Krotscheck]

On Thu, Apr 21, 2016 at 8:10 AM Hayes, Graham  wrote:

> On 21/04/2016 15:39, Michael Krotscheck wrote:
>
> python-openstackclient does require the creation of a new repo for each
> project (unless you are one of the chosen few).
>
> Does this mean you will accept all projects to the library, or just
> selected projects?


In a perfect world, we'd accept everyone. I have some questions about
things like "Does devstack fall down if we try to gate on every service
ever", and how to package things so we can meet both the "gimme everything"
and the "I just want one service" users, however those strike me as
solvable problems.

Michael
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Monty Taylor]

On 04/21/2016 10:05 AM, Hayes, Graham wrote:

On 21/04/2016 15:39, Michael Krotscheck wrote:
[...]

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.


I'd love to chat about js-openstacklib supporting clouds.yaml files for 
config.



python-openstackclient does require the creation of a new repo for each
project (unless you are one of the chosen few).

Does this mean you will accept all projects to the library, or just
selected projects?


Not being a person who is doing the work on this, I would counsel 
accepting all projects to the library. We have done that in shade and 
os-client-config and have not had any problems with it.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] JavaScript RoadMap for OpenStack Newton

[Hayes, Graham]

On 21/04/2016 15:39, Michael Krotscheck wrote:
[...]
> 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.

python-openstackclient does require the creation of a new repo for each
project (unless you are one of the chosen few).

Does this mean you will accept all projects to the library, or just
selected projects?

- Graham


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] JavaScript RoadMap for OpenStack Newton

[Michael Krotscheck]

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.
-