Re: [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Jesse Keating]

mod_wsgi is compiled to a specific python for Apache. It's a single process
(with multiple forks). It looks like the upstream solution to running
different pythons with mod_wsgi is to either use mod_wsgi-express to launch
a new apache+mod_wsgi per-application, or to modify wsgi script (
https://github.com/openstack/keystone/blob/master/keystone/server/wsgi.py )
to load a virtualenv at the top with execfile()

Neither of these are very good options.


- jlk

On Mon, Nov 30, 2015 at 12:41 PM, Robert Collins 
wrote:

> On 1 December 2015 at 09:36, Jesse Keating  wrote:
> > I have an objection to eventlet going away. We have problems with running
> > Apache and mod_wsgi with multiple python virtual environments. In some of
> > our stacks we're running both Horizon and Keystone. Each get their own
> > virtual environment. Apache mod_wsgi doesn't really work that way, so
> we'd
> > have to do some ugly hacks to expose the python environments of both to
> > Apache at the same time.
> >
> > I believe we spoke about this at Summit. Have you had time to look into
> this
> > scenario and have suggestions?
>
> mod_wsgi with separate process definitions should work - Graham
> Dumpleton, the mod_wsgi maintainer, works for Red Hat - I'm fairly
> sure they'd be amenable to us roping him in to help you sort things
> out :)
>
> -Rob
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [openstack-dev] [Neutron] Automatically generate sample configuration files (oslo config generator)

[Martin Hickey]

Hi,

The generation of Neutron configuration files using the oslo config
generator is being introduced in Mitaka as part of blueprint [1] and bug
[2]. This is broken down into two phases: Neutron core and Neutron *aaS
projects.

The first part of the first phase is the generation of sample core
configuration files in patch [3]. The next part is the removal of the
sample configuration files from the core repository in patch [4]. Patch [3]
and [5] make the static sample configuration files in the Neutron
repository redundant.  Developers should no longer update these
configuration files as  they will be removed in patch[4]. Refer to the
Neutron contribution guide for more details.

The final phase of the blueprint is the update of the Neutron *aaS projects
for configuration generation. These commits will be associated to bug [2].

It is advised that Neutron sub-projects do not keep their configuration
files in their respective trees and instead generate them using a similar
approach as Neutron does. Operators should refer to the release notes for
more details.

[1]
https://blueprints.launchpad.net/neutron/+spec/autogen-neutron-conf-file
[2] https://bugs.launchpad.net/neutron/+bug/1199963
[3] https://review.openstack.org/#/c/204206/
[4] https://review.openstack.org/#/c/251348/
[5] https://review.openstack.org/#/c/204722/

Regards,
Martin


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Neutron Multiple gateways instances source routing

[Pedro Sousa]

Hi Salvatore,

thank you for your reply. I'm aware that it works with static routes, I
would like to know if it does source routing
http://www.linuxhorizon.ro/iproute2.html

Anyway I solved it using a script inside the instance.

Regards,
Pedro Sousa





On Sun, Nov 29, 2015 at 7:29 AM, Salvatore Orlando 
wrote:

> Hello Pedro,
>
> Neutron has some (limited) capabilities for injecting static routes into
> instances.
> You can try whether the subnet's host_routes attribute [1] can satisfy
> your requirement.
> Routes can however be specified only in the form destination CIDR/next hop.
> Note: the host_routes option leverages DHCP option 121 in the reference
> implementation and therefore requires DHCP on network interfaces.
>
> Salvatore
>
> [1]
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/api/v2/attributes.py#n808
> (sorry for the link to the code, the API spec does not render anymore
> correctly the subnet page)
>
> On 18 November 2015 at 12:23, Pedro Sousa  wrote:
>
>> Hi all,
>>
>> I've a couple of linux instances with multiple interfaces (different
>> networks and gateways) and I would like to setup source routing, meaning
>> for example that packet that enters interface eth0 should be routed to it's
>> correspondent gateway interface and not default gateway.
>>
>> My question is if this can be done with neutron or do I need to configure
>> it inside the instances?
>>
>> Thanks,
>> Pedro Sousa
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Steve Martinelli]

