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 c
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 non
+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 the
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 talk
>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 Dashb
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 on
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 bi
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
> 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 mee
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 capa
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 didn't realize it would violate Django community's conventions, can you
> point to where they are documented?
There's no single document that says "you must name this way", but if you look
at all the most popular django packages, they all follow a similar trend.
The Django tutorial does actu
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 [mailto:ante...@ante
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 hea
[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
th
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) If
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 devs
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 needs
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 d
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, t
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, revertin
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 w
> > 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 co
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
t of classes a little bit 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 usin
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.
he engagement between the Foundation
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
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
sh
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 "notif
of someone 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 lis
wrongly intended.
Endre
2013/10/31 Endre Karlson
mailto: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
mailto:gabriel.hur...@nebula.com>>
Hi all,
It saddens me to say that for a mix of reasons I h
We all agree on the benefits of an event-driven "push" system, but the basis
for this already exists in OpenStack. The RPC notification code exists in Oslo
and most of the IaaS projects are using it now. There were (should have been?)
conversations about how to leverage this data stream in the H
On the one hand, this has largely been the long-term plan since I took over
active development of Horizon/OpenStack Dashboard in the Essex cycle. On the
other hand, it's a very significant undertaking to split them and has a lot of
repercussions for the flow of development, management overhead,
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: Chris
Very nice, can't wait to get the code review for that. :)
- Gabriel
From: Tim Schnell [mailto:tim.schn...@rackspace.com]
Sent: Tuesday, July 09, 2013 9:59 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Heat] [Horizon] Heat Resource Topology Demo
Hey everyone,
Just
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
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. CloudFormation
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 mapping
Thanks Steve,
> InstanceType and ImageId could even be specified in the environment file
> that is specified on launch, so they don't need to be specified in the launch
> command, ie env.yaml:
> parameters:
> KeyName: heat_key
> InstanceType: m1.micro
> ImageId: ubuntu-vm-heat-cfntools-tempe
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.
Many of you have probably heard about the "BREACH" attack/security
vulnerability in HTTPS traffic that was disclosed recently, and I'd like to
take a moment to provide some info about how that affects Horizon. I'm not
following the official vulnerability management process because 1. The
vulner
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 ha
to:hen...@linux.vnet.ibm.com]
Sent: Wednesday, August 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
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 you
FWIW, this week conflicts with the OpenStack Security Group midcycle meetup.
I’ll be attending that, so I thought I’d point it out in case it affects anyone
else.
Having some cross-pollination between Security and Horizon on this significant
shift in the codebase and architecture would probably
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 t
46 matches
Mail list logo
