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

[Michael Krotscheck]

Hey there, Goutham, thanks for replying!

I don't dispute that the services are properly returning a list of
supported versions, if you request the root resource. So far, that works
wonderfully.

I'm speaking of the resource endpoint that an API client is given when it
queries the keystone service catalog. We have a dump of the devstack output
in our testing data here ->
http://git.openstack.org/cgit/openstack/js-openstack-lib/tree/test/unit/helpers/data/keystone.js#n392

As you can see, some services give us tenant ID, some give us version, some
give us the root resource - and 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, Sep 8, 2016 at 10:15 AM Ravi, Goutham 
wrote:

> Hi Michael,
>
>
>
> We discussed this at the API-WG meeting today (occurs at 16:00 UTC on
> Thursdays, #openstack-meeting-3). A point regarding the ‘/’ endpoint and
> the versions response is made in the microversions guideline [1]
> <https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery>.
> I was testing the services you mentioned (+ manila), the results from my
> environment are here [2]. <http://paste.openstack.org/show/569282/> Looks
> like none of the services require authentication to make a request to the
> bare endpoint. What am I missing? One thing to note is that you included
> the tenant ID and /v3 in case of cinder; why is that?
>
>
>
> When instantiating a client and performing version negotiation, you may
> have auth details; but looks like we have some consistency among all of the
> projects you mentioned to not require auth. Maybe we can add this to [1].
>
>
>
> Thanks,
>
> Goutham
>
>
>
> [1]
> https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery
>
> [2] http://paste.openstack.org/show/569282/
>
>
>
>
>
> *From: *Michael Krotscheck 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Tuesday, August 30, 2016 at 1:11 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *[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- Instantiate service instances for each discovered service.
>
> 4- Perform version negotiation on each service.
>
>
>
> The problem: the service endpoints registered in the catalog all behave
> just a little bit differently, which makes building consistent version
> negotiation a royal PITA. I've annotated the various behaviors from a
> default devstack configuration here:
> http://paste.openstack.org/show/564863/.
>
>
>
> In a perfect world, every endpoint would return the same type of resource
> - most likely the versions resource as described in the API WG
> Microversions spec. It would also be nice if version negotiation can happen
> without requiring authentication, the easiest path to which would be
> supporting the 'max_version' and 'min_version' fields in the root versions
> resource.
>
>
>
> Sadly, this is my last week before I'm no longer paid to contribute to the
> OpenStack community, so I can't take on the responsibility of proposing
> something of this magnitude as an Ocata goal with only my own free time to
> offer. Is there anyone willing to help push this forward?
>
>
>
> 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
>
__
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] [fuel-ui] Is ReactJS OSI Compliant?

[Michael Krotscheck]

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 might not. If possible, I'd like one of the
foundation lawyers to weigh in on this, as one of our projects (Fuel-UI) is
using it.

Some discussion on the matter:
https://news.ycombinator.com/item?id=12108158

Our own guidelines.
http://governance.openstack.org/reference/licensing.html

Historically, OpenStack has avoided projects that make custom modifications
to a license (see the do-no-evil license on JSLint/JSHint).

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

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

[Michael Krotscheck]

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- Instantiate service instances for each discovered service.
4- Perform version negotiation on each service.

The problem: the service endpoints registered in the catalog all behave
just a little bit differently, which makes building consistent version
negotiation a royal PITA. I've annotated the various behaviors from a
default devstack configuration here: http://paste.openstack.org/show/564863/
.

In a perfect world, every endpoint would return the same type of resource -
most likely the versions resource as described in the API WG Microversions
spec. It would also be nice if version negotiation can happen without
requiring authentication, the easiest path to which would be supporting the
'max_version' and 'min_version' fields in the root versions resource.

Sadly, this is my last week before I'm no longer paid to contribute to the
OpenStack community, so I can't take on the responsibility of proposing
something of this magnitude as an Ocata goal with only my own free time to
offer. Is there anyone willing to help push this forward?

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] [tc] persistently single-vendor projects

[Michael Krotscheck]

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 result in that entire team's development
staff effectively exiting OpenStack altogether? This in particular is
pertinent to myself - if Fuel is evicted from the big tent, then it's very
likely that the JavaScript SDK collaboration (which includes several
Fuel-UI developers and has _finally_ taken off) will grind to a halt.

There's a halo effect to having a project under the big tent - contributors
are already familiar with infra and procedure, and thus the barriers to
cross-project bugfixes are way lower. Perhaps (using Fuel as an example)
the "should this be in the big tent" metric is based on how many
contributors contribute _only_ to Fuel, as opposed to
Fuel-and-other-projects.

As a countersuggestion - perhaps the solution to increasing project
diversity is to reduce barriers to cross-project contributions. If the
learning curve of project-shifting was reduced (by agreeing on common web
frameworks, etc), it'd certainly make cross-project bug fixes way easier.

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] Mascot/logo for your project

[Michael Krotscheck]

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 Krotscheck
__
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] [all] Proposal: Architecture Working Group

[Michael Krotscheck]

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 significant impact on
making OpenStack more consistent, easy to work on, and easier to build apps
against, I'd be happy to help out.

The only thing that would give me that confidence is if the WG charter had
a TC-enforced section of: "If you do not implement this *thing* within two
cycles, your project will get kicked out of OpenStack".

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] [nova] Placement API WSGI code -- let's just use flask

[Michael Krotscheck]

[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
- web.py: 1 project

With that in mind, I caution everyone not to surrender to the bandwagon
logical fallacy. "That's what we've always done" or "That's what most
people are doing" isn't actually an argument pro or con, it's merely
supporting the status quo because doing anything else would be hard (tm).

I think we can all agree on the following:
- Consistency is good. We need to pick one approach.
- Offloading support overhead onto a common codebase is better.

As for what the choice should be, this should be a thing the Architecture
WG makes a recommendation on, and with endorsement from the TC, would
actually be worthwhile for other projects to migrate to.

https://krotscheck.net/2016/03/25/we-need-an-consistent-openstack.html

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] [all] Proposal: Architecture Working Group

[Michael Krotscheck]

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 specs, other than "Well if you want to do the work, have fun". In
several cases, I've run into the excuses of "That's Hard/That breaks
backwards compatibility/That's not profitable/I'm not paid to do that".

What's going to prevent [Insert Project Here] from coming along and saying
"Oh, well, we don't like those decisions, so are going to ignore them."
What provides the incentive for a project to adopt these recommendations?

Michael

On Mon, Jun 20, 2016 at 2:25 AM Denis Makogon  wrote:

> Hello Clint.
>
> I'd like to take part as well, so count me in.
>
> Kind regards,
> Denys Makogon
>
>
> 2016-06-20 10:23 GMT+03:00 Ghe Rivero :
>
>> Hi all!
>> I really like the idea of the group, so count me in!
>>
>> Ghe Rivero
>>
>> Quoting Clint Byrum (2016-06-17 23:52:43)
>> > ar·chi·tec·ture
>> > ˈärkəˌtek(t)SHər/
>> > noun
>> > noun: architecture
>> >
>> > 1.
>> >
>> > the art or practice of designing and constructing buildings.
>> >
>> > synonyms:building design, building style, planning, building,
>> construction;
>> >
>> > formalarchitectonics
>> >
>> > "modern architecture"
>> >
>> > the style in which a building is designed or constructed,
>> especially with regard to a specific period, place, or culture.
>> >
>> > plural noun: architectures
>> >
>> > "Victorian architecture"
>> >
>> > 2.
>> >
>> > the complex or carefully designed structure of something.
>> >
>> > "the chemical architecture of the human brain"
>> >
>> > the conceptual structure and logical organization of a computer or
>> computer-based system.
>> >
>> > "a client/server architecture"
>> >
>> > synonyms:structure, construction, organization, layout, design,
>> build, anatomy, makeup;
>> >
>> > informalsetup
>> >
>> > "the architecture of a computer system"
>> >
>> >
>> > Introduction
>> > =
>> >
>> > OpenStack is a big system. We have debated what it actually is [1],
>> > and there are even t-shirts to poke fun at the fact that we don't have
>> > good answers.
>> >
>> > But this isn't what any of us wants. We'd like to be able to point
>> > at something and proudly tell people "This is what we designed and
>> > implemented."
>> >
>> > And for each individual project, that is a possibility. Neutron can
>> > tell you they designed how their agents and drivers work. Nova can
>> > tell you that they designed the way conductors handle communication
>> > with API nodes and compute nodes. But when we start talking about how
>> > they interact with each other, it's clearly just a coincidental mash of
>> > de-facto standards and specs that don't help anyone make decisions when
>> > refactoring or adding on to the system.
>> >
>> > Oslo and cross-project initiatives have brought some peace and order
>> > to the implementation and engineering processes, but not to the design
>> > process. New ideas still start largely in the project where they are
>> > needed most, and often conflict with similar decisions and ideas in
>> other
>> > projects [dlm, taskflow, tooz, service discovery, state machines, glance
>> > tasks, messaging patterns, database patterns, etc. etc.]. Often times
>> this
>> > creates a log jam where none of the projects adopt a solution that would
>> > align with others. Most of the time when things finally come to a head
>> > these things get done in a piecemeal fashion, where it's half done here,
>> > 1/3 over there, 1/4 there, and 3/4 over there..., which to the outside
>> > looks like  chaos, because that's precisely what it is.
>> >
>> > And this isn't always a technical design problem. OpenStack, for
>> instance,
>> > isn't really a micro service architecture. Of course, it might look like
>> > that in diagrams [2], but we all know it really isn't. The compute node
>> is
>> > home to agents for every single concern, and the API interactions
>> between
>> > the services is too tightly woven to consider many of them functional
>> > without the same lockstep version of other services together. A game to
>> > play is ask yourself what would happen if a service was isolated on its
>> > own island, how functional would its API be, if at all. Is this
>> something
>> > that we want? No. But there doesn't seem to be a place where we can go
>> > to actually design, discuss, debate, and ratify changes that would help
>> > us get to the point of gathering the necessary will and capability to
>> > enact these efforts.
>> >
>> > Maybe nova-compute should be isolated from nova, with an API that
>> > nova, cinder and neutron talk to. Maybe we should make the scheduler
>> > cross-project aware and capable of scheduling more than just nova
>> > instances. Maybe we should have experime

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

[Michael Krotscheck]

Productive meeting this morning, everyone. As agreed, we'll be meeting
weekly at 1400UTC. I had to change the meeting time from Monday to
Wednesday though, because twice-a-month there were not meeting channels
available. Since Wednesday at 1400UTC was also available in the former
doodle poll, I chose that date. If this doesn't work for you, please
comment to that effect on this code review:

https://review.openstack.org/#/c/329120/

Next meeting will be next week, Wednesday at 1400UTC, in
#openstack-meeting, and we'll be kicking it off with a design discussion
for the JavaScript 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 agenda is here, go ahead and add
> anything you'd think is pertinent:
>
> https://etherpad.openstack.org/p/javascript-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. Enough so that it's a good idea to
>> actually start having regular about it.
>>
>> I've tried to identify 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
>>
>> Michael Krotscheck
>>
>
__
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] Meeting time doodle

[Michael Krotscheck]

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 agenda is here, go ahead and add
anything you'd think is pertinent:

https://etherpad.openstack.org/p/javascript-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. Enough so that it's a good idea to
> actually start having regular about it.
>
> I've tried to identify 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
>
> Michael Krotscheck
>
__
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] Meeting time doodle

[Michael Krotscheck]

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. Enough so that it's a good idea to
actually start having regular about it.

I've tried to identify 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

Michael Krotscheck
__
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] Seeking contributors, js-generator-openstack

[Michael Krotscheck]

Good idea. Since we've already got a storyboard project, let's start there.

Michael

On Fri, May 20, 2016 at 4:02 PM Zhang Yujun 
wrote:

> Hi, Michael
>
> As you are no longer alone now, we'd better to put things in your head
> onto documents so that everybody who wish to contribute will know where to
> go.
>
> Besides the technical roadmap, I think we shall need a space for issue
> tracking and proposal discussion. After we make the project more open to
> the community, it won't be long that more developers join this project.
>
> That'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 page right now is the README.md
>> file in the project itself. The main reason for this is that the target
>> audience - javascript engineers - usually find that first via NPM. Most of
>> the Todo items there have already been done, actually, so the next step
>> would be to really identify what this project needs to accomplish, group it
>> into major categories, and start working on it. Off the top of my head,
>> here's a list:
>>
>>
>>1. Dependency synchronization: Keep a list of semver
>>global-dependencies.json at the root of the project, and update a 
>> project's
>>dependencies if the versions are out of sync.
>>2. Eslint invocation. Infra's Common Testing Interface states that
>>all javascript projects must support 'npm run lint', using
>>eslint-config-openstack. The generator should add/update this to any
>>project it's run in.
>>3. nsp invocation. Not strictly necessary, but a postinstall scan of
>>the project for publicly known vulnerabilities is always a good thing.
>>
>> After these pieces, the next step becomes more complicated, as we need to
>> choose whether the user is creating a web application, or a node
>> application. This then allows us to switch out which test harness and
>> runner we're using, so that the `npm test` command can be consistent. Once
>> this lands, we can start talking about project src/dist directories, how to
>> best use gulp in each project type, and actual project templates :).
>>
>> Is there something in particular you'd like to work on?
>>
>> Michael
>>
>>
>> On Thu, May 19, 2016 at 12:39 AM Zhang Yujun 
>> wrote:
>>
>>> Hi, Michael,
>>>
>>> I have several project experience in JavaScript and please let me know
>>> how I could 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 <
>>> krotsch...@gmail.com> wrote:
>>>
>>>> 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 keeping dependencies up-to-date and synchronized across
>>>>javascript projects (JS equivalent of global requirements).
>>>>- Provide all the necessary hooks for OpenStack's JavaScript Common
>>>>Testing Interface.
>>>>- Suggest common tools to use for tasks such as linting, unit
>>>>testing, functional testing, and more.
>>>>- (Newton Stretch) Provide a quick way of bootstrapping a new
>>>>CORS-consuming OpenStack UI.
>>>>
>>>> I'm looking for help- firstly, because right now I'm the only person
>>>> who's willing to review JavaScript amongst the various infra cores, and I'd
>>>> really like more eyeballs on this project. Secondly, because I know that
>>>> I'm not the only person who has opinions about how we should be doing
>>>> JavaScript things.
>>>>
>>>> Come on over to
>>>> https://review.openstack.org/#/q/project:openstack-infra/js-generator-openstack+status:open
>>>>  and
>>>> help me out, would ya? If you've got questions, I'm active in the
>>>> #openstack-javascript channel.
>&

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

[Michael Krotscheck]

Hi there!

Well, the first thing we need is other reviewers, which is the fastest way
to become a core :). The project page right now is the README.md file in
the project itself. The main reason for this is that the target audience -
javascript engineers - usually find that first via NPM. Most of the Todo
items there have already been done, actually, so the next step would be to
really identify what this project needs to accomplish, group it into major
categories, and start working on it. Off the top of my head, here's a list:


   1. Dependency synchronization: Keep a list of semver
   global-dependencies.json at the root of the project, and update a project's
   dependencies if the versions are out of sync.
   2. Eslint invocation. Infra's Common Testing Interface states that all
   javascript projects must support 'npm run lint', using
   eslint-config-openstack. The generator should add/update this to any
   project it's run in.
   3. nsp invocation. Not strictly necessary, but a postinstall scan of the
   project for publicly known vulnerabilities is always a good thing.

