Re: [openstack-dev] [infra] javascript templating library choice for status pages

If all you're looking for is a javascript-based in-browser templating system, then handlebars is a fine choice. I'm not certain on how complex status.html/status.js is, however if you expect it to grow to something more like an application then perhaps looking at angular as a full application frame

Re: [openstack-dev] [infra] javascript templating library choice for status pages

On 01/13/2014 05:05 AM, Sean Dague wrote: Honestly, I've not done enough large scale js projects to know whether we'd consider status.js to be big or not. I just know it's definitely getting too big for += all the html together and doing document.writes. Yes indeed. I guess the real question I

Re: [openstack-dev] [infra] javascript templating library choice for status pages

On 01/13/2014 01:12 PM, Sean Dague wrote: Well, as an expert in the area, particular recommendations would be appreciated. I don't feel like we necessarily need one answer, but it would be nice knock some of the options off the table. I'd say: Start with handlebars, unless you want to lay appl

[openstack-dev] [infra] [storyboard] Goodbye Infra on Launchpad, Hello Infra on StoryBoard

The OpenStack Infrastructure team has successfully migrated all of the openstack-infra project bugs from LaunchPad to StoryBoard. With the exception of openstack-ci bugs tracked by elastic recheck, all bugs, tickets, and work tracked for OpenStack Infrastructure projects must now be submitted an

Re: [openstack-dev] [OpenStack-Infra] [infra] [storyboard] Goodbye Infra on Launchpad, Hello Infra on StoryBoard

Hey there, Brad! The answer to your question depends on who you ask. If you ask me, I will say: "Yes! Feel free to use it all you want!" If you ask Thierry or Jim Blair, their response will be “Oh please no”. Our roadmap right now is as follows: - 1.1.1: Clean up straggling features from our i

Re: [openstack-dev] [Fuel][Nailgun] Web framework

This sounds more like you need to pay off technical debt and clean up your API. Michael On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov wrote: > Hello all, > > I actually tried to use Pecan and even created a couple of PoCs, but > there due to historical reasons of how our API is organized it

Re: [openstack-dev] [All] Who needs a pair of hands to write tons of python code

StoryBoard is always looking for help, and we've got a nice roadmap that you can pull a feature from if you're so inclined: https://wiki.openstack.org/wiki/StoryBoard/Roadmap Come hang out on #storyboard and #openstack-infra :) Michael On Thu Dec 18 2014 at 6:52:28 AM Michael wrote: > Hi all,

[openstack-dev] [infra] [storyboard] Nominating Yolanda Robla for StoryBoard Core

Hello everyone! StoryBoard is the much anticipated successor to Launchpad, and is a component of the Infrastructure Program. The storyboard-core group is intended to be a superset of the infra-core group, with additional reviewers who specialize in the field. Yolanda has been working on StoryBoar

Re: [openstack-dev] [horizon] static files handling, bower/

> > > Solaris is supported by node.js: > > x86 is certainly supported. Always has been. That's not the issue in > question. My point was that SPARC is not supported. > I think Oracle's got enough money to support Node.js on SPARC. > I think Solaris is no longer relevant > > I won't stoop to co

Re: [openstack-dev] [horizon] static files handling, bower/

> > > I think Oracle's got enough money to support Node.js on SPARC. > > How is money relevant here? > Well, normally the argument I've received is "We don't have the time/resources/insert-other-fiscally-motivated-reason to support/work on node". Ergo, money. But then, given Oracle's conduct aroun

Re: [openstack-dev] [horizon] static files handling, bower/

> > Does having the requirements specified in a JSON file, without requiring a > specific build tool to install the files, solve the packaging, testing, and > deployment issue on platforms where node.js isn’t supported natively right > now? > We only support what we test. Unless I missed something

[openstack-dev] [Storyboard] [UX] Atlanta Storyboard UX Summary

I've compiled a list of takeaways from the one-on-one ux sessions that we did at the Atlanta Summit. These comments aren't exhaustive - they're the big items that came up over and over again. If you'd like to review the videos yourself or peruse my notes, please drop me a private line: They're rath

Re: [openstack-dev] [infra] Nominating Nikita Konovalov for storyboard-core

