I've been hoping some of the more design-oriented folks would weigh in on this
issue, but that hasn't particularly happened...
My concern is that as engineers we're all comfortable with GitHub, but that it
will end up being an impediment or discouragement for people who fall more on
the
7:41 AM
To: Gabriel Hurley
Cc: Devendra Gupta; openstack@lists.launchpad.net
Subject: Re: [Openstack] API version in Grizzly
On Wed, May 8, 2013 at 6:57 PM, Gabriel Hurley
gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote:
In Grizzly I can send Keystone requests to either
http
When you say Identity v3.0 development is going on side-by-side so I think if
I have Grizzly setup with Identity v2.0 then it'll be upgraded to Identity
v3.0
with Grizzly when new version is available in updates.
Though I might have option to upgrade it or not? OR Identity v3.0 will be
If that config option is not being respected for the Nova API calls that's a
bug. Please file a ticket on Launchpad so we can track fixing it.
Thanks!
- Gabriel
From: Openstack
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Wyllys Ingersoll
If you have Instances Volumes then you're not running Grizzly Horizon.
Those two were split apart in Grizzly. Prior to Grizzly the Volume Service was
required. In Grizzly Horizon it's not.
As such you have two choices: run Cinder like you are but don't use it, or
upgrade so you're actually
There's something very wrong is false doesn't raise an exception. In Python
False is a Boolean value, false is a variable name which should be
undefined.
That aside, you should set COMPRESS_OFFLINE=False in your
openstack_dashboard/local/local_settings.py file.
- Gabriel
-Original
Identity service has both a v2.0 and v3 side-by-side. There isn't necessarily a
default except for the fact that most people's Service Catalogs still say
v2.0 in them because they're hard-coded that way.
In the future I believe the api.openstack.org site would gain a lot by storing
,
- Gabriel
From: annegen...@justwriteclick.com [mailto:annegen...@justwriteclick.com] On
Behalf Of Anne Gentle
Sent: Wednesday, May 08, 2013 4:38 PM
To: Gabriel Hurley
Cc: Devendra Gupta; openstack@lists.launchpad.net
Subject: Re: [Openstack] API version in Grizzly
On Wed, May 8, 2013 at 4:54 PM
Do you have plans to add comparison matrices, user counts, github stats,
categories (aside from arbitrary tags), etc.? No offense meant to stackmeat,
but the OpenComparison project is way ahead in terms of features that make it
easy for consumers to make educated choices about the
+1. And I'd add that we need to do everything in our collective power to treat
OpenStack as a coherent whole, not as a loosely federated set of projects that
are released together.
We are still a young community, but doing things to build supporting tools,
expose commonalities and overlaps,
I'll throw it out there again:
We really ought to deploy an OpenComparison site (http://opencomparison.org/)
for OpenStack. It's awesome, and does massive amounts of goodness for managed
information and discovery.
- Gabriel
-Original Message-
From: Openstack [mailto:openstack-
We landed a fix in Horizon yesterday ( tracked in
https://bugs.launchpad.net/horizon/+bug/1155876 ) that addresses this problem
for the Grizzly RC.
Nova should have followed a proper deprecation path here and accepted the
parameters in this release and reject them (if they really must) in
Hi folks!
I'm nominating myself for Horizon PTL for another term. I want to continue
fighting for cross-service integration/standardization, better APIs for
everyone, and the best possible user interface to introduce people to what
OpenStack can do.
Quick recap of my qualifications: current
That particular endpoint not found log message is a red herring. It's been
removed in keystoneclient trunk because it was logging an *expected* error.
There isn't supposed to be a service catalog available at the point at which it
logged that message, and it lead to confusion just like this.
Even though I don't experience this problem (and prefer nginx to apache), I can
help diagnose:
Connections ending up in CLOSE_WAIT means that the socket isn't being fully
closed, which is controlled by the client lib (in this case
python-keystoneclient) which uses httplib2 under the hood.
Also, aren't the release names always *California* cities? Thereby Hillsboro,
Oregon isn't a valid choice...
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Poll: H release cycle naming
Also, aren't the release names always *California* cities?
Nope. =)
http://wiki.openstack.org/ReleaseNaming
At Your Service,
--
Mark T. Voelker
On 1/28/13 3:23 PM, Gabriel Hurley wrote:
Also
Horizon's list of required services includes Nova, Glance and Keystone. At
present no work has been done to make it run with a Swift + Keystone (only)
configuration. That said, it's not impossible. The easiest route would likely
be to unregister all of the Nova and Glance-related panels in the
I haven't heard a report like this from anyone else. Looking at your patch it
looks like you're having problems with the sub-module imports for some reason,
which sounds to me like a Python problem. Is there anything unusual about your
version of Python? Any unusual/duplicate packages on your
The DevStack and Ubuntu configurations run with the Ubuntu distro's default
version of Apache and modWSGI. Personally I'm also a big fan of NginX. Horizon,
being a Django/WSGI-compliant application can run behind any webserver that
supports the Python WSGI standard.
- Gabriel
Have you tried doing what it said and running manage.py compress? (make sure
you're in the proper Python environment/venv when running that command)
That error indicates one of two things:
1. You have your settings set with COMPRESS_ENABLED = True and
COMPRESS_OFFLINE = True but you
It sounds like you *could* start updating and submitting it, but with the
knowledge that you’ll have to continue to tweak it just as the JSON spec is
being tweaked during development. So your options are to maintain it as such or
wait until it’s declared FINAL and then do the work later on but
Agreed. I've been thinking that for a while. I've been thinking keypair should
be promoted to the main tab of the Launch workflow, even.
Patches welcome. :-)
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
Yep, what Vish said. Everything about the current Boot From Volume UI is driven
by contraints from Nova which the Nova core team is aware of and is working to
fix. I will certainly not argue that the current UX in Horizon around it is any
good at all. Look for improvements in the late G or H
That is actually the manifestation of a bug in Nova that was addressed very
late in Folsom. The short version is that Nova inconsistently scoped the
ownership of volumes vs. instances so it was possible for an admin user to view
a mixed set of resources which could lead to the scenario you hit
Your Quantum API route is returning a 404. Whether this is because you have
your route wrong or Quantum is misconfigured or [something else] I could tell
you. I would recommend narrowing down your possibilities by trying to make the
call directly with quantumclient or using curl to make the
For questions like that it would be *very* helpful if you could post your code
somewhere (github/gerrit). Debugging them otherwise is basically shooting in
the dark.
- Gabriel
From: Srikanth Kumar Lingala [mailto:srikanthkumar.ling...@gmail.com]
Sent: Monday, November 12, 2012 11:51
[mailto:srikanthkumar.ling...@gmail.com]
Sent: Tuesday, November 06, 2012 5:49 AM
To: Gabriel Hurley
Cc: openstack@lists.launchpad.net; openstack-...@lists.openstack.org
Subject: [Horizon] Different URLs (hyperlinks) in a table view.
Hi Gabriel,
I want to go to different URL for each row in a table view
Hey all, I just got this from the Dope'n'Stack crew and thought I'd pass it
along:
---
We know many of you were devastated by not getting a What the F☁☁K is
OpenStack shirt down in San Diego... if you still want one there's a signup
list available:
With respect to the comments on Horizon, as soon as Keystone implements the
policy rollup and exposes it in the v3 API Horizon will fully honor the
policies specified by the various projects. That blueprint for Keystone was
targeted for Folsom but got bumped to Grizzly. Hopefully it'll make it
It's also worth noting that we are now in territory where quotas are controlled
by multiple projects: volumes and gigabytes have quotas in both Nova and
Cinder; network quotas are in both Nova and Quantum...
While I don't think it makes sense to try and centralize these things, I think
the
There are various options for how Horizon can handle the UX problems associated
with adding additional domains. Making it a part of the URL is one which could
be supported, but I'm not inclined to make that the only method. The
implementation details can be hashed out when we get there.
I am
Horizon has (thus far) been designed to avoid requiring a persistent storage
backend such as a database, so you won't find any code in there to do that.
That said, Horizon is built on Django, and Django has a phenomenal ORM which
works with most common database backends. Building a Django model
Full timezone support was added in Folsom; for Essex the best you can do is
change the TIME_ZONE setting in your local_settings.py file; however if your
timezone there doesn't match the timezone on your server(s) you're gonna end up
with an offset between the dashboard and the rest of the
That generic error is what happens when there's a 500 error on the server-side
while submitting a form via AJAX. Take a look in the Horizon console log to see
what really went wrong.
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
This QUANTUM_ENABLED setting hasn't existed in a very long time (I'm talking
like Diablo timeframe). Everything in Horizon is controlled by Keystone's
service catalog. The presence or absence of particular service types (e.g.
network for Quantum) is what controls the appearance of those panels
All of what you said is correct. Those filtering issues (which applied to
volumes, keypairs, and security groups at least) were tracked in separate
tickets in Nova and all got fixed towards the tail end of Folsom. I don't have
the commits handy, sorry. The proper fix was filtering the results
the definition here, but that seems like overkill to me.
If its what you need I'll do it for Folsom, but... thoughts?
- Gabriel
On Sep 14, 2012, at 8:25 PM, Thomas Goirand tho...@goirand.fr wrote:
On Sat Sep 15 2012 03:55:09 AM CST, Gabriel Hurley
gabriel.hur...@nebula.com wrote:
Either
Adam beat me to the punch. What he suggested is the least invasive solution
(doesn't require changing any template files).
The secondary solution which is simpler but less elegant is a simple patch to
the stylesheet template file to point to a static pre-compiled copy of the CSS,
and then
Matt is correct in pointing you to extending Horizon, however I'd take this up
a level and suggest that I'd love to see a mashup between the very widely used
django-registration app (http://docs.b-list.org/django-registration/0.8/) and
the django-openstack-auth backend. Making user accounts
One additional note on that, however: for legacy reasons many of the projects
have hardcoded assumptions about the role named admin. In Grizzly we'll be
working to make the role-based access control truly customizable, but for now
you're stuck with needing that one.
- Gabriel
From:
. ;-)
- Gabriel
From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: Friday, August 31, 2012 1:34 PM
To: Gabriel Hurley
Cc: Dolph Mathews; Jack; openstack
Subject: Re: [Openstack] About the Role and User's rights
Nova recently was changed to allow the rolename that gets is_admin privileges
I hereby officially throw my hat in the ring to be Horizon's PTL.
Qualifications:
I'm a highly active developer on Horizon, and a member of the Horizon Drivers
group. I wrote the initial version of python-keystoneclient, and I'm a member
of the Keystone Core group as well. I'm also a core
Well said, Ryan. Agreed 100% on all points, both in the specific examples and
the overarching theme of n+1 compatibility. Upgrade paths have got to be clean
and well-documented, and deprecations must be done according to responsible,
established timelines from here on out.
We're verifiably
I traced this through the code at one point looking for the same thing. As it
stands, right now there is *not* a mechanism for customizing the default
security group's rules. It's created programmatically the first time the rules
for a project are retrieved with no hook to add or change its
In conjunction with the PTLs, the Docs team, the Infrastructure team, various
community members and more, I'm very happy to say that we are ready to share
out a complete set of documentation and processes for translation,
internationalization, and localization for OpenStack as a whole. The
For two summits running I've been advocating the need for a common standard of
functionality for all OpenStack APIs (things like sorting, bulk operations,
filtering, pagination, etc.). I intend to push on the issue even harder this
time around at the Grizzly summit (I'm going to propose an
Given that the v3 API didn't get implemented in Folsom that gives us a perfect
opportunity to talk about this stuff at the Grizzly summit! ;-)
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
There are two levels of status control in Horizon: one at the column level
and one at the row level, which is an aggregate of the column statuses within
that row.
Column status is controlled by settings status=True on the column. If you
want fine-grained control over which statuses are
More than happy to discuss it! If we can do things to support it that don't
rely on other projects (e.g. Keystone) all the better. Otherwise we should
discuss it as a community and work together towards a federated federation
solution. ;-)
- Gabriel
From:
Go for it. I assume this is related to
https://bugs.launchpad.net/horizon/+bug/1018560 ?
If you need to add stuff feel free. Were you thinking the end result would be
to display those bars on the overview screen for the project?
- Gabriel
From:
Horizon already has what you just described. You can load images into glance by
providing a URI. It's the Create Image button on the Images table.
- Gabriel
-Original Message-
From: Brian Waldon [mailto:bcwal...@gmail.com]
Sent: Friday, August 10, 2012 7:35 AM
To: Gabriel Hurley
Indeed, uploading large files with the Horizon webserver as an intermediate
relay is a nasty business which we want to discourage. We are looking at ways
to send files directly from the Horizon client-side UI to swift/glance for
large file upload in the future.
All the best,
- Gabriel
With the stipulation that clients will be able to talk to all versions of the
API from here on forward, I am totally in favor of this.
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
I'm trying to run devstack with quantum enabled so I can test the recent work
on re-integrating Quantum into Horizon.
I've followed the instructions for what should be in my localrc file here:
http://wiki.openstack.org/QuantumDevstack
However, devstack fails when trying to create a network
: Tuesday, August 07, 2012 1:33 PM
To: Gabriel Hurley
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Quantum devstack authentication error
Hi Gabriel,
Adding Q_AUTH_STRATEGY=noauth to localrc should fix the issue.
The authentication it's trying to use only works in folsom.
Thanks
As a rule of thumb, we need to start doing proper deprecation on all public
interfaces, whether that's a CLI, client method signatures, APIs, etc. It's a
little late for this on the old vs. new glance client/CLI (unless Brian feels
the work can be reasonably done to make them compatible) but
. Mitchell
Sent: Wednesday, August 01, 2012 12:19 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] [glance] legacy client removal and python-
glanceclient
On Wed, 2012-08-01 at 18:37 +, Gabriel Hurley wrote:
As a rule of thumb, we need to start doing proper deprecation on all
I ran into some similar issues with the _enable_hairpin() call. The call is
allowed to fail silently and (in my case) was failing. I couldn't for the life
of me figure out why, though, and since I'm really not a networking person I
didn't trace it along too far.
Just thought I'd share my
Without information on how you installed keystone/horizon, I'm going to assume
the most common problem: your local_settings.py file for Horizon is
misconfigured/out of date. Particularly let me point out this section in the
example file:
happened and what progressed from the bug
trace.
Sam
On Fri, Jul 13, 2012 at 12:43 PM, Gabriel Hurley
gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote:
Glance pagination was added in Folsom. Adding a bug for this won't help since
it's already been added in the current code
, Jul 5, 2012 at 11:54 AM, Gabriel Hurley
gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote:
The “Project Dashboard” hides images with an AKI or AMI image type (as they’re
not launchable and generally shouldn’t be edited by “normal” users). You can
see those in the “Admin Dashboard
The stated and agreed-upon goal from Essex forward is to make the core
OpenStack projects N+1 compatible (e.g. Essex-Folsom, Folsom-Grizzly), and to
make the clients capable of talking to every API version forever.
Anything standing in the way of that should be considered a release-blocking
I'm normally very much in favor of stable APIs and slow deprecation, but in
this case I'm far more concerned about having to support two completely
independent codebases. If we pursue option 2 I think the language there needs
to be even stronger and we'd have to say that nova-volume is
Filed that bug a month ago: https://bugs.launchpad.net/glance/+bug/1009248
Patches welcome. ;-)
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf
The Project Dashboard hides images with an AKI or AMI image type (as they're
not launchable and generally shouldn't be edited by normal users). You can
see those in the Admin Dashboard if you want to edit them.
So my guess is that the kernel and ramdisk images are being hidden correctly
and
Sorry, that's should've read AKI or ARI.
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Gabriel Hurley
Sent: Thursday, July 05, 2012 11:54 AM
To: Sam Su; openstack
Having a team/leader in that arena would definitely help. I'd contribute to
common more if I knew what needed contributing, who to talk to about it, etc...
Same goes for helping in terms of packaging, etc. to make it a proper common
library.
- Gabriel
-Original Message-
From:
So, I understand the rationales, and I think of those three options the one
chosen is the most reasonable. I'm gonna just come out and say I hate this
whole idea, but let's set this aside for a minute 'cuz I have a genuine
question:
What will the process be for merging changes to this
The notion that copying code is any protection against APIs that may change is
a red herring. It's the exact same effect as pegging a version of a dependency
(whether it's a commit hash or a real version number), except now you have code
duplication. An unstable upgrade path is an unstable
are so easy to ignore...
All the best,
- Gabriel
-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com]
Sent: Tuesday, July 03, 2012 12:49 PM
To: Gabriel Hurley
Cc: Eric Windisch; openstack@lists.launchpad.net
Subject: Re: [Openstack] Single global dependency list
in all other project heads simultaneously.
--
Eric Windisch
On Tuesday, July 3, 2012 at 15:47 PM, Andrew Bogott wrote:
On 7/3/12 1:59 PM, Gabriel Hurley wrote:
The notion that copying code is any protection against APIs that may change is
a red herring. It's the exact same effect as pegging
+1 on close enough to an arbitrary territory and also a great name. ;-)
Also, the Grizzly is the California state animal:
http://www.statesymbolsusa.org/California/animal_grizzly_bear.html
Food for thought.
- Gabriel
From:
On a more fundamental level, did I miss some tremendous reason why we have this
merge from common pattern instead of making OpenStack Common a standard
python dependency just like anything else? Especially with the work Monty has
recently done on versioning and packaging the client libs from
I'm seeing this error too. It appears that the environment variables
(SERVICE_TOKEN, etc.) aren't getting exported, causing keystoneclient to not
find them in the environment and triggering that error.
What I can't figure out is what changed in the last couple days to make this
suddenly stop
I've found where the problem stems from. It snuck in with the keystone sql
backend change:
https://github.com/openstack-dev/devstack/commit/3f7c06f5aaff5d3e2ec28931e0fe4ab8376208e6#L1L1944
Previously the arguments to the keystone commands were being passed in
directly, now they're not, hence
This turned out to be a legitimate bug in devstack.
bug report:
https://bugs.launchpad.net/devstack/+bug/1019056
and review:
https://review.openstack.org/#/c/9143/
All the best,
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
I'm seeing a lot of that on the CI gate jobs today, too. Seems to be an problem
installing dependencies with pip. Usually I blame this on transient network
problems, unless somebody's been mucking with the clients themselves...
- Gabriel
From:
I can get behind that. Despite some vigorous debates he and I have had, I can
stand behind his overall knowledge, contributions and quality standards. ;-)
+1.
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
It sounds like your local_settings.py file is missing any logging
configuration. The default config from the local_settings.py.example file is a
good place to start.
If that’s not the case, then it would be helpful to know how you installed
OpenStack/Horizon, what you’ve done to configure it,
Big +1 for automated tagging and releasing (sounds like we're managing
wildlife...) from Jenkins!
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
bounces+gabriel.hurley=nebula@lists.launchpad.net] On
The port change is fine with me since we're trampling on an already-registered
port number.
However, I'd like to ask again about the admin vs. standard ports in the
Keystone v3 API. There was no mention of the differentiation between the two or
how they would be used. Especially in a
Argh. I think it interacted with one of the other backports badly. I'll update
this today.
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of
Updated the review on gerrit so the test that got added by another backport to
work with this patch. Everything should be good there now.
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
...@suse.de]
Sent: Wednesday, June 20, 2012 9:05 AM
To: Gabriel Hurley; openstack@lists.launchpad.net
Cc: Paul McMillan
Subject: Re: [Openstack] [Blueprint automatic-secure-key-generation]
Automatic SECURE_KEY generation
Hi guys,
according from your answers, I believe we're still trying
That's looking pretty good, Sascha. May I suggest:
1. Instead of using the temporary lockfile, let's actually move slightly back
towards your original approach and check for the existence of a known secret
key file (added to .gitignore of course) which the get_secret_key function can
check
Nice work.
When you've got the rest of the API bits ironed out (particularly
attach/detach) I'll help work on making sure Horizon is fully functional there.
Note that there's also an F3 Horizon blueprint for splitting volumes into its
own optional panel:
It may have to do with the container type set on the images. There is some
filtering happening in the Project dashboard that hides the AKI and ARI images
that are associated with AMIs. So if you've only got AKI/ARI images those would
be hidden. You can see (and manage) those images as an
Hi Joe,
I added lots of comments on the google doc. I think most of them reinforce the
existing design decisions. That said, there are a few high-level issues I'd
like to ask for discussion on:
1. This API features no differentiation between the admin API and the
regular API as it
Big +1 for automated tagging and releasing (sounds like we're managing
wildlife...) from Jenkins!
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Message-
From: Sascha Peilicke [mailto:sasc...@suse.de]
Sent: Friday, June 15, 2012 12:38 AM
To: Gabriel Hurley
Cc: openstack@lists.launchpad.net
Subject: Re: [Blueprint automatic-secure-key-generation] Automatic
SECURE_KEY generation
Hi Grabriel,
let's discuss the blueprint [1
It generally sounds like you've done the right things... the only thing I can
think of offhand might be that if you're running Django through a webserver
like Apache, nginx, or gunicorn you'll need to restart your webserver to see
the changes take effect.
Some information on what version of
-Original Message-
From: Mark Nottingham [mailto:m...@mnot.net]
Sent: Tuesday, June 12, 2012 8:43 PM
To: Gabriel Hurley
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to
the community)
On 13/06/2012, at 1:24 PM, Gabriel Hurley
Big +1 to getting our client release process nailed down! That'll be huge in
terms of managing those dependencies. :-)
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
Mark,
Apparently you must have missed my lightning talk at the Essex summit... ;-)
(http://gabrielhurley.github.com/slides/openstack/apis_like_orms/index.html)
Filtering, pagination, and many other API features are *critical* for a rich
dashboard experience. If you want to talk specifics, the
Totally agree with all of Jay's points, and I also couldn't agree more with
Mark on the importance of being crystal clear, and not operating on just a
common understanding which is quickly misunderstood or forgotten.
Ideally I'd like to see an OpenStack API feature contract of some sort...
I just thought I'd call out that Glance's swift storage module is currently
broken, and apparently this escaped the devstack gate even though devstack
actually fails to complete if swift is enabled. Are we not testing with swift
in the ENABLED_SERVICES list?
Bug report here:
The blueprint for adding Quantum support (via a Networks panel) back into the
dashboard is still a high priority for both the Horizon and Quantum teams.
There was a patch started by one of the Quantum team members, but after a code
review that identified many fixes it ended up expiring and
Stored timestamps should always be in UTC, however efforts should be made to
support local timezones as a user-configurable option. Horizon will be working
towards this goal since Django has good timezone support, I'd encourage other
projects to keep this on their radar as well.
- Gabriel
I've had this fight with Joe Heck and Termie before. They rejected my attempts
to modify the Keystone code to allow a user to change their own password. I
believe their grounds were a combination of it being an admin activity, and
that adding it to the user API would change the API contract and
1 - 100 of 137 matches
Mail list logo