After these pieces, the next step becomes more complicated, as we need to
choose whether the user is creating a web application, or a node
application. This then allows us to switch out which test harness and
runner we're using, so that the `npm test` command can be consistent. Once
this lands, we can start talking about project src/dist directories, how to
best use gulp in each project type, and actual project templates :).

Is there something in particular you'd like to work on?

Michael


On Thu, May 19, 2016 at 12:39 AM Zhang Yujun 
wrote:

> Hi, Michael,
>
> I have several project experience in JavaScript and please let me know how
> I could 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 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 keeping dependencies up-to-date and synchronized across
>>javascript projects (JS equivalent of global requirements).
>>- Provide all the necessary hooks for OpenStack's JavaScript Common
>>Testing Interface.
>>- Suggest common tools to use for tasks such as linting, unit
>>testing, functional testing, and more.
>>- (Newton Stretch) Provide a quick way of bootstrapping a new
>>CORS-consuming OpenStack UI.
>>
>> I'm looking for help- firstly, because right now I'm the only person
>> who's willing to review JavaScript amongst the various infra cores, and I'd
>> really like more eyeballs on this project. Secondly, because I know that
>> I'm not the only person who has opinions about how we should be doing
>> JavaScript things.
>>
>> Come on over to
>> https://review.openstack.org/#/q/project:openstack-infra/js-generator-openstack+status:open
>>  and
>> help me out, would ya? If you've got questions, I'm active in the
>> #openstack-javascript channel.
>>
>> 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
>>
> __
> 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 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] [infra] NPM Mirrors (IMPORTANT)

[Michael Krotscheck]

We appear to be encountering an intermittent server issue - that is to say,
some of the time the npm request for either a json file or a tarball will
terminate prematurely, which we believe is due to a request timeout at the
client side. We'll be temporarily switching back to the public registry
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 caches (2 retries, 10 second mintimeout, 1
> minute maxtimeout). We _just_ landed this patch (
> https://review.openstack.org/#/c/318279/) which increases both the # of
> retries and the timeouts, which would address that issue.
>
> We've got two choices- revert the mirror configuration, or wait for this
> patch to be propagated to our slaves. Both of them will require a dib run,
> which happens once a day, so neither fix will be available until tomorrow.
> Frankly, I'd prefer to move forward than back, so I'm going to check in the
> infra channel to see if we can trigger that run manually.
>
> Michael
>
> On Thu, May 19, 2016 at 5:41 AM Vitaly Kramskikh 
> wrote:
>
>> It seems this issue started to affect us on OpenStack infra about 13
>> hours ago. The main 2 reasons of failing tests are "Unexpected end of
>> input"/"registry error parsing json" (example
>> <http://logs.openstack.org/19/315119/5/check/gate-fuel-ui-npm-run-lint/2622df4/console.html>)
>> and "Error: socket hang up" (example
>> <http://logs.openstack.org/04/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 Krotscheck :
>>
>>> Hey there, Vitaly-
>>>
>>> I suspect that the issue you're encountering is actually a
>>> cross-atlantic lag, combined with the Mirror's AFS cache warming up. As of
>>> this morning, fuel-ui seems to be installing fine from dfw.rax, though
>>> you may run into similar issues with other mirrors until those caches warm
>>> up.
>>>
>>> Michael
>>>
>>> On Thu, May 12, 2016 at 4:10 AM Vitaly Kramskikh <
>>> vkramsk...@mirantis.com> wrote:
>>>
>>>> Hi, Michael,
>>>>
>>>> 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!
>>>>>
>>>>> 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` during
>>>>> any of its gate jobs, then please invoke the following commands at your
>>>>> project root.
>>>>>
>>>>> echo "registry=http://mirror.dfw.rax.openstack.org/npm/"; >> .npmrc
>>>>> rm -rf ./node_modules/
>>>>> rm -rf ~/.npm/
>>>>> npm install
>>>>>
>>>>> If you encounter an error, put it in paste.openstack.org and reply to
>>>>> this thread. If not, great! Delete the .npmrc file and go on your merry 
>>>>> way.
>>>>>
>>>>> Have a great day!
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Vitaly Kramskikh,
>>>> Fuel UI Tech Lead,
>>>> Mirantis, Inc.
>>>>
>>>> ___

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

[Michael Krotscheck]

Well, my current theory is that npm's default timeout and retries are set
too permissively for cold AFS caches (2 retries, 10 second mintimeout, 1
minute maxtimeout). We _just_ landed this patch (
https://review.openstack.org/#/c/318279/) which increases both the # of
retries and the timeouts, which would address that issue.

We've got two choices- revert the mirror configuration, or wait for this
patch to be propagated to our slaves. Both of them will require a dib run,
which happens once a day, so neither fix will be available until tomorrow.
Frankly, I'd prefer to move forward than back, so I'm going to check in the
infra channel to see if we can trigger that run manually.

Michael

On Thu, May 19, 2016 at 5:41 AM Vitaly Kramskikh 
wrote:

> It seems this issue started to affect us on OpenStack infra about 13 hours
> ago. The main 2 reasons of failing tests are "Unexpected end of
> input"/"registry error parsing json" (example
> <http://logs.openstack.org/19/315119/5/check/gate-fuel-ui-npm-run-lint/2622df4/console.html>)
> and "Error: socket hang up" (example
> <http://logs.openstack.org/04/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 Krotscheck :
>
>> Hey there, Vitaly-
>>
>> I suspect that the issue you're encountering is actually a cross-atlantic
>> lag, combined with the Mirror's AFS cache warming up. As of this morning,
>> fuel-ui seems to be installing fine from dfw.rax, though you may run
>> into similar issues with other mirrors until those caches warm up.
>>
>> Michael
>>
>> On Thu, May 12, 2016 at 4:10 AM Vitaly Kramskikh 
>> wrote:
>>
>>> Hi, Michael,
>>>
>>> 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!
>>>>
>>>> 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` during any
>>>> of its gate jobs, then please invoke the following commands at your project
>>>> root.
>>>>
>>>> echo "registry=http://mirror.dfw.rax.openstack.org/npm/"; >> .npmrc
>>>> rm -rf ./node_modules/
>>>> rm -rf ~/.npm/
>>>> npm install
>>>>
>>>> If you encounter an error, put it in paste.openstack.org and reply to
>>>> this thread. If not, great! Delete the .npmrc file and go on your merry 
>>>> way.
>>>>
>>>> Have a great day!
>>>>
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Vitaly Kramskikh,
>>> Fuel UI Tech Lead,
>>> Mirantis, Inc.
>>>
>>> __
>>> 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 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
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
> __
> 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 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] Seeking contributors, js-generator-openstack

[Michael Krotscheck]

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 keeping dependencies up-to-date and synchronized across
   javascript projects (JS equivalent of global requirements).
   - Provide all the necessary hooks for OpenStack's JavaScript Common
   Testing Interface.
   - Suggest common tools to use for tasks such as linting, unit testing,
   functional testing, and more.
   - (Newton Stretch) Provide a quick way of bootstrapping a new
   CORS-consuming OpenStack UI.

I'm looking for help- firstly, because right now I'm the only person who's
willing to review JavaScript amongst the various infra cores, and I'd
really like more eyeballs on this project. Secondly, because I know that
I'm not the only person who has opinions about how we should be doing
JavaScript things.

Come on over to
https://review.openstack.org/#/q/project:openstack-infra/js-generator-openstack+status:open
and
help me out, would ya? If you've got questions, I'm active in the
#openstack-javascript channel.

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] [infra] NPM Mirrors (IMPORTANT)

[Michael Krotscheck]

Hey there, Vitaly-

I suspect that the issue you're encountering is actually a cross-atlantic
lag, combined with the Mirror's AFS cache warming up. As of this morning,
fuel-ui seems to be installing fine from dfw.rax, though you may run into
similar issues with other mirrors until those caches warm up.

Michael

On Thu, May 12, 2016 at 4:10 AM Vitaly Kramskikh 
wrote:

> Hi, Michael,
>
> 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!
>>
>> 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` during any
>> of its gate jobs, then please invoke the following commands at your project
>> root.
>>
>> echo "registry=http://mirror.dfw.rax.openstack.org/npm/"; >> .npmrc
>> rm -rf ./node_modules/
>> rm -rf ~/.npm/
>> npm install
>>
>> If you encounter an error, put it in paste.openstack.org and reply to
>> this thread. If not, great! Delete the .npmrc file and go on your merry way.
>>
>> Have a great day!
>>
>> 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
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
> __
> 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 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

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

[Michael Krotscheck]

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 moment to review these rules. As a reminder, approval for
eslint-config-openstack requires that a rule receives five positive votes,
with no negative ones.

Have a great day!

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] [infra] NPM Mirrors (IMPORTANT)

[Michael Krotscheck]

Thanks, Vitaly- I'll add it to the list of things to investigate. I suspect
it might be a cold cache, however trusting my gut when it comes to
javascript related things has burned me in the past.

Michael

On Thu, May 12, 2016 at 4:10 AM Vitaly Kramskikh 
wrote:

> Hi, Michael,
>
> 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!
>>
>> 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` during any
>> of its gate jobs, then please invoke the following commands at your project
>> root.
>>
>> echo "registry=http://mirror.dfw.rax.openstack.org/npm/"; >> .npmrc
>> rm -rf ./node_modules/
>> rm -rf ~/.npm/
>> npm install
>>
>> If you encounter an error, put it in paste.openstack.org and reply to
>> this thread. If not, great! Delete the .npmrc file and go on your merry way.
>>
>> Have a great day!
>>
>> 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
>>
>>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
> __
> 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 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

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

