On 06/24/2015 07:57 AM, Chris Dent wrote:
On Wed, 24 Jun 2015, Sean Dague wrote:
So on https://review.openstack.org/#/c/194442 ... I was kind of thinking
we'd be able to get keystone-wsgi-public into a bin directory. I put up
a half baked sketch of this idea in
On 06/23/2015 04:07 PM, Brant Knudson wrote:
I've got a few related changes proposed to keystone and devstack:
https://review.openstack.org/#/c/193891/ - Changes Apache Httpd config
so that /identity is the keystone public (aka main) handler and
/identity_admin is the keystone admin handler.
On Wed, 24 Jun 2015, Sean Dague wrote:
On 06/24/2015 07:57 AM, Chris Dent wrote:
If the primary reason is so that we can rely on the console_scripts
entry point to handle getting the application somewhere useful then
that too feels a bit crufty, in the sense of that's a hack.
[snip]
The
On 06/24/2015 07:19 AM, Sean Dague wrote:
On 06/23/2015 04:07 PM, Brant Knudson wrote:
I've got a few related changes proposed to keystone and devstack:
https://review.openstack.org/#/c/193891/ - Changes Apache Httpd config
so that /identity is the keystone public (aka main) handler and
On Wed, 24 Jun 2015, Sean Dague wrote:
So on https://review.openstack.org/#/c/194442 ... I was kind of thinking
we'd be able to get keystone-wsgi-public into a bin directory. I put up
a half baked sketch of this idea in
https://review.openstack.org/#/c/195044. Would be curious if some
version
Hi guys,
I worked on running nova-api on http://localhost/compute.
I prepared raw reviews:
nova review: https://review.openstack.org/#/c/195303/1
devstack review: https://review.openstack.org/#/c/195300/
We need to determine proper URLs for ec2-api(used 8773 port) and
metadata(used 8775 port)
On 06/24/2015 01:51 PM, Brant Knudson wrote:
On Wed, Jun 24, 2015 at 7:27 AM, Chris Dent chd...@redhat.com
mailto:chd...@redhat.com wrote:
On Wed, 24 Jun 2015, Sean Dague wrote:
On 06/24/2015 07:57 AM, Chris Dent wrote:
If the primary reason is so that we can
On Wed, Jun 24, 2015 at 7:27 AM, Chris Dent chd...@redhat.com wrote:
On Wed, 24 Jun 2015, Sean Dague wrote:
On 06/24/2015 07:57 AM, Chris Dent wrote:
If the primary reason is so that we can rely on the console_scripts
entry point to handle getting the application somewhere useful then
that
On 06/24/2015 02:05 PM, Sean Dague wrote:
On 06/24/2015 01:51 PM, Brant Knudson wrote:
On Wed, Jun 24, 2015 at 7:27 AM, Chris Dent chd...@redhat.com
mailto:chd...@redhat.com wrote:
On Wed, 24 Jun 2015, Sean Dague wrote:
On 06/24/2015 07:57 AM, Chris Dent wrote:
Brant,
We likely need to back port a simplified version of the wsgi files and/or make
the Juno (and kilo) versions of dev stack use the same simplified / split
files. Grenade doesn't re-run stack - so new files that are outside pip's
purview won't be used afaik.
--Morgab
Sent via mobile
On
On Wed, Jun 17, 2015 at 1:21 PM, Sean Dague s...@dague.net wrote:
On 06/16/2015 05:25 PM, Chris Dent wrote:
On Tue, 16 Jun 2015, Sean Dague wrote:
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
On Tue, Jun 23, 2015 at 4:08 PM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:
We likely need to back port a simplified version of the wsgi files and/or
make the Juno (and kilo) versions of dev stack use the same simplified /
split files. Grenade doesn't re-run stack - so new files that are
Dean,
If we change how Kilo works, then we'll just move the error state from Kilo
- Master to Juno - Kilo since the same issue will now occur in upgrading
from Juno in grenade. It's unfortunate.
--Morgan
On Tue, Jun 23, 2015 at 2:22 PM, Dean Troyer dtro...@gmail.com wrote:
On Tue, Jun 23,
Aha! Right, Thanks Sean. I'll just go back under my rock (too many things
going on to remember them all) and see what we can do about getting Kilo -
Master fixed up.
On Tue, Jun 23, 2015 at 4:53 PM, Sean Dague s...@dague.net wrote:
On 06/23/2015 07:49 PM, Morgan Fainberg wrote:
Dean,
If
On 06/23/2015 07:49 PM, Morgan Fainberg wrote:
Dean,
If we change how Kilo works, then we'll just move the error state from
Kilo - Master to Juno - Kilo since the same issue will now occur in
upgrading from Juno in grenade. It's unfortunate.
Actually Juno - Kilo is back on eventlet because
-Original Message-
From: Sean Dague [mailto:s...@dague.net]
Sent: Wednesday, June 17, 2015 11:22
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack] apache wsgi application support
On 06/16/2015 05:25 PM, Chris Dent wrote:
On Tue, 16
On 06/16/2015 05:25 PM, Chris Dent wrote:
On Tue, 16 Jun 2015, Sean Dague wrote:
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
direction. Largely I think because they were copied from the
On Tue, 16 Jun 2015, Sean Dague wrote:
I'd expect nova to be running on http://localhost/compute not
http://localhost:8774 when running under wsgi. That's going to probably
interestingly break a lot of weird assumptions by different projects,
but that's part of the reason for doing this
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
direction. Largely I think because they were copied from the
lib/keystone code, which we've learned is kind of the wrong direction.
The first is the fact
Long term we want to see Keystone move to http://host/identity. However the
reason for choosing 5000/35357 for ports was compatibility and avoiding
breaking horizon. At the time we did the initial change over, sharing the root
80/443 ports with horizon was more than challenging since horizon
On Tue, 16 Jun 2015, Sean Dague wrote:
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
direction. Largely I think because they were copied from the
lib/keystone code, which we've learned is kind of the
On 06/16/2015 12:25 PM, Sean Dague wrote:
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
direction. Largely I think because they were copied from the
lib/keystone code, which we've learned is kind of
On 06/16/2015 12:48 PM, Morgan Fainberg wrote:
Long term we want to see Keystone move to http://host/identity. However the reason for choosing
5000/35357 for ports was compatibility and avoiding breaking horizon. At the time we did the initial
change over, sharing the root 80/443 ports with
23 matches
Mail list logo