This post is being sent again to the operators mailing list, and i
apologize if it's duplicated for some folks. The original thread is here:
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.html

In the Mitaka release, the keystone team will be removing functionality
that was marked for deprecation in Kilo, and marking certain functions as
deprecated in Mitaka (that may be removed in at least 2 cycles).

removing deprecated functionality
=

This is not a full list, but these are by and large the most contentious
topics.

* Eventlet support: This was marked as deprecated back in Kilo and is
currently scheduled to be removed in Mitaka in favor of running keystone in
a WSGI server. This is currently how we test keystone in the gate, and
based on the feedback we received at the summit, a lot of folks have moved
to running keystone under Apache since we’ve announced this change.
OpenStack's CI is configured to mainly test using this deployment model.
See [0] for when we started to issue warnings.

* Using LDAP to store assignment data: Like eventlet support, this feature
was also deprecated in Kilo and scheduled to be removed in Mitaka. To store
assignment data (role assignments) we suggest using an SQL based backend
rather than LDAP. See [1] for when we started to issue warnings.

* Using LDAP to store project and domain data: The same as above, see [2]
for when we started to issue warnings.

* for a complete list:
https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka

functions deprecated as of mitaka
=

The following will adhere to the TC’s new standard on deprecating
functionality [3].

* LDAP write support for identity: We suggest simply not writing to LDAP
for users and groups, this effectively makes create, delete and update of
LDAP users and groups a no-op. It will be removed in the O release.

* PKI tokens: We suggest using UUID or fernet tokens instead. The PKI token
format has had issues with security and causes problems with both horizon
and swift when the token contains an excessively large service catalog. It
will be removed in the O release.

* v2.0 of our API: Lastly, the keystone team recommends using v3 of our
Identity API. We have had the intention of deprecating v2.0 for a while
(since Juno actually), and have finally decided to formally deprecate v2.0.
OpenStack’s CI runs successful v3 only jobs, there is complete feature
parity with v2.0, and we feel the CLI exposed via openstackclient is mature
enough to say with certainty that we can deprecate v2.0. It will be around
for at least FOUR releases, with the authentication routes
(POST /auth/tokens) potentially sticking around for longer.

* for a complete list:
https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-mitaka


If you have ANY concern about the following, please speak up now and let us
know!


Thanks!

Steve Martinelli
OpenStack Keystone Project Team Lead


[0]
https://github.com/openstack/keystone/blob/b475040636ccc954949e6372a60dd86845644611/keystone/server/eventlet.py#L77-L80
[1]
https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/assignment/backends/ldap.py#L34
[2]
https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/resource/backends/ldap.py#L36-L39

[3]
http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nova] [ux] [neutron] Results Presentation: Nova Networks to Neutron Migration Study

[Kruithof, Piet]

Hi Folks,

I wanted to let you know about a results presentation for the Nova Networks to 
Neutron Migration Study this Tuesday, December 1st at 10AM MST / 12PM EST / 
5:00PM UTC.

The purpose of this study was to gather data to help better understand the 
attributes of OpenStack users who remain on Nova Networking rather than 
migrating to Neutron, and their primary reasons for doing so.  HP, Red Hat, and 
the OpenStack Foundation collaborated to execute this investigation.

The primary researcher for the study was Melissa Meingast:
Melissa is the manager of the human factors and usability research program for 
the Industry Standard Server (ISS) division, as part of the HP Enterprise 
Design Group. Her primary responsibility is to interface with a variety of 
engineering and product teams to understand and evaluate their strategic and 
tactical user research needs, to design and lead research programs to meet 
these needs based on current scientific research as well as domain expertise, 
and to serve as a usability advocate throughout ISS.

Melissa has conducted a number of studies on behalf of the community including 
interviews, card sorts and usability testing.

A link to the virtual room for the presentation can be found at:

https://wiki.openstack.org/wiki/HorizonUsability_Testing#December_2015_Nova_Networks_to_Neutron_Migration_Study

Note that we are planning a second presentation in a few weeks for OpenStack 
community members in Asia.

Thanks,

Piet

Piet Kruithof
Sr UX Architect, HP Helion Cloud
PTL, OpenStack UX project