[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
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` during any of
its gate jobs, then please invoke the following commands at your project
root.

echo "registry=http://mirror.dfw.rax.openstack.org/npm/"; >> .npmrc
rm -rf ./node_modules/
rm -rf ~/.npm/
npm install

If you encounter an error, put it in paste.openstack.org and reply to this
thread. If not, great! Delete the .npmrc file and go on your merry way.

Have a great day!

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] [horizon] Angular form framework

[Michael Krotscheck]

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 is enough interest that I should have just
> sent it to the whole ML from the start. I’d like to keep folks in the loop,
> so, I’m copying it all below with all of the responses To date.
>
> Thanks,
> Travis
>
> From: "Borland, Matt"  matthew.borl...@hpe.com>>
>
> That sounds great, it would be good to use something we don’t have to
> maintain.  Timur, thanks for researching that!
>
> Matt
>
> From: Timur Sufiev [mailto:tsuf...@mirantis.com]
>
> Folks,
>
> I was going to research this library as the possible prerequisite to
> angularization murano-dashboard 'dynamic ui' feature. So i'm planning to
> start next week looking into it.
>
> On Mon, 2 May 2016 at 20:21, Thai Q Tran  tqt...@us.ibm.com>> wrote:
> I think that it will remove a lot of boilerplate HTML, and is much more
> extensible than the current way of creating forms. But we may need to
> extend the directive to do more things.
>
> The options they provide does not cover the 2 cases that I brought up.
> hz-password and hz-if-* are both directives.
> For example: 
>
> This says that if some_rules passes, then show this input, otherwise, hide
> it. Essentially, what we need is the ability to inject additional attrs
> into each form field so that we can include our own directives. If we can
> somehow extend ngSchemaForm to support this, it should work.
>
> Alternately, we can do the policy check in javascript instead. It just
> means we have to use the services directly rather than their directive
> counterparts (most of the directives we have are backed by a service, i.e.
> hz-if-policy uses the policy service). It's less nice but should also work.
>
> Ultimately, I think going this direction is right, as the extensible
> benefits outweighs the declarative readability. There is still a separation
> of concerns, the forms can be declare like how we declare actions today (in
> a service that we can extend).
>
> - Original message -
> From: "Rob Cresswell (rcresswe)"  rcres...@cisco.com>>
>
> I’m a pretty big fan of this idea, I’ve mentioned it at basically every
> meet up we’ve had. Building up content like this is a great way of
> preventing duplication.
>
> Thai, the forms can take specific conditions to control their display:
> https://github.com/json-schema-form/angular-schema-form/blob/master/docs/index.md#standard-options
> as well as custom form fields, so it looks like that solves both of your
> issues?
>
> Rob
>
> On 27 Apr 2016, at 11:44, tsuf...@mirantis.com
> wrote:
>
> I recall mentioning model-directed generation of forms layout (since they
> are pretty verbose) at Hillsboro midcycle, the response was that 'mixing
> logic/model and presentation is not the best pattern'.
>
> On Wed, Apr 27, 2016 at 7:41 PM Thai Q Tran  tqt...@us.ibm.com>> wrote:
> Looks interesting, but I'm not too sure it will work for all cases. I can
> think of a few cases where this might not work.
>
> Case 1. We have custom directives that modify existing input forms such as
> hz-password. Not sure how we will be able to incorporate it if we use an
> auto-generated form.
>
> Case 2. We have things like hz-if that we may use to control which form
> fields to show. Again, not sure how this will work if we are
> auto-generating the form. I suppose you would have to do the check in the
> controller and modify the JSON to reflect this. But that will make it less
> declarative.
>
> - Original message -
> From: "Tripp, Travis S" mailto:travis.tr...@hpe.com
> >>
>
> Alex Tivelkov at Mirantis mentioned this to me.  Has anybody looked at
> this to see if it is something we might want to incorporate. He said it
> allows using JSON schema definitions to generate forms.  As FYI, the
> Metadata Definitions in Glance are in JSON schema format and many of the
> services actually provide JSON schema of their fields.
> ar form framework
>
> http://schemaform.io
>
>
>
> __
> 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 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] [tc] supporting Go

[Michael Krotscheck]

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 (ensure that a pep8-like thing exists).
- Mirroring dependencies?
- Building Documentation
- Common tool choices for testing, coverage, etc.

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

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

[Michael Krotscheck]

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 ES6, is now an official project (?).
- We have non-browser projects that could use it, assuming that we have a
recent version of Node.js that we can test on.
- We now have Node4 LTS on our infra build nodes, which support _most_ of
EcmaScript 6 things.
- EcmaScript continues to be moving target (And will likely always be a
moving target).
- Xenial contains Node 4 LTS. Ubuntu does _not_ have an upgrade exception
for node (akin to Firefox).
- Node 6 LTS was released during the summit.

Body of work required:
- Discuss and enable linting rules for ES6 in eslint-config-openstack.
- Smoke-test fuel's unit and functional testing for ES6 components.

Personal Assessment:

Frankly, we already have ES6 in our infra, so that train has left the
building. What we need to do is make sure it has the same level of support
as other languages, which, I believe, isn't going to be too difficult. I
also have some commitments of mutual assistance from Vitaly (Fuel) to keep
things sane and keep communication open. As for the upcoming Node4 vs.
Node6 question, I recommend that we _not_ upgrade to Node 6 LTS in the
Newton cycle, however strongly consider it for the Ocata cycle.

Am I missing anything? Does anyone have opinions?

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

[openstack-dev] Summit Core Party after Austin

[Michael Krotscheck]

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

Furthermore, the existence of the Core party has been... contentious. Some
believe it's exclusionary, others think it's inappropriate, yet others
think it's a good way to thank those of use who agree to be constantly
pestered for code reviews.

I'm writing this message for two reasons - mostly, to kick off a discussion
on whether the party is worthwhile. Secondly, to signal to other
organizations that this promotional opportunity is available.

Personally, I appreciate being thanked for my work. I do not necessarily
need to be thanked in this fashion, however as the past venues have been
far more subdued than the Tuesday night events (think cocktail party), it's
a welcome mid-week respite for this overwhelmed little introvert. I don't
want to see it go, but I will understand if it does.

Some numbers, for those who like them (Thanks to Mark Atwood for providing
them):

Total repos: 1010
Total approvers: 1085
Repos for official teams: 566
OpenStack repo approvers: 717
Repos under release management: 90
Managed release repo approvers: 281

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

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

Re: [openstack-dev] [all][oslo] config generator default overrides and namespaces

[Michael Krotscheck]

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 were introduced in 3.7.0. Most of the
patches that apply this for CORS have been introduced and landed in the
last 2 weeks, and I haven't seen anyone else making use of it yet.

Long story short: It's a mitaka thing.

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] [Horizon] Javascript linting and documentation

[Michael Krotscheck]

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 it to be in the doc builder, while I'm ambivalent about where
those checks happen. How about this: Let's keep the checks in there, and
once a replacement is in place, we can turn it off.

In the meantime, they do provide a benefit - for one, I know that Matt
Borland is working on digging into those warnings.


> My perspective on this is if the documentation builder can produce
> documentation that is useful then it's enforcing exactly enough checks on
> the input.
>

It sounds like we don't actually know what this documentation builder is
going to enforce. In fact, it may be more strict and/or less configurable
than eslint. I'm not comfortable turning off a rule if we don't know what
kind of a future we'll get; could you investigate and report back with your
findings?


> For example, the jsdoc linter currently forces us to write @returns
> statements in our docs for angular methods that have no return value, and
> never will (i.e. module.config()) or is otherwise not exposed to developers
> and not interesting (i.e. the return from service or controller
> construction).
>

Given javascript's flexible return types, many IDE's look to the jsdoc to
guess at what the returned type for a method is. This drives things like
code hinting, sanity checks, and tab completion. Explicitly declaring the
return type, even if it's {void}, has a concrete benefit.

And yes, I find it annoying too, but I put up with it for the beauty of
Command-Space-Oh-That's-What-I-Can-Do-Here.


> I mentioned this in passing in the meeting, but most of our JS
> documentation has been written to ngdoc syntax, and that's potentially a
> good thing since it provides much greater hinting to the doc generators
> about how to present and organise the output, but also influences things
> like @returns usefulness.
>

I remember you saying that ngdoc doesn't actually work, so I'm a bit
confused as to why we're writing documentation to that standard. Could you
clarify?


> We just have to find the right tool (or, more likely, create, since I've
> been looking for a while and haven't found a suitable tool) that uses the
> information we're coding into our comments.
>

Awesome. So once this tool is completed, let's come back to this
conversation! I don't think we can continue without really knowing what the
tradeoffs will be.

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] [Horizon] Javascript linting and documentation

[Michael Krotscheck]

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
__
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] [Horizon] Javascript linting and documentation

[Michael Krotscheck]

+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 notoriously
permissive about bad formatting. Eslint's stricter jsdoc checks would add
an additional safety net.

However, if you're working on this with the docs team, then the result
should be applicable to the entirety of openstack - meaning that once your
work is complete, it may make sense to turn the rule off globally.

Michael

On Wed, Mar 9, 2016 at 11:14 AM Rob Cresswell (rcresswe) 
wrote:

> If possible, I’d really prefer we left linting work to Newton. It’ll be
> good to get it to a more usable state again, but we ought to be focusing on
> thoroughly checking the new Launch Instance for bugs and edge usage cases,
> as well as the outstanding bugs and blueprints targeted at RC1 (
> https://launchpad.net/horizon/+milestone/mitaka-rc1). This is a great
> opportunity to prove that the Angular rewrites are fully capable of
> providing an improved experience, and we should be capitalising on that.
>
> Rob
>
>
> On 9 Mar 2016, at 02:25, Richard Jones  wrote:
>
> Hey all,
>
> I started looking into fixing the wall of "npm run lint" warnings today
> and quickly noticed that about 85% of the "linting" warnings were about
> jsdoc. We have significant issues around jsdoc anyway and we're supposed to
> be using Sphinx anyway[1].
>
> Some Horizon folks will know that I've been investigating generating
> publishable documentation for our Javascript code for some time. Most of
> the tools either don't work (dgeni) or produce pretty unusable output for a
> project our size (jsdoc and grunt-ngdocs). I am about to investigate Sphinx
> in collaboration with the docs team.
>
> Regardless, I believe that the documentation generation should generate
> errors about that documentation, not the code linter. Once we actually get
> a documentation generator going. Until then, we don't even know what syntax
> the documentation should follow.
>
> I've proposed a change which just turns jsdoc "linting" off[2]. At the
> moment, it is less than useful (the noise drowns out any other, legitimate
> linting).
>
>
>  Richard
>
>
> [1] http://governance.openstack.org/reference/cti/javascript-cti.html
> [2] https://review.openstack.org/#/c/290235/
>
> __
> 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 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 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] [horizon] Proposal to add Diana Whitten tohorizon-core

[Michael Krotscheck]

+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: [openstack-dev] [horizon] Proposal to add Diana Whitten to
> horizon-core
> Date: Tue, Mar 8, 2016 2:07 PM
>
> I propose adding Diana Whitten[1] to horizon-core.
>
> Diana is an active reviewer, contributor and community member. Over
> the past couple of releases, Diana has driven extensive changes around
> theme-ability in Horizon and drastically increased the standardization
> of our use of bootstrap. During this time, Diana has also provided
> valuable reviews to keep us on the straight and narrow preventing our
> continued abuse of defenseless web technologies.
>
> Please respond with comments, +1s, or objections by Friday.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group&user_id=hurgleburgler&release=all
>
> __
> 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 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 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] [Horizon] How do we move forward with xstatic releases?

[Michael Krotscheck]

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 past architectural decisions.

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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

All patches have been proposed, with the exception of ironic, which
implemented its own config generator which does not support defaults. The
patch list is available here:

https://review.openstack.org/#/q/status:open+branch:master+(topic:bug/1551836)


On Tue, Mar 1, 2016 at 8:59 AM Michael Krotscheck 
wrote:

> The keystone patch has landed. I've gone ahead and filed the appropriate
> launchpad bug to address this issue:
>
> https://bugs.launchpad.net/oslo.config/+bug/1551836
>
> Note: Using latent configuration imposes a forward-going maintenance
> burden on all projects impacted, if released in mitaka. As such I recommend
> that all PTL's mark this as a release-blocking bug, in order to buy us more
> time to get these patches landed. I am working as best I can, however I
> cannot guarantee that I'll be able to land all these patches in 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, 2016 at 6:09 AM Michael Krotscheck 
> wrote:
>
>> Alright, I have a first sample patch up for what was discussed in this
>> thread here:
>>
>> (Keystone) https://review.openstack.org/#/c/285308/
>>
>> The noted TODO on that is the cors middleware should (eventually) provide
>> its own set_defaults method, so that CORS_OPTS isn't exposed publicly.
>> However, dhellmann doesn't believe we have time for that in Mitaka, since
>> oslo_middleware is already frozen for the release. I'll mark it as a todo
>> item for myself, as the next cycle will contain a good amount of additional
>> work on this portion of openstack.
>>
>> Given the time constraints, I'll wait 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 Fainberg <
>>> morgan.fainb...@gmail.com> 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 than hard against feature-freeze.
>>>>
>>>
>>> This sounds like a really good way to get us more time, so I'm in favor
>>> of this. However, even with the additional time I will not be able to land
>>> all these patches on my own.
>>>
>>> Who is willing to help?
>>>
>>> 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] [Openstack-operators] OpenStack Contributor Awards

[Michael Krotscheck]

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 got was this
lousy t-shirt"

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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

The keystone patch has landed. I've gone ahead and filed the appropriate
launchpad bug to address this issue:

https://bugs.launchpad.net/oslo.config/+bug/1551836

Note: Using latent configuration imposes a forward-going maintenance burden
on all projects impacted, if released in mitaka. As such I recommend that
all PTL's mark this as a release-blocking bug, in order to buy us more time
to get these patches landed. I am working as best I can, however I cannot
guarantee that I'll be able to land all these patches in 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, 2016 at 6:09 AM Michael Krotscheck 
wrote:

> Alright, I have a first sample patch up for what was discussed in this
> thread here:
>
> (Keystone) https://review.openstack.org/#/c/285308/
>
> The noted TODO on that is the cors middleware should (eventually) provide
> its own set_defaults method, so that CORS_OPTS isn't exposed publicly.
> However, dhellmann doesn't believe we have time for that in Mitaka, since
> oslo_middleware is already frozen for the release. I'll mark it as a todo
> item for myself, as the next cycle will contain a good amount of additional
> work on this portion of openstack.
>
> Given the time constraints, I'll wait 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 Fainberg <
>> morgan.fainb...@gmail.com> 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 than hard against feature-freeze.
>>>
>>
>> This sounds like a really good way to get us more time, so I'm in favor
>> of this. However, even with the additional time I will not be able to land
>> all these patches on my own.
>>
>> Who is willing to help?
>>
>> 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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

Alright, I have a first sample patch up for what was discussed in this
thread here:

(Keystone) https://review.openstack.org/#/c/285308/

The noted TODO on that is the cors middleware should (eventually) provide
its own set_defaults method, so that CORS_OPTS isn't exposed publicly.
However, dhellmann doesn't believe we have time for that in Mitaka, since
oslo_middleware is already frozen for the release. I'll mark it as a todo
item for myself, as the next cycle will contain a good amount of additional
work on this portion of openstack.

Given the time constraints, I'll wait 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 Fainberg <
> morgan.fainb...@gmail.com> 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 than hard against feature-freeze.
>>
>
> This sounds like a really good way to get us more time, so I'm in favor of
> this. However, even with the additional time I will not be able to land all
> these patches on my own.
>
> Who is willing to help?
>
> 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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

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 than hard against feature-freeze.
>

This sounds like a really good way to get us more time, so I'm in favor of
this. However, even with the additional time I will not be able to land all
these patches on my own.

Who is willing to help?

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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

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 5 of them given my
other obligations, and I need help for the rest.

Who is willing to help?

Right now, it appears that the default in the middleware is do nothing.
> That means CORS won't be in a functional state on services by default.
> However, I thought the point of the effort was that all the APIs in the
> wild would be CORS enabled.
>

This is by design, and is specifically called out in the cross-project
specification, adopted on June 9th.

http://specs.openstack.org/openstack/openstack-specs/specs/cors-support.html

I'm not hugely sympathetic to defaulting to not having the Keystone
> headers specified in the non keystone case. I get there are non keystone
> cases, but keystone is defcore. Making the keystone case worse for the
> non keystone case seems like fundamentally the wrong tradeoff.
>

The non-keystone use cases is also mentioned in the spec.

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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

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 a
year ago, I can point at several instances where custom UI's were built to
handle different use cases. There were examples of Monitoring dashboards,
Custom admin panels, etc.

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] [all] A proposal to separate the design summit

[Michael Krotscheck]

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 nice if the patrons (our
> employers) would recognize that getting us all working well together
> is a cost of doing this business.
>

To echo (and add an angle) what Chris is saying: follow the money. Sales
and marketing has traditionally gotten more dollars than dev, and I feel
that splitting the summit into two is the start of the long slow
budget-cutting death of the design summit. "Sorry, we just can't afford to
send you this year" is going to erode attendance.

Also, it doesn't seem like alternative cost-savings solutions have been
considered. For example, how about we host a summit in a Not-Top-Tier city
for a change? Examples that come to mind are Columbus, Pittsburgh, and
Indianapolis, which each have convention centers larger than Austin.

On the upside, if we're going down this path, can I recommend that the Ops
summit be combined with the marketing summit? It seems like a natural fit
to put People Who Deploy OpenStack together with People Who Sell Things To
People Who Deploy OpenStack.

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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

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
prescribed. If, for instance, ironic is deployed with an auth plugin that
is not keystone, different allowed headers would be required.

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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

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.
> https://review.openstack.org/#/c/265415/ is no longer needed).
>

I will need help to do this. More below.


> 2) ideally the cors middleware will have sane defaults for that set of
> headers in oslo.config.
>

I'd like to make sure we agree on what "Sane defaults" means here. By
design, the CORS middleware is generic, and only explicitly includes the
headers prescribed in the w3c spec.  It should not include any additional
headers, for reasons of downstream non-openstack consumers.


> 3) projects should be able to apply new defaults for these options in
> their codebase through a default override process (that is now nicely
> documented somewhere... url?)


New sample defaults for the generated configuration files, they should not
live anywhere else. The CORS middleware should, if we go this path, be
little more than a true-to-spec implementation, with config files that
extend it for the appropriate API.

The big question I now have is: What do we do with respect to the mitaka
freeze?

Option 1: Implement as is, keep things consistent, fix them in Newton.

Option 2: Try to fix it in Mitaka.
This requires patches against Heat, Nova, Aodh, Ceilometer, Keystone,
Mistral, Searchlight, Designate, Manila, Barbican, Congress, Neutron,
Cinder, Magnum, Sahara, Trove, Murano, Glance, Cue, Kite, Solum, Ironic.
These patches have to land after the next oslo release has made it into
global requirements, and requires the +2's of the appropriate cores.

I will need help, both to write and land those patches. We're super tight
against feature freeze, and I'm currently overcommitted with the Ironic and
Horizon midcycles (this week and next). I also have an infant at home, with
no daycare, so I cannot work long hours to make this happen.

I feel that I can commit to landing 5 of the 22 required patches. If I
cannot get support for the remaining 17, we risk having an inconsistent
implementation, in which case Option 1 is preferred.

Who's willing to help?

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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

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 files and documentation are where we want this. If we override the
defaults, and then a config file is modified to again overwrite those
defaults, then suddenly a magic internal value that is presumably required
for the feature to function properly disappears. What we're looking to do
is guide operators and deployers to knowing what should live in their
config file for the feature to work properly. Hence the change you created
being what we need.

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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

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
__
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] [oslo] upgrade implications of lots of content in paste.ini

[Michael Krotscheck]

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 from keystone's service catalog and trusted dashboards
might be a next step. I'm sure the oslo core team can chime in, but the
arguments that I recall were:

1- Maintaining a list of headers in a repository separate from projects
that use them is undesirable and likely to bitrot.
2- Oslo's backwards-compatibility policy means that new and/or modified
headers could only be added, not removed. This would result in a long list
of no-longer used headers (https://tools.ietf.org/html/rfc6648 was
mentioned).
3- We could not guarantee that downstream consumers of the CORS middleware
don't already exist, and they should not be subject to having
suddenly-approved headers.

We'd like to move forward with this approach at this time, to ensure that
CORS is consistently enabled in Mitaka before the freeze. I'd be happy to
work with you on alternative approaches moving forwards; for example, I
think teaching oslo's genconfig to permit project-specific default
overrides would solve this problem in a way that would make both of us, and
other users of genconfig, very happy.

Michael

On Wed, Feb 17, 2016 at 5:08 AM Sean Dague  wrote:

> A set of CORS patches came out recently that add a ton of content to
> paste.ini for every project (much of it the same between projects) -
> https://review.openstack.org/#/c/265415/1
>
> paste.ini is in a really weird space because it's config, ops can change
> it, so large amounts of complicated things in there which may change in
> future releases is really problematic. Deprecating content out of there
> turns into a giant challenge because of this. As does changes to code
> which make any assumption what so ever about other content in that file.
>
> Why weren't these options included as sane defaults in the base cors
> middleware?
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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 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] [infra] Gate is broken

[Michael Krotscheck]

Hello, everyone!

The broken images have been deleted, and our jenkins slaves should revert
back to the previous (good) image. It's safe to submit patches again!

Michael

On Fri, Jan 29, 2016 at 7:52 AM Paul Michali  wrote:

> Thanks for hopping on it quickly!
>
>
>
> On Fri, 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 talks for Austin!
>>
>> That certainly sounds better than "We misconfigured pip.conf and now none
>> of our nodes know how to pip install.". A fix has been merged, however it
>> will take some time to propagate. We will keep you updated on this thread
>> and on IRC.
>>
>> 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
>>
> __
> 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 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] [infra] Gate is broken

[Michael Krotscheck]

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 how to pip install.". A fix has been merged, however it
will take some time to propagate. We will keep you updated on this thread
and on IRC.

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] [api] api working group proposed actions guideline needs input

[Michael Krotscheck]

Is there an accepted process for this? And/or does everyone care enough to
really weigh in?



Some dictionary terms:
Task: A piece of work to be done or undertaken.
Transition: The process or a period of changing from one state or condition
to another.
Action: The fact or process of doing 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 the same word for things. Is there a meaningful
> > enough difference between "Actions", "Transitions", and "Tasks", that
> > requires different words?
>
> not that i have detected, although i would love hear other opinions on
> this.
>
> i have to admit that this is the first time i'm hearing "transitions",
> and i feel it could be looked at separately from "actions" or "tasks".
> but i think this is largely a semantic debate.
>
> i do think it would be useful to coalesce on a standard term for what we
> are talking about.
>
> regards,
> mike
>
>
> __
> 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 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] [api] api working group proposed actions guideline needs input

[Michael Krotscheck]

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: I like using the same word for things. Is there a meaningful enough
difference between "Actions", "Transitions", and "Tasks", that requires
different words?

Michael

On Fri, Jan 15, 2016 at 9:17 AM Chris Dent  wrote:

>
> In this review:
>
>  https://review.openstack.org/#/c/234994/
>
> there's a proposal that provides guidance for how to represent certains
> types of actions against resources in an HTTP API. There's been a fair
> bit of back and forth between me and the original author without
> conclusion.
>
> It would be great to get additional eyes on this spec so that we
> could reach agreement. It is quite likely everyone involved is wrong
> in some fashion or there are misunderstandings happening. If you're
> working to implement actions in APIs, or just thinking about it,
> pile on.
>
> There's quite a lot of meat in the comments, discussing various
> alternatives.
>
> Thanks.
>
> --
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw:
> @anticdent__
> 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 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] [qa] [eslint-config-openstack] Nominating Beth Elwell to eslint-config-openstack core

[Michael Krotscheck]

Hello everyone!

This email is to nominate Elizabeth "Beth" Elwell (aka betherly) to core on
eslint-config-openstack. She provides valuable EU timezone coverage, as
well as a friendly and inviting demeanor when discussing language rules.
Also, she's been keeping up-to-date with the 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 special way :)

Michael Krotscheck
__
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] [all] [infra] [java] Seeking java mirror person

[Michael Krotscheck]

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 pick up
the white courtesy phone and contact me? I'm trying to gather all the
different mirror efforts (rubygems, pypi-wheel, bower, npm, java, etc)
under one coordinated umbrella.

For all the other lurkers who are curious about this topic, you can come
help review our spec and/or patches :)

Spec: https://review.openstack.org/#/c/252678/
Patches:
https://review.openstack.org/#/q/status:open+branch:master+topic:unified_mirror,n,z

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] [Fuel] Patch size limit

[Michael Krotscheck]

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

Also, random concerns I have with using "Line of code" as a metric:

* What counts as a Line of Code? Does whitespace count? Comments? Docs?
Tests? Should comments/docs/tests be included in this heuristic?
* Taking a big patch, and splitting it into several, can easily lead to
dead code as the first patch may remain completely inactive on master until
the entire patch chain merges.
* git annotate becomes far less useful, as you cannot simply look at all
the applicable changes for a given patch - you have to dig for all related
patches.
* Reverting things becomes more difficult for the same reason. Would you
revert all-in-one? One revert per patch?

I've seen, and written, 1000+ line patches. Some of them were 200 lines of
logic, 1000+ lines of tests. Others included extensive documentation,
comments, etc, or perhaps-too-verbose parameter and method names that
clearly explain what they do. Others use method-parameter-per-line style
formatting in their code to assist in legibility.

While I totally understand how frustrating it is to have to review a large
patch, I'm not in favor of a hard limit for something which is governed
mostly by whitespace and formatting preferences.

Michael

On Tue, Dec 1, 2015 at 6:36 AM Sylwester Brzeczkowski <
sbrzeczkow...@mirantis.com> wrote:

> Neil, just to clarify: moved/renamed files are marked as "R" so I think
> there may be some way to ignore such files when counting LOC.
>
> Maciej, I completely agree with you. It's pretty hard to review such big
> change,and takes a lot of time which could be saved by submitting smaller
> patches.
>
> +1
>
> On Tue, Dec 1, 2015 at 1:50 PM, Neil Jerram 
> wrote:
>
>> On 01/12/15 12:45, Maciej Kwiek wrote:
>> > Hi,
>> >
>> > I recently noticed the influx of big patches hitting Gerrit
>> > (especially in fuel-web, but I also heard that there was a couple of
>> > big ones in library). I think that patches that have 1000 LOC are
>> > simply too big to review thoroughly and reliably.
>> >
>> > I would argue that there should be a limit to patch size, either a
>> > soft one (i.e. written down in contributor guidelines) or a hard one
>> > (e.g. enforced by gate job).
>> >
>> > I think that we need a discussion whether we really need this limit,
>> > what should it be, and how to enforce it.
>> >
>> > I personally think that most patches that are over 400 LOC could be
>> > easily split into at least two smaller changes.
>> >
>> > Regarding the limit enforcement - I think we should go with the soft
>> > limit, with X LOC written as a guideline and giving the reviewers a
>> > possibility to give -1s to patches that are too big, but also giving
>> > the possibility to merge bigger changes if it's absolutely necessary
>> > (in really rare cases the changes simply cannot be split). We may mix
>> > in the hard limit for ridiculously large patches (twice the "soft
>> > limit" would be good in my opinion), so the gate would automatically
>> > reject such patches, forcing contributor to split his patch.
>> >
>> > Please share your thoughts on this.
>>
>> I think most of your principle is correct.  However I can imagine a file
>> renaming / moving patch that would appear in Gerrit to be >=1000 LOC,
>> but would actually just be file moves, with perhaps some trivial changes
>> to Python module paths; and I don't think it would be helpful to force a
>> patch like that to be split up.  So it may not be correct to enforce a
>> hard limit all the time.
>>
>> Neil
>>
>>
>> __
>> 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
>>
>
>
>
> --
> *Sylwester Brzeczkowski*
> Junior Python Software Engineer
> Product Development-Core : Product Engineering
> __
> 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 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] [cross-project] Cross-project Liaisons

[Michael Krotscheck]

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 liaisons which would have the
> following
> > duties:
> >
> > * Watching the cross-project spec repo [1].
> >   - Comment on specs that involve your project. +1 to carry forward for
> TC
> > approval.
> > -- If you're not able to provide technical guidance on certain specs
> for
> >your project, it's up to you to get the right people involved.
> > -- Assuming you get someone else involved, it's up to you to make
> sure they
> >keep up with communication.
> >   - Communicate back to your project's meeting on certain cross-project
> specs
> > when necessary. This is also good for the previous bullet point of
> sourcing
> > who would have technical knowledge for certain specs.
> > * Attend the cross-project meeting when it's called for [2].
> > [...]
>
> I like it. That sounds like a great way to ensure cross-project efforts
> don't fall into the cracks. The same horizontal group (chapter? guild?)
> could also ultimately end up tracking cross-project cycle goals.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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 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] New linting rules under review

[Michael Krotscheck]

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.openstack.org/#/q/status:open+project:openstack/eslint-config-openstack+-(label:Code-Review%253D2%252Cuser%253Dself+OR+label:Code-Review%253D1%252Cuser%253Dself)label:Verified%253D1,n,z

Even if you see a -1 on the review, please provide your own feedback.
Linting rules often bridge that fuzzy line between benefit and personal
preference, and an active and lively discussion is the best way to ferret
that out.

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

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

[Michael Krotscheck]

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, eternally patient, friendly, and nothing short of
amazing. The straw that broke the camel's back, in this case, was that you
fixed a bug, which I introduced, quietly and quickly, without any kind of
big public drama.

Thank you for that, and for everything else that I mentioned. You, sir, are
a better man than I. :)

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

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

[Michael Krotscheck]

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 over here,
we'd like to invite anyone and everyone interested in looking at our JS
code to add their own +2, and maybe even contribute a bit!

https://review.openstack.org/#/q/status:open+project:openstack/ironic-webclient,n,z
__
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] [all] Something about being a PTL

[Michael Krotscheck]

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 that it's almost
impossible to split your time between being a PTL and, say, being a member
of the TC, or working on an employer's private
feature/cloud/deployment/etc. For a far more eloquent explanation of why
this is, I defer to Devananda's wonderful non-candidacy email last spring.

http://lists.openstack.org/pipermail/openstack-dev/2015-April/062364.html

Not many people have the privilege of working for a company that supports
that level of upstream commitment. If your employer doesn't, send me your
Resumé ;).

Michael

On Wed, Sep 9, 2015 at 8:15 AM Flavio Percoco  wrote:

> Greetings,
>
> Next week many folks will be running for PTL positions and I thought
> about taking the time to dump[0] some thoughts about what being a PTL
> means - at least for me - and what one should consider before running.
>
> Since the audience I want to reach is mostly in this mailing list, I
> thought about sending it here as well.
>
> [0] http://blog.flaper87.com/post/something-about-being-a-ptl/
> Flavio
>
>
> It's that time of the cycle, in OpenStack, when projects need to elect
> who's going to be the PTL for the next 6 months. People look at the,
> hopefully many, candidacies and vote based on the proposals that are
> more sound to them. I believe, for the PTL elections, the voting
> process has worked decently, which is why this post is not meant for
> voters but for the, hopefully many, PTL candidates.
>
> First and foremost, thank you. Thanks for raising your hand and
> willing to take on this role. It's an honor to have you in the
> community and I wish you the best of lucks in this round. Below are a
> few things that I hope will help you in the preparation of your
> candidacy and that I also hope will help making you a better PTL and
> community member.
>
>
> Why do you want to be a PTL?
> 
>
> Before even start writing your candidacy, please, ask yourself why you
> want to be a PTL. What is it that you want to bring to the project
> that is good for both, the project and the community. You don't really
> need to get stuck on this question forever, you don't really need to
> bring something new to the project.
>
> In my opinion, a very good answer for the above could be: "I believe
> I'll provide the right guidance to the community and the project."
>
> Seriously, one mistake that new PTLs often do is to believe they are
> on their own. Turns out that PTLs arent. The whole point about being a
> PTL is to help the community and to improve it. You're not going to do
> that if you think you're the one pulling the community. PTLs ought to
> work *with* the community not *for* the community.
>
> This leads me to my next point
>
> Be part of the community
> 
>
> Being a PTL is more than just going through launchpad and keeping an
> eye on the milestones. That's a lot of work, true. But here's a
> secret, it takes more time to be involved with the community of the
> project you're serving than going through launchpad.
>
> As a PTL, you have to be around. You have to keep an eye on the
> mailing list in a daily basis. You have to talk to the members of the
> community you're serving because you have to be up-to-date about the
> things that are happening in the project and the community. There may
> be conflicts in reviews, bugs and you have to be there to help solving
> those.
>
> Among all the things you'll have to do, the community should be in the
> top 2 of your priorities. I'm not talking just about the community of
> the project you're working on. I'm talking about OpenStack. Does your
> project have an impact on other projects? Is your project part of
> DefCore? Is your project widely deployed? What are the deprecation
> guarantees provided? Does your project consume common libraries? What
> can your project contribute back to the rest of the community?
>
> There are *many* things related to the project's community and its
> interaction with the rest of the OpenStack community that are
> important and that should be taken care of. However, you're not alone,
> you have a community. Remember, you'll be serving the community, it's
> not the other way around. Working with the community is the best thing
> you can do.
>
> As you can imagine, the above is exhausting and it takes time. It
> takes a lot of time, which leads me to my next point.
>
> Make sure you'll have time
> ==
>
> There are a few things impossible in this world, predicting time
> availability is one of them. Nonetheless, we can get really close
> estimates and you should strive, *before* sending your candidacy, to
> get the closest estimate of your upstream availability for the ne

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

[Michael Krotscheck]

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 introduction of the eslint-config-openstack project was to
create a javascript equivalent to 'hacking'. When created, we disabled many
of the default rules, because we didn't want to overwhelm horizon with new
rules while they were still in the middle of their JSCS cleanup.

Well, now their build finally passes, and their eslint job has the vote.
Also, in the meantime, eslint-config-openstack has been adopted by merlin,
ironic-webclient, and refstack, and is likely to be adopted by more pure
javascript projects in the future.

It's time to revisit all the rules that we deactivated, and discuss which
of them make sense for OpenStack. We'll release these in small batches, so
that each project won't be overwhelmed by them.

If you need to come up for air from the pre-feature-freeze crazyness, come
on and offer your two cents on some language style rules!

Michael
We are not responsible for broken builds. The only reason this would be a
problem is if you used fuzzy dependency versions, and you shouldn't be
using those in the first place :P
__
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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[Michael Krotscheck]

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 something similar, we will be
> addressing the gap.
>

Is there a cross-project spec with assigned resources? I'd love to comment
on it.

I also assert horizon should not be managing users in the same way Keystone
> should not be managing users. Horizon should show what users have access to
> openstack (and this *can* be paginated) and allow for searching for a user
> that is visible to keystone but does not have access to openstack so that
> they can be grants access.
>

Is there a horizon spec that defines this? I'd love to comment on it.


> The user management service would be FreeIPA in my previous example (or AD
> in the environments that deploy it, etc).
>

> 1: you do not get to list every user visible to keystone via v3. This is
> where the problems lie.
>

> 2: you can search for users that are visible but do not have an active
> assignment (this may need some work - and is a reasonable ask).
>
> 2a: if the list of users is small the filter/search could return all users
>
> 3: you can list users with an active assignment (using the assignment
> apis) and this *can* be paginated (if it does not already support
> pagination)
>
> 4: (future view) leverage an already existing open source solution for
> user management such as FreeIPA and remove/deprecate the sql-based data
> store that is missing basic user management features
>

Hey, all of the above looks like a spec! Neat! You should propose it!

Michael
Code Trumps Conversation
__
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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[Michael Krotscheck]

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 a list of data. This is
something horizon needs, traditionally relying on keystone, and now
keystone has broken backwards compatibility for horizon because of one use
case, without taking responsibility for it and providing (with code) a good
alternative. Furthermore, you and your team are saying "You should go use a
different service that's better at this", which is basically saying "We
live in this silo, we don't have to care about other silo's".

You broke backwards compatibility. It's your responsibility to address it.

The other argument I'm hearing here is that keystone is responsible for
authentication and authorization, but not user management. I actually agree
with this, but nobody's started a user management service and/or its
delegation plugins, so now we have a rather large hole in horizon's
features, late in a release cycle, and nobody has the resources to address
it. What do you propose to do about it?

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] [UX] [Keystone] [Horizon] Pagination support for Identity dashboard entities

[Michael Krotscheck]

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 chance to respond.

It feels like we have four UX assumptions, which I feel should be converted
into questions:
1- Do users want to page through search results?
2- Do users want to page through filter results? (do they use filter
results?)
3- If they want to page, do they want to be able to go back a page and/or
know their current page?
4- How much do users care about small data inconsistencies (i.e. ordering
of record sets changing from page-to-page).

Also, from personal experience, it is impossible to make a "search"
implementation that users, especially enterprise users, trust. I personally
blame Sharepoint for that.

Michael

On Fri, Aug 14, 2015 at 6:17 AM Morgan Fainberg 
wrote:

> As a quick note the api-ref you are linking to has some gaps/has not been
> kept in sync with the official api specifications.
>
> The official API specification is located at
> http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
> at the top) and there is a known open bug to work with the docs team to get
> this in sync (somehow).
>
> Unfortunately there are a number of cases especially with the identity
> backend where pagination just does not work (or works completely
> unreliably) such as utilizing the ldap driver. Either a cursor must be
> maintained (problematic in REST) or the results could be wildly different
> every single request meaning each page is not really guaranteed to be the
> "next page" it could be the same/show inconsistent results. The second
> issue is that the pagination is not a good UX even where it works - the
> simple question is: if you can filter the results how many pages deep do
> you go before refining the query; think of your use of search engines.
>
> In light of these issues Keystone has opted for a filter / limit (config).
> If the results exceed the limit there is a truncation that occurs and it is
> recommended extra filtering be applied to reduce the total number of
> results.
>
> This discussion has gone around a few times, pagination in keystone is not
> currently on the roadmap. In addition to the above doc bug, we should work
> to better socialize this filter-over-paginate methodology.
>
> --Morgan
>
> Sent via mobile
>
> On Aug 14, 2015, at 05:46, Timur Sufiev  wrote:
>
> Hello, Keystone folks!
>
> I've just discovered an unfortunate fact that Horizon pagination for
> Tenants/Projects list that worked with Keystone v2 doesn't work with
> Keysone v3 anymore - its API call simply lacks the 'marker' and 'limit'
> parameters [1] that Horizon is relying upon. Meanwhile having looked
> through [2] and [3] I'm a bit confused: while Keystone v3 API states it
> supports [2] pagination for every kind of entities (by using 'page' and
> 'per_page' parameters), the related blueprint [3] is not yet approved,
> meaning that most likely the API implementation did not make it into
> existing Keystone codebase. So I wonder whether there are some plans to
> implement pagination for Keystone API calls that list its entities?
>
> P.S. I'm aware of SearchLight project that tries to help Horizon with
> other OpenStack APIs (part of its mission), what I'm trying to understand
> here is are we going to have some fallback pagination mechanism for
> Horizon's Identity in a short-term/mid-term perspective.
>
> [1] http://developer.openstack.org/api-ref-identity-admin-v2.html
> [2] http://developer.openstack.org/api-ref-identity-v3.html
> [3] https://blueprints.launchpad.net/keystone/+spec/pagination
>
> __
> 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 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 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] [oslo][keystone] oslo_config and wsgi middlewares

[Michael Krotscheck]

It looks like the additional features added, in particular the
'oslo_config_project' property, needs to be documented.

A deeper read shows that you're right, existing functionality was not
broken. Apologies for being heavy handed in my response.

Michael


On Tue, Aug 11, 2015 at 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
> > documentation of the library no longer matches the actual functionality,
> > and will need to be updated before we can release a new version of
> > oslo_middleware.
>
> I'd be happy to fix the documentation, but I cannot find any point that
> does not work anymore or may have been broken by those pathes. Could you
> hint me in the right direction?
>
> Thanks!
>
> Best,
> --
> Julien Danjou
> // Free Software hacker
> // http://julien.danjou.info
>
__
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] [oslo][keystone] oslo_config and wsgi middlewares

[Michael Krotscheck]

It appears that the patch related to this discussion were rushed through
rather quickly, and without appropriate updates to the documentation. The
documentation of the library no longer matches the actual functionality,
and will need to be updated before we can release a new version of
oslo_middleware.

Mehdi, if you would please update the documentation in oslo_middleware as
quickly as possible? Some of us have features that we're trying to land in
liberty, which we cannot do without a new release of this library.

To the rest of the Oslo team, I'd like to propose that if we do 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 Jamie Lennox  wrote:

>
>
> - Original Message -
> > From: "Jamie Lennox" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Sent: Monday, August 10, 2015 12:36:14 PM
> > Subject: Re: [openstack-dev] [oslo][keystone] oslo_config and wsgi
> middlewares
> >
> >
> >
> > - Original Message -
> > > From: "Mehdi Abaakouk" 
> > > To: openstack-dev@lists.openstack.org
> > > Sent: Friday, August 7, 2015 1:57:54 AM
> > > Subject: [openstack-dev] [oslo][keystone] oslo_config and wsgi
> middlewares
> > >
> > > Hi,
> > >
> > > I want to share with you some problems I have recently encountered with
> > > openstack middlewares and oslo.config.
> > >
> > > The issues
> > > --
> > >
> > > In project Gnocchi, I would use oslo.middleware.cors, I have expected
> to
> > > just put the name of the middleware to the wsgi pipeline, but I can't.
> > > The middlewares only works if you pass the oslo_config.cfg.ConfigOpts()
> > > object or via 'paste-deploy'... Gnocchi doesn't use paste-deploy, so
> > > I have to modify the code to load it...
> > > (For the keystonemiddleware, Gnocchi already have a special
> > > handling/hack to load it [1] and [2]).
> > > I don't want to write the same hack for each openstack middlewares.
> > >
> > >
> > > In project Aodh (ceilometer-alarm), we recently got an issue with
> > > keystonemiddleware since we remove the usage of the global object
> > > oslo_config.cfg.CONF. The middleware doesn't load its options from the
> > > config file of aodh anymore. Our authentication is broken.
> > > We can still pass them through paste-deploy configuration but this
> looks
> > > a method of the past. I still don't want to write a hack for each
> > > openstack middlewares.
> > >
> > >
> > > Then I have digged into other middlewares and applications to see how
> > > they handle their conf.
> > >
> > > oslo_middlewarre.sizelimit and oslo_middlewarre.ssl take options only
> > > via the global oslo_config.cfg.CONF. So they are unusable for
> application
> > > that doesn't use this global object.
> > >
> > > oslo_middleware.healthcheck take options as dict like any other python
> > > middleware. This is suitable for 'paste-deploy'. But doesn't allow
> > > configuration via oslo.config, doesn't have a strong config options
> > > type checking and co.
> > >
> > > Zaqar seems got same kind of issue about keystonemiddleware, and just
> > > write a hack to workaround the issue (monkeypatch the cfg.CONF of
> > > keystonemiddleware with their local version of the object [3] and then
> > > transform the loaded options into a dict to pass them via the legacy
> > > middleware dict options [4]) .
> > >
> > > Most applications, just still use the global object for the
> > > configuration and don't, yet, see those issues.
> > >
> > >
> > > All of that is really not consistent.
> > >
> > > This is confusing for developer to have some middlewares that need
> > > pre-setup,
> > > enforce them to rely on global python object, and some others not.
> > > This is confusing for deployer their can't do the configuration of
> > > middlewares in the same way for each middlewares and each projects.
> > >
> > > But keystonemiddleware, oslo.middleware.cors,... are supposed to be
> wsgi
> > > middlewares, something that is independant of the a

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

[Michael Krotscheck]

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 unconstrained, there's no access control to guarantee
the thing you want hasn't been modified, and in the case of oslo.config,
they require initialization before they can be used.

Writing any kind of logic that assumes that a magic global instance has
been initialized is brittle. The pastedeploy wsgi chain is a perfect
example, because the application is only created after the middleware chain
has been executed. This leaves you with - at best - a malfunctioning piece
of middleware that breaks because the global oslo.config object isn't
ready. At worst it's a security vulnerability that permits bypassing things
like keystone.

Passing the config object is a _good_ thing, because it doesn't rely on
magic. Magic is bad. If someone looks at the code and says: "I wonder how
this piece of middleware gets its values", and they don't see the config
object being passed, they have to dig into the middleware itself to figure
out what's going on.


> I'm clearly on the operator side too, and I just try to find a solution to
> be able to use all middlewares without having to write code for each
> in each application and use oslo.config. Zaqar, Gnocchi and Aodh are
> the first projects that do to not use cfg.CONF and can't load many
> middlewares without writing code for each. When middleware should be just
> something that deployer enabled and configuration. Our middleware looks
> more like a lib than a middleware)
>

Sorry, but you're talking from the point of view of someone who wants to
"not have to write code for each". That's a developer. It's our job as
developers to write code until it's as easy as possible, and passing in a
config object is _dead simple_ in your application initialization.

Here's the thing. If the middleware is _optional_ like keystone auth, then
including it via paste.ini makes way more sense. In fact, keystone auth has
gone to great lengths to have no dependencies for that very same reason.
If, instead, the middleware is a feature that should ship with the service
- like CORS, or a simple caching layer - then it should be baked into your
application initialization directly.

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] [oslo][keystone] oslo_config and wsgi middlewares

[Michael Krotscheck]

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 been
updated to reflect this.

As for the "How do we proceed" question, I feel your question can be better
asked as: Do we support developers, or do we support operators? The
developer stance is that of architectural purity, of minimizing
dependencies, and of staying as true to default as possible. The Operator's
stance is that of simplified configuration, performance, good
documentation, and reliability.

I fall on the operators side, and as a result feel that we should be using
oslo.config for everything. One single configuration method across
services, consistent naming conventions, autogenerated with sane options,
with tooling and testing that makes it reliable. Special Snowflakes really
just add cognitive friction, documentation overhead, and noise.

I'm not saying oslo is perfect. I'm not saying that how oslo is used is
always correct. But we're fixing it, and consistency, in my mind, always
trumps ideology.

Michael

On Thu, Aug 6, 2015 at 9:02 AM Mehdi Abaakouk  wrote:

> Hi,
>
> I want to share with you some problems I have recently encountered with
> openstack middlewares and oslo.config.
>
> The issues
> --
>
> In project Gnocchi, I would use oslo.middleware.cors, I have expected to
> just put the name of the middleware to the wsgi pipeline, but I can't.
> The middlewares only works if you pass the oslo_config.cfg.ConfigOpts()
> object or via 'paste-deploy'... Gnocchi doesn't use paste-deploy, so
> I have to modify the code to load it...
> (For the keystonemiddleware, Gnocchi already have a special
> handling/hack to load it [1] and [2]).
> I don't want to write the same hack for each openstack middlewares.
>
>
> In project Aodh (ceilometer-alarm), we recently got an issue with
> keystonemiddleware since we remove the usage of the global object
> oslo_config.cfg.CONF. The middleware doesn't load its options from the
> config file of aodh anymore. Our authentication is broken.
> We can still pass them through paste-deploy configuration but this looks
> a method of the past. I still don't want to write a hack for each
> openstack middlewares.
>
>
> Then I have digged into other middlewares and applications to see how
> they handle their conf.
>
> oslo_middlewarre.sizelimit and oslo_middlewarre.ssl take options only
> via the global oslo_config.cfg.CONF. So they are unusable for application
> that doesn't use this global object.
>
> oslo_middleware.healthcheck take options as dict like any other python
> middleware. This is suitable for 'paste-deploy'. But doesn't allow
> configuration via oslo.config, doesn't have a strong config options
> type checking and co.
>
> Zaqar seems got same kind of issue about keystonemiddleware, and just
> write a hack to workaround the issue (monkeypatch the cfg.CONF of
> keystonemiddleware with their local version of the object [3] and then
> transform the loaded options into a dict to pass them via the legacy
> middleware dict options [4]) .
>
> Most applications, just still use the global object for the
> configuration and don't, yet, see those issues.
>
>
> All of that is really not consistent.
>
> This is confusing for developer to have some middlewares that need
> pre-setup,
> enforce them to rely on global python object, and some others not.
> This is confusing for deployer their can't do the configuration of
> middlewares in the same way for each middlewares and each projects.
>
> But keystonemiddleware, oslo.middleware.cors,... are supposed to be wsgi
> middlewares, something that is independant of the app.
> And this is not really the case.
>
> From my point of view and what wsgi looks like generally in python, the
> middleware object should be just MyMiddleware(app, options_as_dict),
> if the middleware want to rely to another configuration system it should
> do the setup/initialisation itself.
>
>
>
> So, how to solve that ?
> 
>
> Do you agree:
>
> * all openstack middlewares should load their options with oslo.config ?
>   this permits type checking and all other features it provides, it's cool
> :)
>   configuration in paste-deploy conf is thing of past
>
> * we must support local AND global oslo.config object ?
>   This is an application choice not something enforced by middleware.
>   The deployer experience should be the same in both case.
>
> * the middleware must be responsible of the section name in the
> oslo.config ?
>   Gnocchi/Zaqar hack have to hardcode the section name in their code,
>   this doesn't looks good.
>
> * we must support legacy python signature for WSGI object,
>   MyMiddleware(app, options_as_dict) ? To be able to use paste for
>   application/deployer that want it and not break already deployed things.

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

[Michael Krotscheck]

Well, the reasons those rules are deactivated is because they simply had no
equivalent in the previous tool, and we didn't want to force the Horizon
team to suddenly take on a far more aggressive style correction job than
they'd signed up for. Once their job goes green, I'm going to start
updating those rules one by one to slowly tighten the rules set.

With that in mind though: You can always extend the openstack rules and add
your own additional restrictions. So: Best of both worlds :), just make
sure you keep track of what's coming in from upstream.

Michael

On Tue, Jul 28, 2015 at 3:58 AM Kirill Zaitsev 
wrote:

> Thanks Michael,
> I’m actually watching this process closely, and considering switching to
> these rules, as soon as the job goes green. =)
>
> The upside of not doing so is that, since our (murano) js code base is
> significantly 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, Inc
>
> On 28 Jul 2015 at 03:00:40, Michael Krotscheck (krotsch...@gmail.com)
> wrote:
>
>  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 
> wrote:
>
>>  Since there was some interest in my side activity (which is described
>> in https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve
>> created an etherpad with files, that are yet to be cleaned up.
>>
>>  Here is the link https://etherpad.openstack.org/p/murano-escleanup
>>  So I suggest, that if you’re willing to help — add yourself in front of
>> the file you’d like to cleanup so that we would not do the same job twice.
>>
>>  When adding rule configs I try to refer to
>> https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc
>>
>>  (I’m considering switching to it completely, but that is a story for a
>> different letter =))
>>
>>  --
>> Kirill Zaitsev
>> Murano team
>> Software Engineer
>> Mirantis, Inc
>>
>> __
>> 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 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 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] [murano] eslint cleanup

[Michael Krotscheck]

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

> Since there was some interest in my side activity (which is described in
> https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve
> created an etherpad with files, that are yet to be cleaned up.
>
> Here is the link https://etherpad.openstack.org/p/murano-escleanup
> So I suggest, that if you’re willing to help — add yourself in front of
> the file you’d like to cleanup so that we would not do the same job twice.
>
> When adding rule configs I try to refer to
> https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc
>
> (I’m considering switching to it completely, but that is a story for a
> different letter =))
>
> --
> Kirill Zaitsev
> Murano team
> Software Engineer
> Mirantis, Inc
> __
> 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 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] [horizon] Minimum Unit Test Coverage

[Michael Krotscheck]

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

100% code coverage is ambitious. Let's get the tool selected and working
first.

Michael

On Wed, Jul 22, 2015 at 11:57 AM Rajat Vig  wrote:

> Hi Rob
>
> I agree. Enforcing a minimum level of coverage as a start is awesome.
>
> I must add though keeping it at 100% and breaking the build has almost
> never worked in practice for me.
> Keeping a slightly lower level ~98% is slightly more pragmatic.
> Also, the currently low coverages will have to be addressed as well.
> Is there a blueprint that can be created to tackle it?
>
> -Rajat
>
>
> On Wed, Jul 22, 2015 at 6:33 AM, Rob Cresswell (rcresswe) <
> rcres...@cisco.com> wrote:
>
>>  Hi all,
>>
>>  As far as I’m aware, we don’t currently enforce any minimum unit test
>> coverage, despite Karma generating reports. I think as part of the review
>> guidelines, it would be useful to set a minimum. Since Karma’s detection is
>> fairly relaxed, I’d put it at 100% on the automated reports.
>>
>>  I think the biggest drawback is that the tests may not be “valuable”,
>> but rather just meet the minimum requirements. I understand this sentiment,
>> but I think that “less valuable” is better then “not present” and it gives
>> reviewers a clear line to +1/ -1 a patch. Furthermore, it encourages the
>> unit tests to be written in the first place, so that reviewers can then ask
>> for improvements, rather than miss them.
>>
>>  Rob
>>
>> __
>> 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 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 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] [qa] [eslint-config-openstack] Nominating Cindy Lu for eslint-config-openstack-core

[Michael Krotscheck]

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 nominate Cindy Lu
as a core!

This will give her the power to tell you whether spaces or tabs are better.
So be warned :D

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] [Nova] The unbearable lightness of specs

[Michael Krotscheck]

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 don't mean talk about it, I mean actually
implementing and enforcing policy.

On Wed, Jun 24, 2015 at 6:30 AM Matt Riedemann 
wrote:

>
> There is the openstack-specs repo for cross-project specs:
>
> http://specs.openstack.org/openstack/openstack-specs/
>
> That'd be a good place for things like your os-vif library spec which
> requires input from both nova and neutron teams, although I think it's
> currently OK to have it in nova-specs since a lot of the forklift is
> going to come from there and we can add neutron reviewers as needed.


Let's walk through a hypothetical (because I just went through this)
example of a cross-project spec, assuming a 6 month release cycle (26
weeks), assuming one person driving a spec.

First: Overhead
- 1 week for vacation
- 1 week for holidays.
- 4 weeks for feature freeze.
- 4 weeks of pre-summit roadmap planning.
- 1 week of summit.
Remaining: 15 weeks.

Second: Writing, discussing, and landing the spec.
Taking a quick look at the most recent cross-project specs that have
merged, they seem to take between one and two months from proposal to
landing. This process involves hunting down cores from all impacted
projects, the TC, the x-project team, getting your spec onto the agenda for
discussion, making sure your spec gets proper exposure and time on the
mailing list, and more. So, let's conservatively assume it'll take 6 weeks
to land a cross-project spec, on average. Note that none of requires 40
hours a week, but it is disruptive time because you never know when someone
will be online and accessible.
Remaining: 9 weeks.

Third: Role conflicts and internal overhead.
Now let's assume that you're either a core, or a PTL, or a lead/contributor
on an internal project. Assuming that you're even permitted to work on the
spec, it's unlikely that you'll be able to dedicate your entire time to
just this particular piece. So let's conservatively estimate that between
standups, doing other reviews, discussing other code, internal work, and
shifting context, you're about 50% efficient.
Remaining time: 4.5 weeks

Writing the code:
Yay, we're coding! Let's assume that the initial code, plus tests and
dependencies, takes .5 weeks per project. In our above example, there's 2
projects involved, so that takes 1 week total.
Remaining time: 3.5 weeks.

The last step: Getting the cores to agree with your approach.
Inevitably, the approach you took can't please everyone, because technical
goals != technical implementation. Usually there's some feature you didn't
know about, or something that needs to land first, or a docimpact you
forgot about... Long story short, you lose about 2 weeks fixing your
patch per project... because there's always something.
Remaining time: -0.5 weeks.

Sorry! But the PTL just -2'd your patch because you couldn't get it in on
time. Why? Because the continuous insistence of 'discuss everything' in
OpenStack, while ethically sound, is TERRIBLE if there's no forcing
function to bring people to the table and force a decision in a timely
manner.

So, to summarize: Specs are great, because we can get an idea of the why,
the impact, etc. I don't think anyone denies the benefit of discussing
technical goals before implementation.

The problem is how long it takes.

Solutions? Frankly, I'm annoying and persistent on IRC in order to force
the PTL's to pay attention to me. It sometimes works. Many times (I'm
looking at you, PTL's and TC's) I'm ignored. However across openstack?
Personally, I believe that there's a conflict of interest between the TC
and PTL's, and the two roles should be exclusive. I believe that both TC
members and PTL's should step down if they can't dedicate 100% of their
time to their upstream role. I believe that cores, ptl's, and tc members,
have an obligation to review every patch that comes in, every morning, no
matter whether there's already a -1 on it.

But then, I'm none of these things. Turns out I like prefer pushing the
codebase forward, as frustrating as it is these days.

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] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?

[Michael Krotscheck]

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 routine, likely in the app factory. In this case, we
have tight control over the initialization order, and can make sure that
oslo.config is there first. Yay config.

- If the middleware _is_ optional, then I really feel this problem is
solved by pastedeploy's filter_factory pattern. It lets you define as many
required parameters as you want, and spits back a middleware instance. That
way you have the freedom to set whatever configuration options you want, or
omit the middleware altogether.

http://pythonpaste.org/deploy/#paste-filter-factory

Ultimately, what you should want is to ask a factory method for a thing
with some configuration options, and it spits an instance back at you. If
your project doesn't support pastedeploy, that limits your options
(ahem-ironic-ahem). Otherwise, it's really a team decision on whether
something is a 'Fundamental feature' or something that's optional.

In the case of Ceilometer? Sorry, but I think it's optional. You should be
able to run any component of openstack without ceilometer. So I don't
really think it should depend on oslo_config.

Michael

On Mon, Jun 22, 2015 at 7:59 AM Doug Hellmann  wrote:

> Excerpts from Doug Hellmann's message of 2015-06-22 10:50:06 -0400:
> > Excerpts from Sean Dague's message of 2015-06-22 09:02:02 -0400:
> > > On 06/22/2015 08:58 AM, Doug Hellmann wrote:
> > > > Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400:
> > > >> In extracting the contract for RPC backends in devstack (to have
> most of
> > > >> them live in plugins) one bit of an edge case was discovered.
> > > >>
> > > >>
> https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388
> > > >>
> > > >> The connection to the RPC mechanism from ceilometermiddleware
> inside of
> > > >> swift uses a transport url instead of an oslo.messaging config
> block.
> > > >>
> > > >> ceilometermiddleware requires oslo.config and oslo.messaging, so it
> > > >> seems like it could use an oslo config block instead.
> > > >>
> > > >> One of the reasons why this seems like a better idea is that not
> all the
> > > >> properties of a messaging connection can be encoded in just a url
> today.
> > > >> For instance, Rabbit can specify heartbeating params -
> > > >>
> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287
> ,
> > > >> and zmq needs matchmaker info -
> > > >>
> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287
> > > >>
> > > >> (Note: zmq is not currently able to be configured for swift +
> ceilometer
> > > >> today
> > > >>
> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287
> > > >> and given what it needs in it's config, it's not clear that it
> would be
> > > >> reasonable to do so.)
> > > >>
> > > >> Could we deprecate the use of tranport_url in ceilometermiddleware
> and
> > > >> move to an actual oslo.config file somewhere instead? That would
> bring
> > > >> it in line with the rest of the RPC configuration for services, and
> > > >> ensure that all connections in a cluster have access to all the same
> > > >> options.
> > > >
> > > > Swift doesn't use oslo.config, so we might need to make the
> middleware
> > > > support both configuration mechanisms.
> > >
> > > Right, but ceilometermiddleware does. Can't it load it's config from a
> > > side channel? Or is it only possible for it to load it's config from
> the
> > > same file as swift?
> >
> > Library code that uses oslo.config relies on having an initialized
> > configuration object, which means something has specified the files
> > to be loaded, handled command line argument parsing, etc. We wouldn't
> > want the middleware doing that, because doing it properly requires
> > knowing the name of the application it's running in and what some
> > of the application-specific defaults should be, and those are usually
> > best left to the application.
>
> We had a similar issue with the CORS middleware needing a config object.
> Perhaps we need a piece of middleware to set up the config using
> parameters coming in from the paste.ini (application, name, default
> config file, etc.). If that middleware sets up the global config
> instance, other middleware could be written to rely on it being earlier
> in the pipline.
>
> Doug
>
> __
> 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 Development Mailing List (not for usage 

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

[Michael Krotscheck]

gt;
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a
> dashboard for Ironic
>
>
>
> Hi Zhengou,
>
>
>
> I think it make sense to start with the angular version. It's true that we
> don't have an angular dashboard yet,
>
> but we have a pretty good idea of what needs to go into it. I'll link a
> few patches that will give you an idea
>
> of where we are headed. I think this will also save you some work in the
> long run.
>
>
>
> For creating a new dashboard: https://review.openstack.org/#/c/190852/
>
> For creating a new panel: https://review.openstack.org/#/c/190865/
>
> For demo patch: https://review.openstack.org/#/c/181253/
>
>
>
> The file and code structure I would say is pretty stable.
>
> There are still some infra stuff that needs to happen to make this easier
> to do.
>
> Things like translation in static HTML, auto discovery of static files,
> start dash for angular, etc...
>
>
> -niuzhenguo  wrote: -
>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> From: niuzhenguo 
> Date: 06/17/2015 06:38PM
> Subject: Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a
> dashboard for Ironic
>
> Hi Krotscheck,
>
>
>
> Sorry for not attending the last meeting due to TZ.
>
>
>
> Yes, Horizon is moving towards an Angular application, but for now there’s
> no any Angular Dashboard landed. I think it’s high time that we should make
> a standard for other projects which want to horizon compatible on whether
> they should based on Angular Dashboard or the current Horizon framework.
> This is important for 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 if I
> missed something), and seems there’s no any update over a month, are you
> planning to push you repo to stackforge or openstack?
>
>
>
> Anyway, it’s clear that we should make an Ironic dashboard, it’s a good
> start.
>
>
>
>
>
> Regards
>
> -zhenguo
>
>
>
> *From:* Michael Krotscheck [mailto:krotsch...@gmail.com
> ]
> *Sent:* Wednesday, June 17, 2015 11:56 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* 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 the
> end goal being a maximum amount of code reusability between the standalone
> UI and Horizon. While it may not appear that way, I _am_ actively working
> on this project, though I'm currently focused on javascript infrastructure
> tooling and oslo middleware than the ironic webclient itself.
>
>
>
> With Horizon also moving towards an angular application, I feel it makes
> far more sense to build components for the "new" Horizon than the old one.
>
>
>
> Michael
>
>
>
> On Tue, Jun 16, 2015 at 9:02 PM NiuZhenguo 
> wrote:
>
>  hi folks,
>
>
>
> I'm planning to propose a new horizon plugin ironic-dashboard to fill the
> gap that ironic doesn't have horizon support. I know there's a nodes panel
> on "infrastructure" dashboard handled by tuskar-ui, but it's specifically
> geared towards TripleO. Ironic needs a separate dashboard to present an
> interface for querying and managing ironic's resources (Drivers, Nodes, and
> Ports).
>
>
>
> After discussion with the ironic community, I pushed an ironic-dashboard
> project to stackforge [1].
>
>
>
> Also there's an existing JS UI for ironic in developing now [2], we may
> try to resolve the same goals, but as an integrated openstack project,
> there's clear needs to have horizon support.
>
>
>
> I'd like to get what's your suggestion, thanks in advance.
>
>
>
>
>
> [1] https://review.openstack.org/#/c/191131/
>
> [2] https://github.com/krotscheck/ironic-webclient
>
>
>
>
>
> Regards
>
> -zhenguo
>
> __
> OpenStack Development Mailing List (no

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

[Michael Krotscheck]

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 the
end goal being a maximum amount of code reusability between the standalone
UI and Horizon. While it may not appear that way, I _am_ actively working
on this project, though I'm currently focused on javascript infrastructure
tooling and oslo middleware than the ironic webclient itself.

With Horizon also moving towards an angular application, I feel it makes
far more sense to build components for the "new" Horizon than the old one.

Michael

On Tue, Jun 16, 2015 at 9:02 PM NiuZhenguo 
wrote:

> hi folks,
>
> I'm planning to propose a new horizon plugin ironic-dashboard to fill the
> gap that ironic doesn't have horizon support. I know there's a nodes panel
> on "infrastructure" dashboard handled by tuskar-ui, but it's specifically
> geared towards TripleO. Ironic needs a separate dashboard to present an
> interface for querying and managing ironic's resources (Drivers, Nodes, and
> Ports).
>
> After discussion with the ironic community, I pushed an ironic-dashboard
> project to stackforge [1].
>
> Also there's an existing JS UI for ironic in developing now [2], we may
> try to resolve the same goals, but as an integrated openstack project,
> there's clear needs to have horizon support.
>
> I'd like to get what's your suggestion, thanks in advance.
>
>
> [1] https://review.openstack.org/#/c/191131/
> [2] https://github.com/krotscheck/ironic-webclient
>
>
> Regards
> -zhenguo
>  __
> 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 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] [horizon] [merlin] [refstack] Javascript Linting

[Michael Krotscheck]

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 an openstack linting plugin,
which enforce things like "Do not use fuzzy versions in your package.json"
and other things that make things unstable. That should be a very carefully
reserved list of rules though.

I've created an eslint configuration file that includes every single rule,
it's high level purpose, and a link to the details on it, and provided it
in a patch against horizon. The intent is that it's a good starting point
from which to activate and deactivate rules that make sense for horizon.

https://review.openstack.org/#/c/192327/


> We’ve spent a good portion of liberty 1 getting the code base cleaned up
> to meet the already adopted horizon rules and it is still in progress.
>

As a side note, the non-voting horizon linting job for javascript things is
waiting for review here: https://review.openstack.org/#/c/16/

My preference would be to see if we can use eslint to accomplish all of
> our currently adopted horizon rules [3][4] AND to also add in the angular
> specific plugin [1][2]. But we can’t do this at the expense of the entire
> liberty release.
>

Again, I agree. The patch I've provided above sets up the horizon eslint
build, and adds about... 10K additional style violations. Since neither of
the builds pass, it's difficult to see the difference, yet either way you
should probably tweak the rules to match horizon's personal preferences.

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] [horizon] [merlin] [refstack] Javascript Linting

[Michael Krotscheck]

Just for the sake of clarity- did the Horizon team discuss the tool
selection for JSCS with the greater community? I can't find anything on the
dev list. Furthermore, there've been situations before (karma) where a
patch was landed without appropriate upstream notifications and/or
discussion, which then resulted in a lot of unnecessary work.

Horizon isn't the only UI project anymore. While it's certainly the
elephant in the room, that doesn't mean its decisions shouldn't be up to
scrutiny.

Michael

On Tue, Jun 16, 2015 at 12:44 AM Rob Cresswell (rcresswe) <
rcres...@cisco.com> wrote:

>  So my view here is that I don’t particularly mind which plugin/ set of
> plugins Horizon uses, but the biggest deterrent is the workload. We’re
> already cleaning everything up quite productively, so I’m reluctant to
> swap. That said, the cleanup from JSCS/ JSHint should be largely relevant
> to ESLint. Michael, do you have any ideas on the numbers/ workload behind a
> possible swap?
>
>  With regards to licensing, does this mean we must stop using JSHint, or
> that we’re still okay to use it as a dev tool? Seems that if the former 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 Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [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 need for common formatting rules to
> be self-evident. Here's the lay of the land so far:
>
>- Horizon currently uses JSCS.
>- Refstack uses Eslint.
>- Merlin doesn't use anything.
>- StoryBoard (deprecated) uses eslint.
>- Nobody agrees on rules.
>
>  *JSCS*
>  JSCS Stands for "JavaScript CodeStyle". Its mission is to enforce a
> style guide, yet it does not check for potential bugs, variable overrides,
> etc. For those tests, the team usually defers to (preferred) JSHint, or
> ESLint.
>
>  *JSHint*
> Ever since JSCS was extracted from JSHint, it has actively removed rules
> that enforce code style, and focused on findbug style tests instead. JSHint
> still contains the "Do no evil" license, therefore is not an option for
> OpenStack, and has been disqualified.
>
>  *ESLint*
> ESLint's original mission was to be an OSI compliant replacement for
> JSHint, before the JSCS split. It wants to be a one-tool solution.
>
>  My personal opinion/recommendation: Based on the above, I recommend we
> use ESLint. My reasoning: It's one tool, it's extensible, it does both
> codestyle things and bug finding things, and it has a good license. JSHint
> is disqualified because of the license. JSCS is disqualified because it is
> too focused, and only partially useful on its own.
>
>  I understand that this will mean some work by the Horizon team to bring
> their code in line with a new parser, however I personally consider this to
> be a good thing. If the code is good to begin with, it shouldn't be that
> difficult.
>
>  This thread is not there to argue about which rules to enforce. Right
> now I just want to nail down a tool, so that we can (afterwards) have a
> discussion about which rules to activate.
>
>  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
>
__
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] [horizon] [merlin] [refstack] Javascript Linting

[Michael Krotscheck]

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 need for common formatting rules to be
self-evident. Here's the lay of the land so far:

   - Horizon currently uses JSCS.
   - Refstack uses Eslint.
   - Merlin doesn't use anything.
   - StoryBoard (deprecated) uses eslint.
   - Nobody agrees on rules.

*JSCS*
JSCS Stands for "JavaScript CodeStyle". Its mission is to enforce a style
guide, yet it does not check for potential bugs, variable overrides, etc.
For those tests, the team usually defers to (preferred) JSHint, or ESLint.

*JSHint*
Ever since JSCS was extracted from JSHint, it has actively removed rules
that enforce code style, and focused on findbug style tests instead. JSHint
still contains the "Do no evil" license, therefore is not an option for
OpenStack, and has been disqualified.

*ESLint*
ESLint's original mission was to be an OSI compliant replacement for
JSHint, before the JSCS split. It wants to be a one-tool solution.

My personal opinion/recommendation: Based on the above, I recommend we use
ESLint. My reasoning: It's one tool, it's extensible, it does both
codestyle things and bug finding things, and it has a good license. JSHint
is disqualified because of the license. JSCS is disqualified because it is
too focused, and only partially useful on its own.

I understand that this will mean some work by the Horizon team to bring
their code in line with a new parser, however I personally consider this to
be a good thing. If the code is good to begin with, it shouldn't be that
difficult.

This thread is not there to argue about which rules to enforce. Right now I
just want to nail down a tool, so that we can (afterwards) have a
discussion about which rules to activate.

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

[Michael Krotscheck]

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
> > compelling reason to use something that has the infamous "do no evil"
> > license in it, let's dump it.
> ...
> > As for how this is synchronized, a brief discussion in the infra channel
> > proposed that we put global javascript requirements in the
> > global-requirements repo, and then update the update.py script in that
> repo
> > to also handle bower.json and package.json. Then, if we build an
> eslint/jscs
> > plugin similar to our hacking rules, we can just update that when we
> want to
> > modify the linting rules. Any objections?
>
> Yes, I think this should live in openstack/requirements.
>
> bower.json is clearly js specific; package.json isn't AFAICT - can you
> give me some sane pointers to go level up on that?
>

There are two package managers in the JavaScript world right now, one that
focuses on node.js/server dependencies (karma, lint, express, etc), and one
that focuses on in-browser dependencies (angular, bootstrap, etc). They're
both required for thick browser clients, but for server apps you only
really need package.json

https://docs.npmjs.com/files/package.json
https://github.com/stackforge/refstack/blob/master/refstack-ui/package.json
https://github.com/angular-ui/bootstrap/blob/master/package.json
https://github.com/openstack/horizon/blob/master/package.json


> In the absence of information I'm assuming we should make a subdir
> 'js' and put bower.json and package.json in there (and do the same for
> the python things in a subdir called python for symmetry, though
> backwards compat and tooling considerations may mean that we have to
> prepare for that. The reason being that if package.json is js
> specific, its just confusing to have it live at the top level. Also we
> may want to call them global-$thing, since if we do have js in the
> requirements repo itself at some point, it would be good not to
> conflict on names.
>

FYI, it looks like the monasca team may want to start doing similar things
with Java. More information after I hunt them down this morning :)


> I'm not at all sure that update.py should handle the json files per
> se; will the policy for those files be the same as we use for python?
>

Add linting rule sets to this list, contained either in .jscsrc or
.eslintrc. Javascript does not have the privilege of pep8 being baked into
the language tooling, so we have to sync it ourselves.


> If not it might be cleaner to have a new entry point. OTOH I'll need
> to look closely at a few real {bower,package}.json files to proffer an
> useful opinion. [Perhaps you covered this in IRC - it didn't come
> through in your summary].
>

It depends on what you think update.py is supposed to do. If I look at that
repository, I would argue that the purpose is to "Synchronize common files
and properties across registered openstack projects". In this case, a
"requirement" is defined as something required to meet a minimum set of
project "sanity" standards.

Also, I'm in the middle of rearranging update.py to handle PEP 426 and so
> we should probably coordinate so we don't tromp on each other.
>

Do you have a patch?

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

[Michael Krotscheck]

The more I think about this, the more I think my ideas are dumb.

John Papa has very opinionated guides on how an _angular_ application
should be structured. Openstack's linting must be framework agnostic,
because we can't predict which frameworks may or may not be used. For
example, 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 
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 compelling reason to use something that has the infamous "do no evil"
> license in it, let's dump it.
>
> The John Papa styles seem sane, and though I disagree with them, I'd be ok
> using them. Putting everything in a closure is an old standard that has
> usually just annoyed me, since it's one of those things about javascript
> that _shouldn't_ have to be explicit, but no language is perfect ;). The
> existing eslint stylesheets that exist in StoryBoard and others were
> written with PEP8 in mind, in order to facilitate readability between our
> languages, however I am also a strong believer in treating JavaScript on
> equal terms with other languages. Also, John papa seems to have more
> opinions about angular apps than javascript in general, so I propose this
> rule for OpenStack going forward:
>
> 1- If the John Papa rules have an opinion, use that.
> 2- Otherwise, use pep8 (where applicable).
> 3- Otherwise, check to see if there's a thing in hacking.
> 4- If it's in none of those, we'll address it on a case by case basis.
>
> The main reasons for this is that I simply do not want to have an argument
> about spaces vs. tabs. The arguments about PEP8 have already been had, and
> the benefits of a language-wide enforced style are simple: We can argue
> about more important things! :). Let's assume a week of commentary on the
> above.
>
> As for how this is synchronized, a brief discussion in the infra channel
> proposed that we put global javascript requirements in the
> global-requirements repo, and then update the update.py script in that repo
> to also handle bower.json and package.json. Then, if we build an
> eslint/jscs plugin similar to our hacking rules, we can just update that
> when we want to modify the linting rules. Any objections?
>
> With regards to JSCS vs. Eslint, I feel that we actually have to use both
> to decide which is better: Once we set up the rules side by side and try to
> apply them against a project, a clear winner will emerge. Does anyone want
> to volunteer to put together a spreadsheet of all the rules from John Papa
> and pep8 that we'd like to enforce, and the appropriate rule in eslint
> and/or jscs that applies?
>
> Michael
>
> On Mon, Jun 8, 2015 at 9:57 PM Tripp, Travis S 
> wrote:
>
>> We¹ve adopted the John Papa style guide for Angular in horizon [0]. On
>> cursory inspection ES lint seems to have an angular specific plugin [1]
>> that could be very useful to us, but we¹d need to evaluate it in depth. It
>> looks like there was some discussion on the style guide on this not too
>> long ago [2]. The jscs rules we have [3] are very generic code formatting
>> type rules that are helpful, but don't really provide any angular specific
>> help. Here are the jshint rules [4]. It would be quite nice to put all
>> this goodness across tools into a single tool configuration if possible.
>>
>> [0]
>>
>> http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty
>> le-guide
>> <http://docs.openstack.org/developer/horizon/contributing.html#john-papa-style-guide>
>> [1] https://www.npmjs.com/package/eslint-plugin-angular
>> [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:
>>
>> >
>> >
>> >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 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?
>> 

Re: [openstack-dev] [javascript] Linters

[Michael Krotscheck]

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 compelling reason to use something that has the infamous "do no evil"
license in it, let's dump it.

The John Papa styles seem sane, and though I disagree with them, I'd be ok
using them. Putting everything in a closure is an old standard that has
usually just annoyed me, since it's one of those things about javascript
that _shouldn't_ have to be explicit, but no language is perfect ;). The
existing eslint stylesheets that exist in StoryBoard and others were
written with PEP8 in mind, in order to facilitate readability between our
languages, however I am also a strong believer in treating JavaScript on
equal terms with other languages. Also, John papa seems to have more
opinions about angular apps than javascript in general, so I propose this
rule for OpenStack going forward:

1- If the John Papa rules have an opinion, use that.
2- Otherwise, use pep8 (where applicable).
3- Otherwise, check to see if there's a thing in hacking.
4- If it's in none of those, we'll address it on a case by case basis.

The main reasons for this is that I simply do not want to have an argument
about spaces vs. tabs. The arguments about PEP8 have already been had, and
the benefits of a language-wide enforced style are simple: We can argue
about more important things! :). Let's assume a week of commentary on the
above.

As for how this is synchronized, a brief discussion in the infra channel
proposed that we put global javascript requirements in the
global-requirements repo, and then update the update.py script in that repo
to also handle bower.json and package.json. Then, if we build an
eslint/jscs plugin similar to our hacking rules, we can just update that
when we want to modify the linting rules. Any objections?

With regards to JSCS vs. Eslint, I feel that we actually have to use both
to decide which is better: Once we set up the rules side by side and try to
apply them against a project, a clear winner will emerge. Does anyone want
to volunteer to put together a spreadsheet of all the rules from John Papa
and pep8 that we'd like to enforce, and the appropriate rule in eslint
and/or jscs that applies?

Michael

On Mon, Jun 8, 2015 at 9:57 PM Tripp, Travis S  wrote:

> We¹ve adopted the John Papa style guide for Angular in horizon [0]. On
> cursory inspection ES lint seems to have an angular specific plugin [1]
> that could be very useful to us, but we¹d need to evaluate it in depth. It
> looks like there was some discussion on the style guide on this not too
> long ago [2]. The jscs rules we have [3] are very generic code formatting
> type rules that are helpful, but don't really provide any angular specific
> help. Here are the jshint rules [4]. It would be quite nice to put all
> this goodness across tools into a single tool configuration if possible.
>
> [0]
> http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty
> le-guide
> <http://docs.openstack.org/developer/horizon/contributing.html#john-papa-style-guide>
> [1] https://www.npmjs.com/package/eslint-plugin-angular
> [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:
>
> >
> >
> >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 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?
> >
> >what about https://bitbucket.org/dcs/jsmin/ it's license is free
> >
> >
> >--
> >1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
> >
> >keybase: http://keybase.io/gfa
> >
> >__
> >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 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 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] Linters

[Michael Krotscheck]

Hey there, Gustavo-

JSMin's a minifier, not a linter, yes? Unless I'm wrong, we're discussing
the enforcement of code style rather than the concatenation step in our
build, and thus jsmin's not really in the running. Once we _do_ talk about
how we assemble javascript, I'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 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?
>
> what about https://bitbucket.org/dcs/jsmin/ it's license is free
>
>
> --
> 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333
>
> keybase: http://keybase.io/gfa
>
> __
> 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 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] Linters

[Michael Krotscheck]

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.


> jscs seems to be the utility, cool kids are using. As expected, it
> requires node. It has seen 3 releases within 3 months, or 5 in 4 months.
>

Google trends disagrees with this assertion:
https://www.google.com/trends/explore#q=eslint%2C%20jscs%2C%20jshint%2C%20jslint&cmpt=q&tz=

Also, as a random aside, I have read things On The Internet (tm) that say
that eslint is better about doing PMD things like scope variable overrides
and unused parameters. Not having used JSCS, I can't really comment.

My question here would be: how are we going to handle changes here over a
> release (and how to keep this running on the gate for released
> versions)?
> 
>

The required version of eslint is actually defined per project, in
package.json. As long as the project does NOT use fuzzy version matching
(~1.x.x), the build should remain reliable.

Furthermore, all 'lint' builds are abstracted behind the `npm run lint`
command, and is definable by project, so specific changes to the linting
configuration are committed to the codebase. Here's an example:
https://review.openstack.org/#/c/185711/5/refstack-ui/package.json

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

[openstack-dev] [javascript] Linters

[Michael Krotscheck]

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?

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

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

[Michael Krotscheck]

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 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] Summit Conversation Continued

[Michael Krotscheck]

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 be
raising each new item for discussion.

To preface this conversation, assume that you are a slightly schizophrenic
engineer named Pat, who has been told be the Powers That Be to implement an
Ironic UI. The requirements are listed here:
https://etherpad.openstack.org/p/modern-javascript-vancouver-requirements-2015

Decisions made so far:

   - *Language: ECMA5 Javascript* (disqualified were ECMA6, Coffeescript,
   Typescript).
   - *Styling Language: SASS/SCSS* (Disqualified were LESS, raw CSS)
   - *What platform do we target: Browser* (Disqualified was Node.js,
   and/or both)
   - *What platform do we test against: Firefox, Chromium, PhantomJS*
   (Note: Let's talk to Microsoft to see if they're willing to help with 3rd
   party testing)
   - *What testing libraries do we use: Jasmine.* (Disqualified were QUnit,
   YUITest, Mocha)
   - *What test runner do we use: UNDECIDED*
   - *What unit test output do we generate: HTML is fine, subunit
   preferred.*
   - *What coverage requirements do we target: 100%*
   - *How do we test UX Changes: Gate-based ui drafts.*
   - *How do we build Documentation: Sphinx* (Disqualified were ngDoc,
   jsDoc).

The next discussion point is that of "What parts of this app are reusable",
and it's the first that goes into application design (which is why we never
got to it at the summit). Its purpose is to determine where a sane split
might be between common not-openstack things, common openstack things,
common ironic things, and specific ironic UI things.

So, Pat: What parts of your application are reusable?

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

[openstack-dev] Resigning as StoryBoard-Core

[Michael Krotscheck]

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 meets
OpenStack's needs.

The discussion of whether to continue working on StoryBoard, and what to
replace it with, had similarly been halted, with me being told explicitly
that a decision would be made in Vancouver.

The session during which the decision was to be made just concluded, and
the "decision" was to continue maintaining StoryBoard in a Status Quo mode
until we can evaluate alternatives. These alternatives had been under
evaluation since April. In short, the future of StoryBoard continues to
remain uncertain, and I, as sole remaining active contributor, am again
left hanging.

I am resigning, effective immediately, as StoryBoard Core, and will no
longer contribute to the project. This moves the number of active
contributors to the project to zero, effectively killing it. I also propose
that storyboard, storyboard-webclient, and puppet-storyboard are
immediately moved to the attic, as without contributors, there is no real
narrative in which it could continue to live on its own.

Now that StoryBoard is no longer a viable alternative in the Task Tracking
discussion, I trust that the TC and Infra team will come to a quick
resolution on the topic.

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] [Horizon]Informal Pre-summit get together

[Michael Krotscheck]

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, Travis S" 
> wrote:
> >
> > Just to double check, there was some IRC discussion about Monday.  So is
> > it still Sunday?
> >
> >> On 5/14/15, 3:41 PM, "Douglas Fish"  wrote:
> >>
> >>
> >> The Horizon team will be meeting on Sunday night informally over a beer
> >> and
> >> dinner:
> >> Sunday 6pm @  The Charles Bar http://thecharlesbar.ca/
> >>
> >> Hope to see you there!
> >>
> >> Doug
> >>
> >>
> >>
> __
> >> 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 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 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 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] [Horizon] Horizon Usage Survey Results

[Michael Krotscheck]

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 participated,
THANK YOU! It's awesome to see all this come together.

The current summary of findings is published here:
http://www.krotscheck.net/2015/05/15/horizon-usage-survey.html

Feel free to find me at the summit (around the HP booth during the booth
crawl), or reach out to me either here via discussion, on IRC as
krotscheck, or via email if you have any additional questions.

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

[Michael Krotscheck]

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 it
> again, and hope that it wont happen again:
>
> When releasing anything using the MIT license, we *MUST* also ship the
> license itself, or otherwise, this is a license violation:
>
> "The above copyright notice and this permission notice shall be included
> in all copies or substantial portions of the Software."
>
> Jordan, you're marked as the maintainer of angular-fileupload. Please
> fix the xstatic repository at
> https://github.com/danialfarid/ng-file-upload. Also, please get this
> release tagged.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> P.S: The frustration builds up here, as that's a reoccurring issue. It'd
> be nice to not just add anything to the global-requirements.txt without
> further checking of licensing, and that the stackforge repository is
> properly tagged as well...
>
> __
> 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 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] [Security] CORS Documentation

[Michael Krotscheck]

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 this, and at Anne Gentle's suggestion I'd
like some suggestions on where this might live. It will definitely live in
the Cloud Admin guide - are there any other places where I should make a
point to highlight these issues?

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] [oslo] Adding Joshua Harlow to oslo-core

[Michael Krotscheck]

++!

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, tooz…) and
> > he's helping on a lot of other ones for a while now. Let's bring him in
> > for real!
> >
> > --
> > Julien Danjou
> > -- Free Software hacker
> > -- http://julien.danjou.info
> >
> >
> __
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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 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] [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

[Michael Krotscheck]

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 statement, or even better, a proof?
>

In the interest of open data, I'll answer this, using basic data extracted
from the Paris User Survey. For the sake of simplicity, I'm only going to
focus on production deployments of openstack, and I'm going to make the
assumption that if a tool is referenced, the official openstack version of
it was used. Here's the link, if you'd like to follow along:

http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014

As of Paris, the following tools were used to deploy openstack-dashboard in
production.  I've called out which of these are actually a source install,
and which of them are not. I've also skipped the two 1%'ers, because I
don't know those tools well enough to figure out if they're source.

ToolPercentageIs Source?Is Package?Puppet45%NoYesChef20%NoYesAnsible21%NoYes
DevStack7%Yes NoPackStack8%NoYesSalt8%NoYesJuju7%NoYes

As you can see, the majority of the tools that we publish install via
packages. Note that this data _cannot_ be used to infer an argument as to
whether source or packages are used more often, for the following reasons:

   1. The actual percentages from the survey add up to 118%.
   2. "Install from Source" did not appear to be an option.
   3. We are unable to determine the size of the cloud, thus providing a
   'weight' to each install method.
   4. We do not know whether every one of these respondents actually
   install horizon.

In short: We don't have data to support either side of this argument,
though there is a strong case that packages are the de-facto install method.

If I can editorialize for a second and read subtext into what Ian's saying:
The real question seems to be whether packagers have a disproportionate
amount of power to set development goals, tools, and policy. This is a
common theme that I've encountered frequently, and it leads to no small
amount of tension.

This tension serves no-one, and really just causes all of us stress. How
about we start a separate thread to discuss the roles of package
maintainers in OpenStack?

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

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

[Michael Krotscheck]

Paging David Lyle!

We're trying to nail down exactly what work needs to be done on the Karma
patch to get your approval and avoid further frustrating patch churn. Could
you take a moment to respond to Matt's question, and/or discuss here what
you're looking for? We tried pinging 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 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] [all] Question for the TC candidates

[Michael Krotscheck]

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


OpenStack needs to become as boring as possible.

Clouds, to me, are plumbing. They're not themselves interesting, rather
they are the platforms upon which interesting things are built. And they
shouldn't be, either! Use hardware as an analogy: The RJ-45 connector is
ubiquitous for physical network connections. If each manufacturer used
something different, you'd soon be spending all your time soldering
adapters, and the last thing I want our operators, developers, or customers
to do is waste their time doing the cloud-equivalent.

Example: Pep8 is boring. Benefit: We don't waste time arguing about tabs
vs. spaces anymore.

The TC can set policies that encourage being boring. It's the closest we
have to an ISO standards board, and while the TC has no real power to
mobilize resources to build things, it can advise and encourage adoption of
policies and standards. Some examples include: Test Coverage standards,
common middleware, consistent API standards... you get the idea. The more
boring OpenStack becomes, the easier it will be to work on, operate, and
talk about.

As for myself: I'm going to focus on making UI projects as boring as
possible. This includes lots of things, so let me get into specifics:
- Creating, and encouraging the use of, common middleware that encapsulates
existing RFC's and standards which support UI development (CORS, Common
Auth, etc.)
- Researching, Drafting, Proposing, and Shepherding policies for UI
development that involve all stakeholders, including upstream and
downstream engineers, Package Maintainers, and operators.
- Creating the tools that will allow us to publish UI libraries to the
global community (mostly JS, we've got the Python part handled).
- Getting involved in UI tooling projects (Node, Sass, etc) and advocating
a more enterprise-supportive approach to topics like security, package
signing, package structures, audit trails, and distribution.

That about sums it up. Have a nice day!

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

[openstack-dev] TC Candidacy

[Michael Krotscheck]

Hi everyone!

I'd like to announce my own candidacy for the OpenStack Technical
Committee. My TL/DR platform is: "Represent Front-End Engineering". It's
what I do, it's what I love, it's what I've been doing for the last 15
years, and it's what I want to keep doing for years to come.

Would you like some details? Of course you would!

*First: Represent Front-End Engineering on the TC.*

To me, this means being an advocate to everyone who touches the things
which people use to interact with OpenStack; CLI, Web UI, etc. From the
engineers working on upstream projects such as Fuel, Refstack, Ironic-UI,
Horizon, and StoryBoard, to the UI Developers downstream who are developing
their own tools, I strongly feel this branch of our profession should be
represented, and I would like to be that representative.

*Second: Advocate ease-of-use across OpenStack.*

I don't only mean pretty buttons - I also mean how easy the CLI clients
are, how intuitive the API's are, and how easy it is to onboard and/or
support your own engineering efforts. You can have all the feature support
in the world, but if it's not easy to use, you're doomed out of the gate.

*Third: Make JavaScript a first-class citizen.*

Yep, _this_ can of worms! Between the projects mentioned above, it's pretty
clear that JavaScript is here to stay. With that in mind there remain many
problems with the tooling, and we need to be conscious of those
shortcomings as we start to draft policies that support the needs of all
stakeholders: OpenStack's components, Engineers both downstream and
upstream, Package Maintainers, and most importantly Operators and their
Customers.

*My qualifications:*

I've been active in the OpenStack community for about 18 months now,
working on Monty Taylor's team here at HP on trying to get StoryBoard to
the point where it can replace Launchpad. I'm more-or-less responsible for
all things NodeJS, NPM, Selenium, and Browser on infra, basically
everything you need to build and test a Web UI. I've recently 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 experience as a UI engineer, and a scant year of
experience as a UX researcher.

Michael Krotscheck
__
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] [Zaqar] Call for adoption (or exclusion?)

[Michael Krotscheck]

That's what I needed to know, thanks :)

Michael

On Mon, Apr 20, 2015 at 12:11 PM Fox, Kevin M  wrote:

> Another parallel is Manilla vs Swift. Both provides something like a share
> for users to store files.
>
> The former is a multitenant api to provision non multitenant file shares.
> The latter is a multitenant api to provide file sharing.
>
> Cue is a multitenant api to provision non multitenant queues.
> Zaqar is an api for a multitenant queueing system.
>
> They are complimentary services.
>
> Thanks,
> Kevin
> 
> 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'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 understanding of the projects is correct, the latter is far more
> > versatile, and more in line with similar openstack approaches like
> > trove. Is there a use case nuance I'm not aware of that warrants
> > duplicating efforts? Because if not, one of the two should be retired
> > and development focused on the other.
> >
> > Note: I do not have a horse in this race. I just feel it's strange that
> > we're building a thing that can be provisioned by the other thing.
> >
>
> Well, with Trove you can provision databases, but the MagnetoDB project
> still provides functionality that trove won't.
>
>
> The Trove : MagnetoDB and Cue : Zaqar comparison fits well.
>
> Trove provisions one instance of X (some database) per tenant, where
> MagnetoDB is one "instance" (collection of hosts to do database things)
> that serves many tenants.
>
> Cue's goal is "I have a not-very-multitenant message bus (rabbit, or
> whatever)" and makes that multitenant by provisioning one per tenant,
> while Zaqar has a single install (of as many machines as needed) to
> support messaging for all cloud tenants. This enables great stuff like
> cross-tenant messaging, better physical resource utilization in
> sparse-tenant cases, etc.
>
> As someone who wants to adopt Zaqar, I'd really like to see it continue
> as a project because it provides things other message broker approaches
> don't.
>
> --
> Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
>
> __
> 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 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 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] [Zaqar] Call for adoption (or exclusion?)

[Michael Krotscheck]

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 understanding of the projects is correct, the latter is far more
versatile, and more in line with similar openstack approaches like trove.
Is there a use case nuance I'm not aware of that warrants duplicating
efforts? Because if not, one of the two should be retired and development
focused on the other.

Note: I do not have a horse in this race. I just feel it's strange that
we're building a thing that can be provisioned by the other thing.

Michael

On Mon, Apr 20, 2015 at 6:00 AM Flavio Percoco  wrote:

> Greetings,
>
> I'd like my first action as Zaqar's PTL to be based on reflections and
> transparency with regards to what our past has been, to what our
> present is and to what our future could be as a project and community.
> Therefore, I'm sending this call for adoption and support before
> taking other actions (also mentioned below).
>
> The summit is very close and the Zaqar team is looking forward to it.
>
> The upcoming summit represents an important opportunity for Zaqar to
> integrate with other projects. In the previous summits - since
> Icehouse's - we've been collecting feedback from the community. We've
> worked on addressing the many use-cases, we've worked on addressing
> the concerns raised by the community and we've also kept moving
> towards reaching the project's goals.
>
> As you all know, the project has gone through many ups and downs.
> We've had some "failures" in the past and we've also had successes, as
> a project and as a team. Nevertheless, we've got to the point where it
> doesn't make much sense to keep pushing new features to the project
> until it gains adoption. Therefore, I'd like to take advantage of the
> workshop slots and invite people from other projects to help us/guide
> us through a hacking session on their projects so we can help with the
> adoption. The current adoption of Zaqar consist in:
>
> - 1 company reachingunning it in production
> - 1 planning to do it soon
> - RDO support
>
> Unfortunately, the above is certainly not enough for a project to
> succeed and it makes the time and effort spent on the project not
> worth it. It's been more than 2 years since we kicked the project off
> and it's time for it to show some results. The current problem seems
> to be that many people want the project but no one wants to be the
> first in adopting Zaqar (which kind of invalidates the premises of the
> "Big tent").
>
> In summary, this is a call for adoption before we call it a nice
> adventure and ask for the project to be excluded from the OpenStack
> organization based on the lack of adoption and contributions.
>
> If you think it's worth it, speak up. Either way, thanks for the
> support and for reading thus far.
>
> On behalf of the Zaqar team,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
> __
> 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 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