+1, especially since it spreads Storyboard-core to be more-than-HP. Michael ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Updates to Juno blueprint review process

On Sat, Mar 22, 2014 at 3:14 AM, Sean Dague wrote: > > Storyboard remains vaporware. I will be enormously happy when it is not. > You could, oh, I dunno, maybe contribute to the codebase. I am _certain_ that it would make more people happy than calling it vaporware on a public list. Michael

Re: [openstack-dev] [Tuskar][Horizon] Javascript linter

+1 on talking to lawyers. Some more context: JSHint is a fork of JSLint, from which the problem license originates. The team has made a significant effort to strip out and replace JSLint code, however there remains one file which they haven’t tackled yet. There’s a large discussion here, incl

[openstack-dev] [oslo] A special thank you to Davanum (Dims)

Have you ever wanted to thank someone directly, but they're not on IRC so you can't pester them there? Well, dims isn't on IRC right now, so he has to put up with being told he's awesome in public :). Thank you, dims, for helping me out on my work in oslo middleware. You've been calm, helpful, ete

[openstack-dev] [javascript] New linting rules under review

Happy Monday, everyone! We have a few new javascript linting rules under review, since the release of eslint 1.10.1. Also, we have a proposed rule activation and a proposed rule deactivate as well, and all of these would benefit from more reviews. The rules in question are here: https://review.op

Re: [openstack-dev] [cross-project] Cross-project Liaisons

As someone who's surprised more than one team with a patch that apparently came from left field (until I pointed out the x-project spec), I'm totally for this. Michael On Tue, Dec 1, 2015 at 1:45 AM Thierry Carrez wrote: > Mike Perez wrote: > > [...] > > I would like to propose cross-project li

Re: [openstack-dev] [Fuel] Patch size limit

TL/DR: I think you're trying to solve the problem the wrong way. If you're trying to reduce the burden of large patches, I feel the project in question should distribute the burden of reviewing the big ones so one person's not stuck doing them all. That also means you can keep that patch in mental

[openstack-dev] [all] [infra] [java] Seeking java mirror person

Hey everyone! A few months ago, there was a conversation in #openstack-infra, where _someone_ asked for a maven repository mirror to speed up, and stabilize, any java builds. Unfortunately, I can't remember for who that was, and my grep-foo is (apparently) weak. Could the interested party please p

Re: [openstack-dev] [javascript] [infra] NPM Mirrors (IMPORTANT)

ut of > 5. > > 2016-05-11 22:07 GMT+03:00 Michael Krotscheck : > >> Hello everyone! >> >> We've recently added NPM mirrors to our infrastructure, and are about to >> turn them on. Before that happens, however, we'd like to get a sanity check >> fro

[openstack-dev] [javascript] Seeking contributors, js-generator-openstack

Hello everyone! The js-generator-openstack project has been incubated under openstack-infra, and is seeking contributors (and cores). The purpose of the project is as follows: - Help manage common project configuration aspects, such as licenses, gerrit, authors, and more. - Assist in kee

Re: [openstack-dev] [javascript] [infra] NPM Mirrors (IMPORTANT)

/318204/2/check/gate-fuel-ui-npm-run-lint/a390ea7/console.html>). > See https://review.openstack.org/#/c/315119/ for a long list of similar > failures (though almost every gate-fuel-ui-npm-run-lint run now fails). > > What should we do? > > 2016-05-16 16:58 GMT+03:00 Michael Krotschec

Re: [openstack-dev] [javascript] [infra] NPM Mirrors (IMPORTANT)

istry while we investigate. The patch in question is this one: https://review.openstack.org/#/c/318875/ Michael On Thu, May 19, 2016 at 6:21 AM Michael Krotscheck wrote: > Well, my current theory is that npm's default timeout and retries are set > too permissively for cold AFS cache

Re: [openstack-dev] [javascript] Seeking contributors, js-generator-openstack

ld help on this project? > > Is there a project page? > > Or we shall getting started with gerrit review? > > -- > Yujun > > On Wed, May 18, 2016 at 11:45 PM Michael Krotscheck > wrote: > >> Hello everyone! >> >> The js-generator-openstack proje

Re: [openstack-dev] [javascript] Seeking contributors, js-generator-openstack