"For every complex problem, there is a solution that is simple, neat and wrong.”

H L Menken


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Jesse Keating]

I have an objection to eventlet going away. We have problems with running
Apache and mod_wsgi with multiple python virtual environments. In some of
our stacks we're running both Horizon and Keystone. Each get their own
virtual environment. Apache mod_wsgi doesn't really work that way, so we'd
have to do some ugly hacks to expose the python environments of both to
Apache at the same time.

I believe we spoke about this at Summit. Have you had time to look into
this scenario and have suggestions?


- jlk

On Mon, Nov 30, 2015 at 10:26 AM, Steve Martinelli 
wrote:

> This post is being sent again to the operators mailing list, and i
> apologize if it's duplicated for some folks. The original thread is here:
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.html
>
> In the Mitaka release, the keystone team will be removing functionality
> that was marked for deprecation in Kilo, and marking certain functions as
> deprecated in Mitaka (that may be removed in at least 2 cycles).
>
> removing deprecated functionality
> =
>
> This is not a full list, but these are by and large the most contentious
> topics.
>
> * Eventlet support: This was marked as deprecated back in Kilo and is
> currently scheduled to be removed in Mitaka in favor of running keystone in
> a WSGI server. This is currently how we test keystone in the gate, and
> based on the feedback we received at the summit, a lot of folks have moved
> to running keystone under Apache since we’ve announced this change.
> OpenStack's CI is configured to mainly test using this deployment model.
> See [0] for when we started to issue warnings.
>
> * Using LDAP to store assignment data: Like eventlet support, this feature
> was also deprecated in Kilo and scheduled to be removed in Mitaka. To store
> assignment data (role assignments) we suggest using an SQL based backend
> rather than LDAP. See [1] for when we started to issue warnings.
>
> * Using LDAP to store project and domain data: The same as above, see [2]
> for when we started to issue warnings.
>
> * for a complete list:
> https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka
>
> functions deprecated as of mitaka
> =
>
> The following will adhere to the TC’s new standard on deprecating
> functionality [3].
>
> * LDAP write support for identity: We suggest simply not writing to LDAP
> for users and groups, this effectively makes create, delete and update of
> LDAP users and groups a no-op. It will be removed in the O release.
>
> * PKI tokens: We suggest using UUID or fernet tokens instead. The PKI
> token format has had issues with security and causes problems with both
> horizon and swift when the token contains an excessively large service
> catalog. It will be removed in the O release.
>
> * v2.0 of our API: Lastly, the keystone team recommends using v3 of our
> Identity API. We have had the intention of deprecating v2.0 for a while
> (since Juno actually), and have finally decided to formally deprecate v2.0.
> OpenStack’s CI runs successful v3 only jobs, there is complete feature
> parity with v2.0, and we feel the CLI exposed via openstackclient is mature
> enough to say with certainty that we can deprecate v2.0. It will be around
> for at least FOUR releases, with the authentication routes (POST
> /auth/tokens) potentially sticking around for longer.
>
> * for a complete list:
> https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-mitaka
>
>
> If you have ANY concern about the following, please speak up now and let
> us know!
>
>
> Thanks!
>
> Steve Martinelli
> OpenStack Keystone Project Team Lead
>
>
> [0]
> https://github.com/openstack/keystone/blob/b475040636ccc954949e6372a60dd86845644611/keystone/server/eventlet.py#L77-L80
> [1]
> https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/assignment/backends/ldap.py#L34
> [2]
> https://github.com/openstack/keystone/blob/28a30f53a6c0d4e84d60795e08f137e8194abbe9/keystone/resource/backends/ldap.py#L36-L39
> [3]
> http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Robert Collins]

On 1 December 2015 at 09:36, Jesse Keating  wrote:
> I have an objection to eventlet going away. We have problems with running
> Apache and mod_wsgi with multiple python virtual environments. In some of
> our stacks we're running both Horizon and Keystone. Each get their own
> virtual environment. Apache mod_wsgi doesn't really work that way, so we'd
> have to do some ugly hacks to expose the python environments of both to
> Apache at the same time.
>
> I believe we spoke about this at Summit. Have you had time to look into this
> scenario and have suggestions?

