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 creativ
> 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
>
2013 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
mailto:gabriel.hur...@nebula.com>> wrote:
In Grizzly I can send Keystone requests to either
http://:5000
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
Sen
st,
- 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
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
document
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
> -Orig
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
+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, and
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 projects/tools
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 Havan
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 Ho
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. When
y 28, 2013 1:18 PM
> 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 S
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-
> bounces+gabriel.hurley=nebula@lists.launchpad
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 py
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 ha
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
> -Origin
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 o
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 tim
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 A
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 requ
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 w
ar Lingala [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
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:
https://docs.g
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 i
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 proj
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 mo
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
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
[mailto:openstack-bou
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 stack,
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 pane
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 re
same.
I'd be curious to know 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" wrote:
> On Sat Sep 15 2012 03:55:09 AM CST, Gabriel Hurle
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 remov
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 self
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 comm
t to do it in Grizzly now. ;-)
- 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
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:
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 doin
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 char
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 docum
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-
> bounces+gabriel
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 entir
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 cons
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: openstack-bounces+gabriel.hurley=nebula
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: openstack-bounces+gabriel.hu
put it in swift or s3 and just
> provide
> a uri that references it.
>
> On Aug 9, 2012, at 11:05 AM, Gabriel Hurley wrote:
>
> > Indeed, uploading large files with the Horizon webserver as an
> intermediate relay is a nasty business which we want to discourage. We are
>
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-
> bounces+gabriel.hurley=
osen [mailto:aro...@nicira.com]
Sent: 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 t
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 duri
net] On Behalf Of
> Kevin L. 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 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 it'
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 simila
Sam
On Fri, Jul 13, 2012 at 12:43 PM, Gabriel Hurley
mailto: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.
- Gabriel
From:
openstack-bounces+gabrie
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:
https://github.com/openstack/horizon/blob/master/openstac
2012 at 11:54 AM, Gabriel Hurley
mailto: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” if you want to edit them
Fantastic idea! Automating that N+1 test and forcing the buildout of the
migration script would be HUGE!
- Gabriel
> -Original Message-
> From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
> [mailto:openstack-
> bounces+gabriel.hurley=nebula@lists.launchpad.net
Big +1 on that.
- Gabriel
> -Original Message-
> From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
> [mailto:openstack-
> bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of
> Vishvananda Ishaya
> Sent: Thursday, July 12, 2012 2:41 PM
> To: David Mo
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
b
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 dead/froz
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 Beha
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;
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
a
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: o
+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: openstack-bounces+gabriel.hurley=nebula@lists.launchpa
ve 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
ts that have the
power to block everyone yet 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.launc
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 upgra
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 requireme
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 J
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'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 th
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 wo
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-
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: openstack-bounces+gabriel.hurley=nebula.
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, e
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-
> bounces+gabriel.hurl
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
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 post-RBAC/
cke [mailto:sasc...@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,
>
> accordi
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:
https://blueprints.launchpad.net/horizo
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 for.
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 Be
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 exi
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 adminis
is.
- Gabriel
> -Original 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 gener
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-
> bounces+gabriel.hurley=nebula@list
- Gabriel
> -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)
>
>
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 Hor
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...
es
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 e
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: https://bugs.launch
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 doe
June 06, 2012 1:51 PM
> To: openstack@lists.launchpad.net
> Subject: Re: [Openstack] How to let nova use localtime rather than UTC
> time?
>
> On Wed, Jun 06, 2012, Gabriel Hurley wrote:
> > Stored timestamps should always be in UTC, however efforts should be
> > made to support l
1 - 100 of 144 matches
Mail list logo