at's my basic thoughts for the moment. > > -- > Yujun > > On Sat, May 21, 2016 at 1:10 AM Michael Krotscheck > wrote: > >> Hi there! >> >> Well, the first thing we need is other reviewers, which is the fastest >> way to become a core :). The project pag

[openstack-dev] [javascript] Meeting time doodle

ify dates/times in the week when a meeting channel might be open. If you work, consume, and/or want to contribute to JavaScript in OpenStack, please fill out this doodle and let me know when you can attend! http://doodle.com/poll/3hxubef6va5wzpkc Mic

Re: [openstack-dev] [javascript] Meeting time doodle

pt-meeting-agenda Michael On Mon, Jun 6, 2016 at 11:34 AM Michael Krotscheck wrote: > Between fuel, ironic, horizon, storyboard, the app ecosystem group, the > partridges, the pear trees, and the kitchen sinks, there's an awful lot of > JavaScript work happening in OpenStack. En

Re: [openstack-dev] [javascript] Meeting time doodle

cript OpenStack SDK. See you then! Michael On Fri, Jun 10, 2016 at 3:30 PM Michael Krotscheck wrote: > Alright, the first meeting will be on monday, 1500UTC. For the first > meeting we'll just meet in #openstack-javascript, and see which of the > rooms are available at that time. The

Re: [openstack-dev] [all] Proposal: Architecture Working Group

I like the idea in principle, but am bullish on the implementation. For example: we have the API-WG which fulfills part of an Architectural mission, as well as the Cross-Project WG which fulfills a different part. Yet there's no incentive, carrot or stick, that drives adoption of the approved spec

Re: [openstack-dev] [nova] Placement API WSGI code -- let's just use flask

[Non-specific to nova] I generated a list of which frameworks were in use in Mitaka - it's at the top of the blog post I reference below, so you don't have to dig into it too much to get the data. TL/DR: - falcon: 4 projects - custom + routes: 12 projects - pecan: 12 projects - flask: 2 projects

Re: [openstack-dev] [all] Proposal: Architecture Working Group

On Mon, Jun 20, 2016 at 10:59 AM Clint Byrum wrote: > > As you should be, and we all must be. It's not going to happen if we > just dream it. That's kind of the point. Let's write down a design _for > the group that writes down designs_. > If I had any confidence that this group would have a sig

[openstack-dev] JavaScript RoadMap for OpenStack Newton

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

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

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

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

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 less

[openstack-dev] Summit Core Party after Austin

Hey everyone- So, HPE is seeking sponsors to continue the core party. The reasons are varied - internal sponsors have moved to other projects, the Big Tent has drastically increased the # of cores, and the upcoming summit format change creates quite a bit of uncertainty on everything surrounding t

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

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 w

[openstack-dev] [infra] [fuel] [javascript] Supporting ES6

TL/DR: Should we support EcmaScript 6? Discussions I've had on the topic: Vancouver: - Browser support is not yet broad enough, so no- we shouldn't support ES6. - TypeScript is too closely tied to Corporations (tm), not really an open standard. Do not support TypeScript. Austin: - Fuel is using

Re: [openstack-dev] [tc] supporting Go