mod_wsgi with separate process definitions should work - Graham
Dumpleton, the mod_wsgi maintainer, works for Red Hat - I'm fairly
sure they'd be amenable to us roping him in to help you sort things
out :)

-Rob

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Paul Czarkowski]

I don't have a problem with eventlet itself going away, but I do feel that
keystone should pick a python based web server capable of running WSGI apps
( such as uWSGI ) for the reference implementation rather than Apache which
can be declared appropriately in the requirements.txt of the project.   I
feel it is important to allow the operator to make choices based on their
organization's skill sets ( i.e. apache vs nginx ) to help keep complexity
low.

I understand there are some newer features that rely on Apache (
federation, etc )  but we should allow the need for those features inform
the operators choice of web server rather than force it for everybody.

Having a default implementation using uWSGI is also more inline with the 12
factor way of writing applications and will run a lot more comfortably in
[application] containers than apache would which is probably an important
consideration given how many people are focused on being able to run
openstack projects inside containers.

On Mon, Nov 30, 2015 at 2:36 PM, Jesse Keating  wrote:

> I have an objection to eventlet going away. We have problems with running
> Apache and mod_wsgi with multiple python virtual environments. In some of
> our stacks we're running both Horizon and Keystone. Each get their own
> virtual environment. Apache mod_wsgi doesn't really work that way, so we'd
> have to do some ugly hacks to expose the python environments of both to
> Apache at the same time.
>
> I believe we spoke about this at Summit. Have you had time to look into
> this scenario and have suggestions?
>
>
> - jlk
>
> On Mon, Nov 30, 2015 at 10:26 AM, Steve Martinelli 
> wrote:
>
>> This post is being sent again to the operators mailing list, and i
>> apologize if it's duplicated for some folks. The original thread is here:
>> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.html
>>
>> In the Mitaka release, the keystone team will be removing functionality
>> that was marked for deprecation in Kilo, and marking certain functions as
>> deprecated in Mitaka (that may be removed in at least 2 cycles).
>>
>> removing deprecated functionality
>> =
>>
>> This is not a full list, but these are by and large the most contentious
>> topics.
>>
>> * Eventlet support: This was marked as deprecated back in Kilo and is
>> currently scheduled to be removed in Mitaka in favor of running keystone in
>> a WSGI server. This is currently how we test keystone in the gate, and
>> based on the feedback we received at the summit, a lot of folks have moved
>> to running keystone under Apache since we’ve announced this change.
>> OpenStack's CI is configured to mainly test using this deployment model.
>> See [0] for when we started to issue warnings.
>>
>> * Using LDAP to store assignment data: Like eventlet support, this
>> feature was also deprecated in Kilo and scheduled to be removed in Mitaka.
>> To store assignment data (role assignments) we suggest using an SQL based
>> backend rather than LDAP. See [1] for when we started to issue warnings.
>>
>> * Using LDAP to store project and domain data: The same as above, see [2]
>> for when we started to issue warnings.
>>
>> * for a complete list:
>> https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka
>>
>> functions deprecated as of mitaka
>> =
>>
>> The following will adhere to the TC’s new standard on deprecating
>> functionality [3].
>>
>> * LDAP write support for identity: We suggest simply not writing to LDAP
>> for users and groups, this effectively makes create, delete and update of
>> LDAP users and groups a no-op. It will be removed in the O release.
>>
>> * PKI tokens: We suggest using UUID or fernet tokens instead. The PKI
>> token format has had issues with security and causes problems with both
>> horizon and swift when the token contains an excessively large service
>> catalog. It will be removed in the O release.
>>
>> * v2.0 of our API: Lastly, the keystone team recommends using v3 of our
>> Identity API. We have had the intention of deprecating v2.0 for a while
>> (since Juno actually), and have finally decided to formally deprecate v2.0.
>> OpenStack’s CI runs successful v3 only jobs, there is complete feature
>> parity with v2.0, and we feel the CLI exposed via openstackclient is mature
>> enough to say with certainty that we can deprecate v2.0. It will be around
>> for at least FOUR releases, with the authentication routes (POST
>> /auth/tokens) potentially sticking around for longer.
>>
>> * for a complete list:
>> https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-mitaka
>>
>>
>> If you have ANY concern about the following, please speak up now and let
>> us know!
>>
>>
>> Thanks!
>>
>> Steve Martinelli
>> OpenStack Keystone Project Team Lead
>>
>>
>> [0]
>> https://github.com/openstack/keystone/blob/b475040636ccc954949e6372a60dd86845644611/keystone/server/eventlet.py#L77-L80
>> [1]
>> 

