Blocking the acceptance of new projects seems punitive and against the spirit
of the big tent. Classification (tagging) can be done at any point, and is
hardly fixed in stone. You can refine tags as needed.
To put it harshly: it is a failure of both leadership and process to have
stripped out
As the former Horizon PTL, I have a great respect for the importance of the
contributions the distro maintainers/developers make to Horizon and OpenStack
as a whole. From how many bugs the distros manage to find, to their diligence
in vetting the software that we as Horizon developers provide,
Two things of note, having been doing heavy javascript development over the
past couple years:
1) NPM actually resolves conflicts in a dependency tree. Unlike Python, it can
ensure that if different packages declare conflicting versions, each one gets
the version it requested. And conflicting
I have no familiarity with stacktach, but it sounds like it's trampling data on
the sessionid cookie (even if it's also setting a beaker.session.stacktach
cookie).
Your options include running the two at different domains/subdomains (and
specifying the subdomain as the cookie domain; that
SQLite doesn't introduce any additional dependencies, memcached requires
installation of memcached (admittedly it's not hard on most distros, but it
*is* yet another step) and in most cases the installation of another python
module to interface with it.
Memcached might be a good choice for
All in all this is been a long time coming. The cookie-based option was useful
as a batteries-included, simplest-case scenario. Moving to SQLite is a
reasonable second choice since most systems Horizon might be deployed on
support sqlite out of the box.
I would make a couple notes:
1)
This is generally the right plan. The hard parts are in getting people to
deploy it correctly and securely, and handling fallback cases for lack of
browser support, etc.
What we really don't want to do is to encourage people to set
Access-Control-Allow-Origin: * type headers or other such
I would also like to add that incubated != integrated. There's no telling how
long a project may stay in incubation or how many changes it may undergo before
it's deemed ready (see David's reasoning around client changes during RC's).
While the Horizon team has always made every effort to work
I've implemented Kerberos (via Apache) + Django once before, and yes, taking
this as pseudo-code you're on the right track. Obviously the devil is in the
details and you'll work out the particulars as you go.
The most important bit (obviously) is just making absolutely sure your
REMOTE_USER
[mailto:ayo...@redhat.com]
Sent: Wednesday, June 04, 2014 12:43 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Kerberization of Horizon (kerbhorizon?)
On 06/04/2014 03:10 PM, Gabriel Hurley wrote:
I've implemented Kerberos (via Apache) + Django once before, and yes, taking
Forgive me if I'm misunderstanding, but those all look like repositories that
are strictly tracking upstreams. They're not maintained by the
Horizon/OpenStack developers whatsoever. Is this intentional/necessary?
- Gabriel
-Original Message-
From: Anita Kuno
It's sort of a silly point, but as someone who would likely consume the
split-off package outside of the OpenStack context, please give it a proper
name instead of django_horizon. The module only works in Django, the name
adds both clutter and confusion, and it's against the Django community's
I would imagine the downstream distros won't have the same problems with Ruby
as they did with Node.js from a dependency standpoint, though it still doesn't
jive with the community's all-Python bias.
My real concern, though, is anyone who may have extended the Horizon
stylesheets using the
Yes this is one approach if keystone really wants to extend domains to work
this way, but I think this is more complex than just using nested projects.
Having domains contain domains containing projects is less intuitive than
projects all the way down.
It's worth mentioning that at the
Adding this to glanceclient is probably acceptable since the worst abuse of it
would be to disrupt a user's local machine until they terminated the process,
but adding this to Horizon is a no-go.
Django removed the verify_exists option from URLField in Django 1.5 for very
good reasons. Here's
I've also used the core Horizon bits for dashboards other than the OpenStack
dashboard. I can't speak for any current bugs you may run into, but
by-and-large the ability to create arbitrary dashboards, tables, workflows,
etc. to interact with RESTful APIs works perfectly without the OpenStack
Martinelli; Jamie Lennox; David Stanek; Andy Smith; Gabriel Hurley;
Joe Heck; Devin Carlen
Subject: [keystone] Changes to keystone-core!
Hello everyone!
We've been talking this for a long while, and we finally have a bunch of
changes to make to keystone-core all at once. A few people have moved
From my experience, directly adding incubated projects to the main Horizon
codebase prior to graduation has been fraught with peril. That said, the
closer they can be together prior to the graduation merge, the better.
I like the idea of these types of projects being under the OpenStack
I've run into a use case that doesn't currently seem to have a great solution:
Let's say my users want to use a top-of-stack OpenStack project such as Heat,
Trove, etc. that I don't currently support in my deployment. There's absolutely
no reason these services can't live happily in a VM
+1 on Tatiana Mazur being added to Core.
I'm also okay with cleaning out the Core list. I considered doing it myself
last cycle since none of those folks are involved anymore, but figured I'd
leave them as a posthumous honor. ;-) I think now's a good time to trim it down.
Glad I didn't make
who can devote their full attention and energy to it.
I will still be around and engaged (though not in Hong Kong). I'll catch you
all next time around.
All the best,
- Gabriel Hurley
___
OpenStack-dev mailing list
OpenStack-dev
Karlson
endre.karl...@gmail.commailto:endre.karl...@gmail.com
Hey, I'm just curious. You quitting the PTL position to focus on Nebula efforts
or ?
2013/10/31 Gabriel Hurley
gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com
Hi all,
It saddens me to say that for a mix of reasons I have
The answer is sort of. Most projects (including Nova) publish to an RPC
notifications channel (e.g. in rabbitMQ or whichever you use in your
deployment). This is how Ceilometer gets some of its data.
There is common code for connecting to the notification queue in Oslo (the
rpc and notifier
FWIW, Django 1.6 is not officially supported with Horizon yet.
That aside, pickle is generally a security risk (it's equivalent to eval),
hence the move away from it in Django. We'll want to see what we can do about
making things properly serializable with the JSON serializer in Icehouse. It
Board and the TC, coordination within OpenStack, and more, but I won't go into
those now.
Hopefully I've proven myself thus far to be a considered and well-reasoned
member of the TC. It would be my honor to consider doing the good work of
OpenStack.
Thank you,
- Gabriel Hurley
Hi Kaiwai,
First, the bad news:
1. The Horizon release candidate has already been cut, so for Havana we're only
considering release-blocking bugs at this point (and even those have to meet a
high bar to warrant a new release candidate). The feature freeze deadline was
almost a month ago.
2.
more.
If you still have any concerns, let me know I will try to be more explicit.
-- Jarda
On 2013/25/09 02:03, Gabriel Hurley wrote:
Really digging a lot of that. Particularly the inter-rack/inter-node
communication stuff around page 36ish or so.
I’m concerned about using the term “Class”. Maybe
3. There is a thought about watching correlation of multiple alarm
histories in one Chart (either Alarm Histories, or the real statistics
the Alarm is defined by). Do you think it will be needed? Any real
life examples you have in mind?
I think the first use case is to debug combined
Really digging a lot of that. Particularly the inter-rack/inter-node
communication stuff around page 36ish or so.
I’m concerned about using the term “Class”. Maybe it’s just me as a developer,
but I couldn’t think of a more generic, less inherently meaningful word there.
I read through it and
I hereby declare my candidacy for the Horizon PTL position.
My current qualifications:
* PTL for the Grizzly and Havana cycles.
* Core developer on Horizon since Essex, and Keystone core since Folsom.
* Primary architect of the existing Horizon framework.
* Core developer for the Django
I'm also strongly against reverting the move to lesscpy. As David said, that
change was highly-requested by the downstream distros and other folks packaging
Horizon in various ways.
Since there's no evidence that lesscpy does not intend to support bootstrap 3
in a reasonable timeframe,
28, 2013 1:58 AM
To: Gabriel Hurley
Cc: OpenStack Development Mailing List; Dolph Mathews; Adam Young
Subject: [keystone][horizon]Backend filtering in Keystone
Hi Gabriel,
Following up on our discussions on filtering and pagination, here's where we
stand:
1) We have a patch ready to go into H
If you look at the code in the post()[1] method of the base workflow view
you'll note that a response to a successful workflow POST is always a
redirect[2] (caveat for when it's specifically adding data back to a field,
which isn't relevant here).
The reason for this is that in general when
I have been one of the earliest, loudest, and most consistent PITA's about
pagination, so I probably oughta speak up. I would like to state three facts:
1. Marker + limit (e.g. forward-only) pagination is horrific for building a
user interface.
2. Pagination doesn't scale.
3. OpenStack's APIs
The short answer is: you can test and develop it locally but you cannot push
it upstream until you get the dependencies released. As much as that may be
frustrating, it prevents an enormous amount of pain which OpenStack has gone
through in the past when things fail to be released as expected.
Generally spot-on with what Adrian said, but I have one question from that
email:
Mappings is one of the high level concepts in CFN that I think can be
completely eliminated with auto-discovery.
What do you mean by this? What kind of autodiscovery, and where? I'm all for
eliminating mappings
I spent a bunch of time working with and understanding Heat in H2, and I find
myself with one overarching question which I wonder if anyone's thought about
or even answered already...
At present, the CloudFormation template format is the first-class means of
doing things in Heat.
I responded on the ticket as well, but here’s my take:
An error like this should absolutely be caught before it raises a database
error. A useful, human-friendly error message should be returned via the API.
Any uncaught exception is a bug. On the other side of the equation, anything
using the
Brooklyn Chen, Julie Pichon and others have already been putting in a lot of
effort in this area. I suggest you check out
https://blueprints.launchpad.net/horizon/+spec/ceilometer and sync up with them
if you're interested in proceeding.
- Gabriel
-Original Message-
From:
39 matches
Mail list logo