On Tue, May 3, 2016 at 9:03 AM John Dickinson wrote: > > As a starting point, what would you like to see addressed in the document > I'm drafting? > I'm going through this project with JavaScript right now. Here's some of the things I've had to address: - Common language formatting rules (ensur

Re: [openstack-dev] [horizon] Angular form framework

This feels like a thing for AngularJS projects only, yes? What about projects like Fuel that use React? Michael On Wed, May 4, 2016 at 9:00 PM Tripp, Travis S wrote: > Hello everybody, > > I sent a message about this direclty to a couple of people for their quick > thoughts. It looks like there

[openstack-dev] [javascript] [infra] NPM Mirrors (IMPORTANT)

Hello everyone! We've recently added NPM mirrors to our infrastructure, and are about to turn them on. Before that happens, however, we'd like to get a sanity check from impacted projects to make sure that we don't wedge your gate. If you are in charge of a project that invokes `npm install` duri

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

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 wil

Re: [openstack-dev] [javascript] [infra] NPM Mirrors (IMPORTANT)

I randomly get "error parsing json" for fuel-ui > <https://github.com/openstack/fuel-ui> project: > http://paste.openstack.org/show/496871/. Got such errors 2 times out of > 5. > > 2016-05-11 22:07 GMT+03:00 Michael Krotscheck : > >> Hello everyone! >> &g

[openstack-dev] [javascript] [eslint-config-openstack] ECMAScript 6 / ECMAScript2015 rules.

Fuel has already adopted ES6, and is moving to adopt eslint-config-openstack. To help them, Vitaly's started to propose language style rules for ES6, which are available to review at the below link: https://review.openstack.org/#/q/topic:es6+project:openstack/eslint-config-openstack Please take a

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

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

[openstack-dev] [qa] [eslint-config-openstack] Nominating Beth Elwell to eslint-config-openstack core

extant reviews, and - most importantly - said yes when I asked her. In my book, that's a little crazypants, because she's willing to jump into the linting fight. But hey, everyone's weird in their own spec

Re: [openstack-dev] [api] api working group proposed actions guideline needs input

There's related work going on in ironic - https://review.openstack.org/#/c/224022/ - it proposes a way by which a user may query the transitions (actions) of the underlying FSM: "Get me all the valid actions/transitions". Other comments on the review. Also

Re: [openstack-dev] [api] api working group proposed actions guideline needs input

something, typically to achieve an aim. Personally, I prefer action, because I feel like an action can be composed of multiple tasks and/or transitions. Michael On Mon, Jan 18, 2016 at 8:31 AM michael mccune wrote: > On 01/18/2016 10:05 AM, Michael Krotscheck wrote: > > Also: I like using

[openstack-dev] [infra] Gate is broken

Hey everyone! Since the summit submission deadline is this weekend, we (the infra team) have decided that it's an excellent time to break all of our slaves, so you can go and submit your talks for Austin! That certainly sounds better than "We misconfigured pip.conf and now none of our nodes know

Re: [openstack-dev] [infra] Gate is broken

, Jan 29, 2016 at 10:41 AM Michael Krotscheck > wrote: > >> Hey everyone! >> >> Since the summit submission deadline is this weekend, we (the infra team) >> have decided that it's an excellent time to break all of our slaves, so you >> can go and submit your

[openstack-dev] [javascript] [qa] [eslint-config-openstack] Nominating Cindy Lu for eslint-config-openstack-core

Hey everyone! We've been hard at work getting some solid, shared code style rules in place for our javascript code, and nobody's been more diligent about this than Cindy Lu. Since we've managed to encapsulate our eslint configuration into a separate project (much like hacking), I'd like to nominat

Re: [openstack-dev] [horizon] Minimum Unit Test Coverage

+1 on coverage of any kind. >From a tooling perspective, are you thinking istanbul? >From an infra perspective, are you thinking a separate job, or to have it integrated in with npm run test? FYI- istanbul wraps the unit test invocation, e.g. 'istanbul karma start ./karma.config.js' or something

Re: [openstack-dev] [murano] eslint cleanup

FYI, those rules have been moved into OpenStack under the QA program. I'm currently working on getting npm publish jobs to function so we can release those rules as well. http://git.openstack.org/cgit/openstack/eslint-config-openstack/ Michael On Mon, Jul 27, 2015 at 4:13 PM Kirill Zaitsev wrot

Re: [openstack-dev] [murano] eslint cleanup

smaller than that of horizon — we can impose slightly > stricter rule set, than horizon currently does. But switching to it > completely is something, that I do consider and it is on the roadmap =) > > -- > Kirill Zaitsev > Murano team > Software Engineer > Mirantis, I

Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

Hi there! The most recent version of the CORS middleware (~2.4) no longer requires the use of Oslo.config, and supports pastedeploy. While using oslo.config provides far better features - such as multiple origins - it doesn't prevent you from using it in the paste pipeline. The documentation has b

Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

On Thu, Aug 6, 2015 at 10:08 AM Mehdi Abaakouk wrote: > > Yes, but you can't use oslo.config without hardcode the loading the > middleware to pass the oslo.config object into the application. > Yes, and that is intentional, because the use of global variables of any sort is bad. They're unconstr

Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

o not have appropriate updated documentation by the end of this week, we revert Medhi's patches so that we can unblock the library. In case you're curious, the related patch is here: https://review.openstack.org/#/c/209817/3 Michael Krotscheck On Sun, Aug 9, 2015 at 7:58 PM

Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi middlewares

2:53 AM Julien Danjou wrote: > On Mon, Aug 10 2015, Michael Krotscheck wrote: > > Hi Michael, > > > It appears that the patch related to this discussion were rushed through > > rather quickly, and without appropriate updates to the documentation. The > > documentatio

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

I don't have a horse in the "What should keystone support" race. I do, however, need to point out that any UX argument made about how a UI should work should, at this point, ask the OpenStack UX program for help! Thus I've changed the topic of this email to make sure Piet and the UX teams get a cha

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

On Fri, Aug 14, 2015 at 2:26 PM Adam Young wrote: > On 08/14/2015 12:43 PM, Michael Krotscheck wrote: > > 1- Do users want to page through search results? > Does not matter: in Federation, the User list is not available. > Let's back up here for a sec: A user wants to page

Re: [openstack-dev] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

On Sat, Aug 15, 2015 at 11:02 AM Morgan Fainberg wrote: > Please do not construe a major api change as backwards incompatible. This > pagination was never supported in v3 properly/at all. > Sure, let's argue semantics! That's a useful path forward :). As we move towards tools like FreeIPA Or so

[openstack-dev] [javascript] [eslint-config-openstack]

TL/DR: Do you have an opinion on language style? Of course you do! Come weigh in on javascript style rules! https://review.openstack.org/#/q/status:open+project:openstack/eslint-config-openstack,n,z (List will continually update as we add more patches) The original introducti

Re: [openstack-dev] [all] Something about being a PTL

Beautiful summary, Flavio, especially the points about creating new PTL's. It's the bus-number argument: How many people have to get hit by a bus for the project to falter? It's best to have a backup. Also: Being a PTL is a full-time job. >From working with current and former PTL's, I've noticed

[openstack-dev] [ironic] [javascript] ironic-webclient seeks more reviewers and contributors

Hey everyone! The ironic webclient is finally moving forward again, however we're at that odd stage where most of the ironic team is Awesome Python and Hardware types, and we're lacking reviewers able to keep an eye on our Angular Javascript code. In the interest of not creating an echo chamber ov

[openstack-dev] [Horizon] Horizon Usage Survey Results

Hey everyone! I've compiled some *preliminary* results from the horizon usage survey I'm running. I'll be soliciting more responses during the summit, and if you forgot to contribute, you can still participate. The link is here: http://tinyurl.com/horizon-usage-survey . If you've already participa

Re: [openstack-dev] [Horizon]Informal Pre-summit get together

Do you have any distinguishing features? Like an enormous openstack hat? On Sun, May 17, 2015, 5:06 AM Doug Fish wrote: > I missed the discussion in IRC. I'm going to be there Sunday. If we also > go out Monday I'll probably show up then too > > Doug > > > On May 17, 2015, at 12:40 AM, "Tripp, T

[openstack-dev] Resigning as StoryBoard-Core

Hey everyone! As many of you know, storyboard's been on a bit of a back burner recently, largely because members of the TC have acknowledged that the project was never properly resourced, and therefore have reversed their opinion on whether we should be trying to build our own task tracker that me

[openstack-dev] [Javascript] Summit Conversation Continued

Hey everyone! We had an _excellent_ discussion in Vancouver, but with only 40 minutes to discuss things we didn't reach consensus on many topics that we really needed to hash out. In order to make sure that the rest of this list is addressed, I'm including a summary of the discussion here and will

[openstack-dev] [cors] Last Call for Comments

Hey everyone! The CORS spec has been under review for about a month now, and the TC has put it on the agenda next week for final approval. I plan on doing one final revision of the document - if it is warranted - so get your comments in now! https://review.openstack.org/#/c/179866/ Michael _

[openstack-dev] [javascript] Linters

Right now, there are several JS linters in use in OpenStack: JSHint, JSCS, and Eslint. I really would like to only use one of them, so that I can figure out how to sanely share the configuration between projects. Can all those who have a strong opinion please stand up and state their opinions? Mi