Re: [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[John Dewey]

100% agree.

We should look at uwsgi as the reference architecture.  Nginx/Apache/etc should 
be interchangeable, and up to the operator which they choose to use.  Hell, 
with tcp load balancing now in opensource Nginx, I could get rid of Apache and 
HAProxy by utilizing uwsgi.

John
On November 30, 2015 at 1:05:26 PM, Paul Czarkowski 
(pczarkowski+openstack...@bluebox.net) wrote:

I don't have a problem with eventlet itself going away, but I do feel that 
keystone should pick a python based web server capable of running WSGI apps ( 
such as uWSGI ) for the reference implementation rather than Apache which can 
be declared appropriately in the requirements.txt of the project.   I feel it 
is important to allow the operator to make choices based on their 
organization's skill sets ( i.e. apache vs nginx ) to help keep complexity low.

I understand there are some newer features that rely on Apache ( federation, 
etc )  but we should allow the need for those features inform the operators 
choice of web server rather than force it for everybody.

Having a default implementation using uWSGI is also more inline with the 12 
factor way of writing applications and will run a lot more comfortably in 
[application] containers than apache would which is probably an important 
consideration given how many people are focused on being able to run openstack 
projects inside containers.

On Mon, Nov 30, 2015 at 2:36 PM, Jesse Keating  wrote:
I have an objection to eventlet going away. We have problems with running 
Apache and mod_wsgi with multiple python virtual environments. In some of our 
stacks we're running both Horizon and Keystone. Each get their own virtual 
environment. Apache mod_wsgi doesn't really work that way, so we'd have to do 
some ugly hacks to expose the python environments of both to Apache at the same 
time.

I believe we spoke about this at Summit. Have you had time to look into this 
scenario and have suggestions?


- jlk

On Mon, Nov 30, 2015 at 10:26 AM, Steve Martinelli  wrote:
This post is being sent again to the operators mailing list, and i apologize if 
it's duplicated for some folks. The original thread is here: 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.html

In the Mitaka release, the keystone team will be removing functionality that 
was marked for deprecation in Kilo, and marking certain functions as deprecated 
in Mitaka (that may be removed in at least 2 cycles).

removing deprecated functionality
=

This is not a full list, but these are by and large the most contentious topics.

* Eventlet support: This was marked as deprecated back in Kilo and is currently 
scheduled to be removed in Mitaka in favor of running keystone in a WSGI 
server. This is currently how we test keystone in the gate, and based on the 
feedback we received at the summit, a lot of folks have moved to running 
keystone under Apache since we’ve announced this change. OpenStack's CI is 
configured to mainly test using this deployment model. See [0] for when we 
started to issue warnings.

* Using LDAP to store assignment data: Like eventlet support, this feature was 
also deprecated in Kilo and scheduled to be removed in Mitaka. To store 
assignment data (role assignments) we suggest using an SQL based backend rather 
than LDAP. See [1] for when we started to issue warnings.

* Using LDAP to store project and domain data: The same as above, see [2] for 
when we started to issue warnings.

* for a complete list: 
https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka

functions deprecated as of mitaka
=

The following will adhere to the TC’s new standard on deprecating functionality 
[3].

* LDAP write support for identity: We suggest simply not writing to LDAP for 
users and groups, this effectively makes create, delete and update of LDAP 
users and groups a no-op. It will be removed in the O release.

* PKI tokens: We suggest using UUID or fernet tokens instead. The PKI token 
format has had issues with security and causes problems with both horizon and 
swift when the token contains an excessively large service catalog. It will be 
removed in the O release.

* v2.0 of our API: Lastly, the keystone team recommends using v3 of our 
Identity API. We have had the intention of deprecating v2.0 for a while (since 
Juno actually), and have finally decided to formally deprecate v2.0. 
OpenStack’s CI runs successful v3 only jobs, there is complete feature parity 
with v2.0, and we feel the CLI exposed via openstackclient is mature enough to 
say with certainty that we can deprecate v2.0. It will be around for at least 
FOUR releases, with the authentication routes (POST /auth/tokens) potentially 
sticking around for longer.

* for a complete list: 
https://blueprints.launchpad.net/keystone/+spec/deprecated-as-of-mitaka


If you have ANY concern about the following, please speak up now and let us 

Re: [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

[Steve Martinelli]

Trying to summarize here...

  - There isn't much interest in keeping eventlet around.
  - Folks are OK with running keystone in a WSGI server, but feel they are
constrained by Apache.
  - uWSGI could help to support multiple web servers.

My opinion:

  - Adding support for uWSGI definitely sounds like it's worth
investigating, but not achievable in this release (unless someone already
has something cooked up).
  - I'm tempted to let eventlet stick around another release, since it's
causing pain on some of our operators.
  - Other folks have managed to run keystone in a web server (and hopefully
not feel pain when doing so!), so it might be worth getting technical
details on just how it was accomplished. If we get an OK from the operator
community later on in mitaka, I'd still be OK with removing eventlet, but I
don't want to break folks.

stevemar

From:   John Dewey 
100% agree.

We should look at uwsgi as the reference architecture.  Nginx/Apache/etc
should be interchangeable, and up to the operator which they choose to use.
Hell, with tcp load balancing now in opensource Nginx, I could get rid of
Apache and HAProxy by utilizing uwsgi.

John


On November 30, 2015 at 1:05:26 PM, Paul Czarkowski (pczarkowski
+openstack...@bluebox.net) wrote:


  I don't have a problem with eventlet itself going away, but I do feel
  that keystone should pick a python based web server capable of
  running WSGI apps ( such as uWSGI ) for the reference implementation
  rather than Apache which can be declared appropriately in the
  requirements.txt of the project.   I feel it is important to allow
  the operator to make choices based on their organization's skill sets
  ( i.e. apache vs nginx ) to help keep complexity low.

  I understand there are some newer features that rely on Apache
  ( federation, etc )  but we should allow the need for those features
  inform the operators choice of web server rather than force it for
  everybody.

  Having a default implementation using uWSGI is also more inline with
  the 12 factor way of writing applications and will run a lot more
  comfortably in [application] containers than apache would which is
  probably an important consideration given how many people are focused
  on being able to run openstack projects inside containers.

  On Mon, Nov 30, 2015 at 2:36 PM, Jesse Keating 
  wrote:
I have an objection to eventlet going away. We have problems with
running Apache and mod_wsgi with multiple python virtual
environments. In some of our stacks we're running both Horizon and
Keystone. Each get their own virtual environment. Apache mod_wsgi
doesn't really work that way, so we'd have to do some ugly hacks to
expose the python environments of both to Apache at the same time.

I believe we spoke about this at Summit. Have you had time to look
into this scenario and have suggestions?


- jlk

On Mon, Nov 30, 2015 at 10:26 AM, Steve Martinelli <
steve...@ca.ibm.com> wrote:
 This post is being sent again to the operators mailing list, and i
 apologize if it's duplicated for some folks. The original thread
 is here:
 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/080816.html


 In the Mitaka release, the keystone team will be removing
 functionality that was marked for deprecation in Kilo, and marking
 certain functions as deprecated in Mitaka (that may be removed in
 at least 2 cycles).

 removing deprecated functionality
 =

 This is not a full list, but these are by and large the most
 contentious topics.

 * Eventlet support: This was marked as deprecated back in Kilo and
 is currently scheduled to be removed in Mitaka in favor of running
 keystone in a WSGI server. This is currently how we test keystone
 in the gate, and based on the feedback we received at the summit,
 a lot of folks have moved to running keystone under Apache since
 we’ve announced this change. OpenStack's CI is configured to
 mainly test using this deployment model. See [0] for when we
 started to issue warnings.

 * Using LDAP to store assignment data: Like eventlet support, this
 feature was also deprecated in Kilo and scheduled to be removed in
 Mitaka. To store assignment data (role assignments) we suggest
 using an SQL based backend rather than LDAP. See [1] for when we
 started to issue warnings.

 * Using LDAP to store project and domain data: The same as above,
 see [2] for when we started to issue warnings.

 * for a complete list:
 https://blueprints.launchpad.net/keystone/+spec/removed-as-of-mitaka


 functions deprecated as of mitaka

[Openstack-operators] devstack install Openstack on CENTOS 7 hungs

[????????????]

Hi!
I'm a newbie  to Openstack.
I deploy Openstack use devstack on CENTOS 
7(http://docs.openstack.org/developer/devstack/),when I run ./stack.sh, some 
error occur:
2015-11-30 07:46:57.699 | Collecting pycadf===1.1.0 (from -c 
/opt/stack/requirements/upper-constraints.txt (line 236))
2015-11-30 07:47:10.403 |   Downloading pycadf-1.1.0-py2-none-any.whl
2015-11-30 07:47:19.449 | Collecting python-keystoneclient===1.8.1 (from -c 
/opt/stack/requirements/upper-constraints.txt (line 264))
2015-11-30 07:47:30.418 |   Downloading 
python_keystoneclient-1.8.1-py2.py3-none-any.whl (430kB)
2015-11-30 07:51:16.217 |   Hash of the package 
https://pypi.python.org/packages/py2.py3/p/python-keystoneclient/python_keystoneclient-1.8.1-py2.py3-none-any.whl#md5=6e15a0bcbb7152278c302495bc5889af
 (from https://pypi.python.org/simple/python-keystoneclient/) 
(b5b81960bf2ba1fb1a845ca2e1c737c6) doesn't match the expected hash 
6e15a0bcbb7152278c302495bc5889af!
2015-11-30 07:51:16.236 | Bad md5 hash for package 
https://pypi.python.org/packages/py2.py3/p/python-keystoneclient/python_keystoneclient-1.8.1-py2.py3-none-any.whl#md5=6e15a0bcbb7152278c302495bc5889af
 (from https://pypi.python.org/simple/python-keystoneclient/)
2015-11-30 07:51:16.282 | + exit_trap
2015-11-30 07:51:16.282 | + local r=1
2015-11-30 07:51:16.283 | ++ jobs -p
2015-11-30 07:51:16.283 | + jobs=
2015-11-30 07:51:16.283 | + [[ -n '' ]]
2015-11-30 07:51:16.283 | + kill_spinner
2015-11-30 07:51:16.283 | + '[' '!' -z '' ']'
2015-11-30 07:51:16.283 | + [[ 1 -ne 0 ]]
2015-11-30 07:51:16.283 | + echo 'Error on exit'
2015-11-30 07:51:16.284 | Error on exit
2015-11-30 07:51:16.284 | + [[ -z /opt/stack/logs ]]
2015-11-30 07:51:16.284 | + /tmp/devstack/tools/worlddump.py -d /opt/stack/logs
2015-11-30 07:51:16.649 | + exit 1


How to fix the problem?
Thanks.___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] OPs Midcycle location discussion.

[Shamail Tahir]

Hi everyone,

The Product WG is finalizing our mid-cycle plans and I wanted to confirm
the conclusion of this thread to bring into that discussion...

Reviewing the numerous responses here, it seems like the majority opted for
option #1 (one 'official' ops mid-cycle but not precluding regional ones)
and, in this specific instance, the 'official' one is the one happening in
Manchester.  Would you agree with this summary?

If we want to attempt a hub/spoke model (e.g. start etherpad-based
conversations at the 'official' mid-cycle but continue to build on those
topics at the regional events) then we can also discuss ideas on how to
help with the effort of summarizing discussions and topics.

Thanks,
Shamail


On Wed, Nov 18, 2015 at 4:36 PM, Clayton O'Neill  wrote:

> On Wed, Nov 18, 2015 at 4:24 PM, Erik McCormick <
> emccorm...@cirrusseven.com> wrote:
>
>> > 2) More technically we'll need to address the challenge of local
>> > sound, how to we ensure all the mostly spontaious talk in a large work
>> > session makes it to remote participants.  Passing a mic is a bit
>> > cumbersome and hard to enforce, while mic'ing the room to properly get
>> > ambient sound isn't likely something we can do without significant
>> > professional help.
>> >
>>
>> This is a technical issue that needs dealing with for sure. Passing a
>> mic is absolutely not practical, so it would need to be some sort of
>> ambient thing. We can't even get people to consistently go to a mic
>> during Q at the end of summit presentations. I've seen enough
>> teleconferencing systems that cover large boardroom settings to know
>> that such things exist, but I have no specific knowledge of what they
>> are, if they can be rented, or how much they cost. That will require a
>> lot of digging into.
>
>
> A key difference between the Ceph summit and the Ops Mid-cycle appears to
> be that the Ops Mid-cycle is at least an order of magnitude bigger.
>
> For a good amount of the Philly and Palo Alto mid-cycles there were 200ish
> people in a single room.  Audio was a problem even for people sitting in
> the room at times.   I think this is beyond “large boardroom” size.
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [OpenStack-docs] [networking-guide] IRC Meeting

[Matt Kassawara]

I think 16 UTC works well for most of the US, but doesn't include APAC and
probably not ideal for EU because it bumps into Friday evening. How about
alternating US/EU and APAC meetings every other week (similar to other
documentation meetings) and move the US/EU meeting to another day?

On Sun, Nov 29, 2015 at 6:44 PM, Edgar Magana 
wrote:

> Thanks Lana!
>
> Indeed contributors of OpenStack! Join us and provide your input.
> Now, including the Ops ML.
>
> Edgar
>
>
>
> On 11/29/15, 5:40 PM, "Lana Brindley"  wrote:
>
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA256
> >
> >
> >Forwarding to the mailing list to increase exposure.
> >
> >If you are interested in attending the networking guide meetings, please
> have your say on the meeting times.
> >
> >Thanks,
> >Lana
> >
> >-  Forwarded Message 
> >Subject: Fwd: Networking Guide IRC Meeting
> >Date: Mon, 30 Nov 2015 01:33:54 +
> >From: Lana Brindley 
> >To: openst...@lanabrindley.com 
> >
> >
> >
> >Begin forwarded message:
> >
> >From: "Edgar Magaña Perdomo"  >>
> >Date: 30 November 2015 at 10:31:12 AM AEST
> >
> >
> >Team,
> >
> >You may noticed that I added a patch to include an IRC meeting focus on
> the networking guide:
> >https://review.openstack.org/#/c/251169/
> >
> >I am proposing:
> >Bi-weekly on Friday 1600 UTC
> >
> >Please, include your comments and also please confirm your commitment.
> >
> >Thanks,
> >
> >- --
> >Edgar
> >
> >
> >
> >-BEGIN PGP SIGNATURE-
> >Version: GnuPG v2
> >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >iQEcBAEBCAAGBQJWW6kBAAoJELppzVb4+KUy8ysH/1mjX5gqVKsJoML1S4LMp2S6
> >lrXeq/ciUEDQN+F1O7tcTRWUIxMzw7MUGlW4KkfjXcbPT9LNqpeuTnXYzMQwpJOF
> >eYXGZvLrqO4Jw0vPX6JpDO5lmMGtv1iyXYDUoBNZvb8aV0dUj+ANGefI9LputtR6
> >iDuSuEpWBv/MPZrH02grdomosYEqbwfHmQGDCsH1lS3fGYcMXub5DwQqkb2vMklQ
> >w8cugXr0JCrTeFylZl6rnuUQAFP4WX1MBVXr96AtngrFN1POnqsHf6RO53v4YPJx
> >oqmka9uKv1o8ocuJvFhkhjzoDDYlCfKkips0f6od1EraZrSaFy88sex+j2thxWw=
> >=hObr
> >-END PGP SIGNATURE-
> >
> >___
> >OpenStack-docs mailing list
> >openstack-d...@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators