Re: [openstack-dev] [api] [devstack] [ocata] Consistent Endpoint Discovery

nd there's no indication of why that is. Is it fragile? Would removing the version from the nova URI in the catalog entry itself cause other services to fail? One would think not, but if that's the case why are the versions declared explicitly in the first place? Michael Krotscheck On Thu,

[openstack-dev] [javascript] [fuel-ui] Is ReactJS OSI Compliant?

Preface: IANAL (I-am-not-a-lawyer). ReactJS claims to be BSD licensed. However, it has a non-BSD patent rider with a very aggressive "Strong Retaliation Clause", meaning that if there's ever a patent dispute between [React Project] and Facebook, the patents are revoked. This might be fine. It mig

[openstack-dev] [api] [devstack] [ocata] Consistent Endpoint Discovery

Hey everyone - I have a little bit of a UX request for our API developers. For the last week or so, I've been working on building version negotiation logic for an OpenStack SDK. The process is pretty simple: 1- Read clouds.yaml for the keystone URL. 2- Query keystone for the service catalog. 3- I

Re: [openstack-dev] [tc] persistently single-vendor projects

FYI- I'm totally in favor of eviction. But... On Mon, Aug 1, 2016 at 8:42 AM Doug Hellmann wrote: > > I'm interested in hearing other reasons that we should keep these > sorts of projects, though. I'm not yet ready to propose the change > to the policy myself. ...if the social consequences res

Re: [openstack-dev] Mascot/logo for your project

As an aside, I'd be happy to create a project that converts any SVG logo files into a font, for convenient usage in UI projects. Here's an example of what that might look like: http://fontawesome.io/icons/#brand Michael

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

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

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

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

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

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

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

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

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

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

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

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

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

[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] [all][oslo] config generator default overrides and namespaces

On Mon, Mar 14, 2016 at 7:29 AM Markus Zoeller wrote: > > Thanks Doug and Robert for catching this and providing the fixes! > > Regarding potential backports: Do you have information if this is > something which came up in a specific version in "oslo.config"? > Oslo config's default overrides we

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

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

+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] 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] 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] [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] [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

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

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

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

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

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

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

[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

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

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

[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

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

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

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

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

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

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

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

[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] 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 &

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

[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

;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

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.

[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

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

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] [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] xstatic-angular-fileupload with no license

If only JavaScript had a package manager that would take care of all this... ;) Michael On Mon, May 11, 2015 at 12:45 PM Thomas Goirand wrote: > Hi, > > We had the issue with lrdragndrop, and angular-bootstrap. Now, we're > having the same issue again with this angular-fileupload. So I'll say i

[openstack-dev] [Security] CORS Documentation

Hey everyone! I'm currently managing an OpenStack specification to introduce CORS support to Liberty. The specification is here for your review: https://review.openstack.org/#/c/179866/1 Seeing as activating CORS has security implications, I strongly feel that the documentation should reflect th

Re: [openstack-dev] [oslo] Adding Joshua Harlow to oslo-core

++! On Tue, May 5, 2015 at 8:02 AM Davanum Srinivas wrote: > +1 from me!! > > -- dims > > On Tue, May 5, 2015 at 10:47 AM, Julien Danjou wrote: > > Hi fellows, > > > > I'd like to propose that we add Joshua Harlow to oslo-core. He is > > already maintaining some of the Oslo libraries (taskflow,

Re: [openstack-dev] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R

On Tue, May 5, 2015 at 1:32 AM Matthias Runge wrote: > On 05/05/15 04:31, Ian Cordasco wrote: > > > Even so, Horizon is deployed in many places, and given the reliability of > > system packages, it’s increasingly deployed from source. > > Ok, I'll bite. > > You surely have a source for your state

[openstack-dev] [horizon] Karma Tests in Horizon

you on IRC, but it appears you missed the notification in backscroll. For reference, here's the patch under consideration: https://review.openstack.org/#/c/168152/ Michael Krotscheck __ OpenStack Development Mailing

Re: [openstack-dev] [all] Question for the TC candidates

Hey there Chris! On Thu, Apr 23, 2015 at 9:17 AM Chris Dent wrote: > What can and should the TC at large, and you specifically, do to > ensure quality improves for the developers, end-users and operators > of OpenStack as a full system, both as a project being developed and > a product being use

[openstack-dev] TC Candidacy

ently landed supporting technologies (such as CORS) that will greatly assist in unleashing downstream UI developers post-liberty, and am trying to teach Infra how to publish javascript libraries much like it does for python. Also, I've got 15 years of expe

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

__ > From: Ryan Brown [rybr...@redhat.com] > Sent: Monday, April 20, 2015 11:38 AM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?) > > On 04/20/2015 02:22 PM, Michael Krotscheck wrote: > > What'

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

What's the difference between openstack/zaqar and stackforge/cue? Looking at the projects, it seems like zaqar is a ground-up implementation of a queueing system, while cue is a provisioning api for queuing systems that could include zaqar, but could also include rabbit, zmq, etc... If my understa

  1   2   >