Re: [openstack-dev] [javascript] Linters

On Mon, Jun 8, 2015 at 1:59 AM Matthias Runge wrote: > > jshint: still non-free license [1] > Yep! Ergo, we can't really use it. > eslint seems to require to sign a CLA, if we come across an issue and > were going to fix that. > So does the python foundation, I'm not really worried about it.

Re: [openstack-dev] [javascript] Linters

;m sure JSMin will have a strong following :) Michael On Mon, Jun 8, 2015 at 9:02 PM gustavo panizzo (gfa) wrote: > > > On 2015-06-06 03:26, Michael Krotscheck wrote: > > Right now, there are several JS linters in use in OpenStack: JSHint, > > JSCS, and Eslint. I really

Re: [openstack-dev] [javascript] Linters

[2] https://github.com/johnpapa/angular-styleguide/issues/194 > [3] https://github.com/openstack/horizon/blob/master/.jscsrc > [4] https://github.com/openstack/horizon/blob/master/.jshintrc > > On 6/8/15, 9:59 PM, "gustavo panizzo (gfa)" wrote: > > > > > > >

Re: [openstack-dev] [javascript] Linters

there is a good case for a framework-agnostic API library for [Insert API Here]. So, let's just start with the Google Style Guidelines, and let projects use plugins (like eslint-angular) to support additional project guidelines. Michael On Tue, Jun 9, 2015 at 9:01 AM Michael Krotscheck wro

Re: [openstack-dev] [javascript] Linters

On Tue, Jun 9, 2015 at 3:37 PM Robert Collins wrote: > On 10 June 2015 at 04:01, Michael Krotscheck wrote: > > Well, it looks like everyone has disqualified jslint and jshint, so let's > > just make a decision there and remove them from the running. Unless I > hear a &

[openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html The question at hand is "What will be OpenStack's javascript equivalent of flake8". I'm going to consider the nee

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

ormer is > the case, then the decision is made for us. > > Rob > > > > From: Michael Krotscheck > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, 16 June 2015 00:36 > To:

Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting

On Tue, Jun 16, 2015 at 10:22 AM Tripp, Travis S wrote: > I think agreeing on rules is the bigger problem here and I don’t think all > the projects should have to agree on rules. I believe we agree there, mostly. I personally feel there is some benefit to setting some rules, likely published as

Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic‏

Hey there! Yes, we are duplicating effort. I've spent quite a bit of effort over the past few months landing features inside openstack that will make it possible for a JavaScript client to be imported to horizon as a dependency. This includes CORS, configuration, caching, infra tooling, etc, with

Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic

the new Magnum and Ironic UI, personally, I’d prefer > to use the current framework and move to Angular Dashboard when it’s > mature. > > > > And after a quick look at your JS project, I think it’s totally a > standalone UI not based on Horizon Angular Dashboard (correct me

Re: [openstack-dev] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?

Having _just_ done this, a couple of suggestions. - If the middleware is NOT optional - that is, it provides some kind of a fundamental component or specification of the API, like ETag caching, CORS, or DB Session management - then the middleware should be added during the app initialization routi

Re: [openstack-dev] [Nova] The unbearable lightness of specs

TL/DR: I think the original poster is simply frustrated with how long it takes to go from spec to landed feature. How about we stop talking about whether specs are good or not (I think everyone agrees that they are beneficial), and try to actually make the process better? And by make it better, I

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

We (that is, the cores, contributors, and consumers that I've been collaborating with over the past year on this) came to the consensus that leaving the cors middleware as generic & configurable as possible was preferable, and that an openstack-specific version that automatically initializes itself

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 9:41 AM Doug Hellmann wrote: > > The next release of oslo.config will have this. > https://review.openstack.org/#/c/278604/ http://stjent.pinnaclecart.com/images/products/preview/55008.jpg Michael _

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 2:29 PM Doug Hellmann wrote: > > That change only affects sample files and documentation. It has been > possible for applications to override config defaults for ages. Were we > blocked on making effective use of that because of the doc issue for a > long time? Sample fi

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Clarifying: On Thu, Feb 18, 2016 at 2:32 AM Sean Dague wrote: > Ok, to make sure we all ended up on the same page at the end of this > discussion, this is what I think I heard. > > 1) oslo.config is about to release with a feature that will make adding > config to paste.ini not needed (i.e. > ht

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 9:07 AM Doug Hellmann wrote: > > If the deployer is only ever supposed to set the value to the default, > why do we let them change it at all? Why isn't this just something the > app sets? There was a specific request from the ironic team to not have headers be prescribe

Re: [openstack-dev] [all] A proposal to separate the design summit

On Tue, Feb 23, 2016 at 3:40 AM Chris Dent wrote: > > However, it makes me sad to see the continued trend of limiting > in-person gatherings. They are useful as a way of keeping people > aligned with similar goals and approaches to reaching those goals. > Yes, it is expensive, but it would be nic

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 11:42 AM Adam Young wrote: > If the deployer does and all-in-one, and all services are on port 443, > CORS is not an issue. > I feel that this is based on the assumption that a cloud will only ever have one GUI, which I already know is not the case. From the survey I ran

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 9:58 AM Sean Dague wrote: > Here is the future we're going to have. > The future is only going to happen if help materializes. So far, we still need updated patches on all 22 projects, and these will need to land in time for the mitaka release. I can commit to doing about

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Thu, Feb 18, 2016 at 10:18 AM Morgan Fainberg wrote: > > I am against "option 1". This could be a case where we classify it as a > release blocking bug for Mitaka final (is that reasonable to have m3 with > the current scenario and final to be fixed?), which opens the timeline a > bit rather t

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

it until Tuesday for everyone to weigh in on the implementation. After that I will start converting the other projects over as best I can and as I have time. Who is willing to help? Michael On Thu, Feb 25, 2016 at 9:05 AM Michael Krotscheck wrote: > On Thu, Feb 18, 2016 at 10:18 AM Morgan Fa

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

sed by projects that have not adopted oslo.config's generate-config. I hope those teams will be able to find their own paths forward. Who is willing to help? Michael On Fri, Feb 26, 2016 at 6:09 AM Michael Krotscheck wrote: > Alright, I have a first sample patch up for what was discusse

Re: [openstack-dev] [Openstack-operators] OpenStack Contributor Awards

On Tue, Feb 16, 2016 at 2:48 AM Tom Fifield wrote: > > in the meantime, let's use this thread to discuss the fun part: goodies. > What do you think we should lavish award winners with? Soft toys? > Perpetual trophies? baseball caps ? > "I made a substantial contribution to OpenStack, and all I g

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

time. > > Additionally, I will not be able to address issues caused by projects that > have not adopted oslo.config's generate-config. I hope those teams will be > able to find their own paths forward. > > Who is willing to help? > > Michael > > On Fri, Feb 26,

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor wrote: > > > SOLUTION 4: vendor the javascript > > > > Heh. > > Heh indeed. > > SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript. > +1. Let's move the codebase forward, instead of continuing to build hacky workarounds for poor pa

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten tohorizon-core

+1. Another vote in favor of ditching django altogether is good by me :) On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran wrote: > Big +1 from me, thanks for all the hard work Diana! > > > - Original message - > From: David Lyle > To: OpenStack Development Mailing List > Cc: > Subject: [ope

Re: [openstack-dev] [Horizon] Javascript linting and documentation

+1 to what Rob said. I guess I don't see what problems is being solved by turning the rule off, and I also don't see the harm in having more check. It does generate a lot of warnings, but invoking `npm run lint -- --quiet` gets rid of those. Also, from my experience, sphinx-based doc builds are no

Re: [openstack-dev] [Horizon] Javascript linting and documentation

On Wed, Mar 9, 2016 at 12:45 PM Tripp, Travis S wrote: > The problem is that the warnings are so great that is really hard to read. > If all the warnings were fixed - I know Matt Borland's working on that - would we be having this conversation? Michael __

Re: [openstack-dev] [Horizon] Javascript linting and documentation

On Wed, Mar 9, 2016 at 4:15 PM Richard Jones wrote: > > We already have a "lintq" npm task that does this, which most of us use. > The problem is that we then ignore all the legitimate code linting warnings. > I think we both agree that some form of jsdoc linting is useful, yes? You'd prefer for

  1   2   >