[openstack-dev] Reminder: Project & release status meeting - 21:00 UTC

Today in the Project & release status meeting, we'll look into havana-3 progress, and refine the ones that were looking over-optimistic (neutron, nova, heat, horizon). Feel free to add extra topics to the agenda: [1] http://wiki.openstack.org/Meetings/ProjectMeeting All Technical Leads for integr

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

I think we need a further constraint: We must ensure that yum/etc believes that the python-* packages are installed. There are a number of packages that we are currently purging in devstack due to the redhat/pip conflict which we cannot purge (e.g. python-lxml, python-c rypto) as they will remo

Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302

Hi, What about saying that you are not restricted to use H302 in test code test_*.py ? On Mon, Aug 05, 2013 at 08:03:26PM -0700, Clint Byrum wrote: > Excerpts from Robert Collins's message of 2013-08-05 19:26:20 -0700: > > I wanted to get a temperature reading from everyone on this style guidelin

Re: [openstack-dev] [nova][glance] Future of nova's image API

Christopher Yeoh wrote: > I'd like to suggest that we make a final decision around it at the Nova > meeting this week. You should bring this question to the general ML so that we get input from users/deployers on that before taking a final decision. -- Thierry Carrez (ttx) _

Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)

So, From experimenting with, and looking at the WSME code - raising a status with `pecan.abort(404)` etc doesn't actually work. WSME sees that, and helpfully swaps it out for a HTTP 500 ;) The author of WSME even says there is currently no way to return a 404. So, ceilometer must be either no

Re: [openstack-dev] [Glance] async worker design meeting tomorrow!

On 08/05/2013 04:34 AM, Brian Rosmaita wrote: > Well, it's tomorrow as I write this, maybe it's today as you read > this. Anyway: > > - asynchronous worker meeting Tuesday 6 Aug 2013 14:00 UTC in > #openstack-glance > > - the etherpad > https://etherpad.openstack.org/havana-glance-requirements w

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

Hi Dina and All, Please see comments inline. We can drill down on the specifics off-line if that's more practical. Thanks in advance, Patrick On 8/5/13 3:19 PM, Dina Belova wrote: Hello, everyone! Patrick, Julien, thank you so much for your comments. As for the moments Patrick mentioned in

[openstack-dev] [Ceilometer] Another introduction

Hey everyone, I'm a developer at XLAB d.o.o. in Ljubljana. My colleagues are part of the EU research project Contrail, dealing with cloud federation, and I got hired to work on Contrail-Openstack integration. Firstly I'm trying to integrate alarming and since alarming in Ceilometer is still

Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302

On 08/05/2013 10:38 PM, Monty Taylor wrote: On 08/05/2013 11:26 PM, Robert Collins wrote: I wanted to get a temperature reading from everyone on this style guideline. My view on it is that it's a useful heuristic but shouldn't be a golden rule applied everywhere. Things like matches are desig

Re: [openstack-dev] [nova][glance] Future of nova's image API

Joe Gordon wrote: > On Mon, Aug 5, 2013 at 9:11 AM, Roman Bogorodskiy > wrote: > > > Joe Gordon wrote: > > > > > Hi All, > > > > > > even though Glance, has been pulled out of Nova years ago, Nova still > > has a > > > images API that proxies back to Glance. Since Nova is in the process of

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

On Mon, Aug 05, 2013 at 03:37:24PM -0700, Jay Buffington wrote: > I used Anvil for the first three months, but it required constant > updating of dependency versions and it didn't support quantum. What do you mean by "updating" here? The rpm packages being updated causing a lot of churn, or some

Re: [openstack-dev] [Neutron] Network Information Sharing with OpenFlow Controller

Hi Kyle, Thanks for information. We want to follow different approach like non-intrusive approach. We will share more details on this later. Regards, Balaji.P -Original Message- From: Kyle Mestery (kmestery) [mailto:[email protected]] Sent: Monday, August 05, 2013 7:34 AM To: OpenSta

[openstack-dev] Adding extra_specs to flavor show and detail call

Hi, We are working on a blueprint, which adds extra specs to the flavor show and detail calls. As a part of this, we have added a new extension called FlavorWithExtraSpecs. When this extension is enabled, the extra_specs o

[openstack-dev] [Swift] container-sync problems in global data sync senario

Hi, I’m interested in container-sync to take a snapshot of swift. I want to sync data between two swift clusters distributed in multiple locations. It is assumed that there are two swift clusters located in two places, and the container-sync syncs data from one cluster to the other cluster thro

Re: [openstack-dev] [Ceilometer] Nomination for Mehdi Abaakouk

Darn, thought I'd replied to this already! Anyways, a belated +1 and a hearty welcome to Mehdi :) Cheers, Eoghan - Original Message - > Hi, > > I'd like to propose to add Mehdi Abaakouk (sileht) to ceilometer-core. > He has been a valuable contributor for the last months, doing a lot o

Re: [openstack-dev] [Ceilometer] Another introduction

On 08/06/2013 08:31 AM, Nejc Saje wrote: > Hey everyone, > > I'm a developer at XLAB d.o.o. in Ljubljana. My colleagues are part of > the EU research project Contrail, dealing with cloud federation, and I > got hired to work on Contrail-Openstack integration. > > Firstly I'm trying to integrate

Re: [openstack-dev] [Swift] gate on functional tests

They were non-voting. The change is that they are now voting. --John On Aug 5, 2013, at 9:17 PM, Chmouel Boudjnah wrote: > On Mon, Aug 5, 2013 at 10:59 PM, John Dickinson wrote: >> The Swift functional tests have been running as an advisory for a bit now on >> all Swift patches. Everything a

Re: [openstack-dev] devstack modifying git repository

Hey Chmouel! Good point. I think we could add a check to see if there are any changes in the repo and skip the update if there are not. Or, we could protect that action in a variable and have devstack-gate set that variable... what do you guys think? On 08/06/2013 12:56 AM, Chmouel Boudjnah wrote

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 08/06/2013 01:19 AM, Jamie Lennox wrote: Hi all, Partially in response to the trusts API review in keystoneclient (https://review.openstack.org/#/c/39899/ ) and my work on keystone API version discoverability (spell-check disagrees but I'm going to assume that's a word - https://review.openst

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 08/06/2013 01:19 AM, Jamie Lennox wrote: Hi all, Partially in response to the trusts API review in keystoneclient (https://review.openstack.org/#/c/39899/ ) and my work on keystone API version discoverability (spell-check disagrees but I'm going to assume that's a word - https://review.openst

Re: [openstack-dev] devstack modifying git repository

Hey Monty, On Tue, Aug 6, 2013 at 3:18 PM, Monty Taylor wrote: > Good point. I think we could add a check to see if there are any changes > in the repo and skip the update if there are not. Or, we could protect > that action in a variable and have devstack-gate set that variable... > what do you

Re: [openstack-dev] [Ceilometer] Another introduction

On 8/6/13 7:52 AM, "Sandy Walsh" wrote: > > >On 08/06/2013 08:31 AM, Nejc Saje wrote: >> Hey everyone, >> >> I'm a developer at XLAB d.o.o. in Ljubljana. My colleagues are part of >> the EU research project Contrail, dealing with cloud federation, and I >> got hired to work on Contrail-Opensta

Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)

On Tue, Aug 6, 2013 at 5:35 AM, Mac Innes, Kiall wrote: > > So, > > From experimenting with, and looking at the WSME code - raising a > status with `pecan.abort(404)` etc doesn't actually work. > > WSME sees that, and helpfully swaps it out for a HTTP 500 ;) > > The author of WSME even says there

Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302

On 08/06/2013 07:32 AM, Sean Dague wrote: On 08/05/2013 10:38 PM, Monty Taylor wrote: On 08/05/2013 11:26 PM, Robert Collins wrote: I wanted to get a temperature reading from everyone on this style guideline. My view on it is that it's a useful heuristic but shouldn't be a golden rule applie

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

as a general principle I would think it is a good idea for clients to be able to interrogate Keystone to determine what extensions it supports. Most protocols have some mechanism for determining what extensions/versions are supported by the server, and what optional features are implemented.

Re: [openstack-dev] instances fail to boot on el6 (glance schema error issue)

Okay. The quick fix is to remove the extra Glance V2 call when CONF.allowed_direct_url_schemes is disabled. https://review.openstack.org/#/c/40426/1 This effectively avoids calling the Glance V2 API on python 2.6 (thus avoiding the schema validation issue). The real issue here is still unreso

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On Aug 6, 2013, at 8:36 AM, Adam Young wrote: > On 08/06/2013 01:19 AM, Jamie Lennox wrote: >> Hi all, >> >> Partially in response to the trusts API review in keystoneclient >> (https://review.openstack.org/#/c/39899/ ) and my work on keystone API >> version discoverability (spell-check disagree

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of usability. This is the crux of the issue. Everyone who participates in standardisation meetings has their own agenda to follow: their

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams wrote: > > On Aug 6, 2013, at 8:36 AM, Adam Young wrote: > > > On 08/06/2013 01:19 AM, Jamie Lennox wrote: > >> Hi all, > >> > >> Partially in response to the trusts API review in keystoneclient > >> (https://review.openstack.org/#/c/39899/ ) and my

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 08/06/2013 10:54 AM, Dolph Mathews wrote: On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams mailto:[email protected]>> wrote: On Aug 6, 2013, at 8:36 AM, Adam Young wrote: > On 08/06/2013 01:19 AM, Jamie Lennox wrote: >> Hi all, >> >> Partially in response to

[openstack-dev] Hyper-V meeting canceled

Hi All, I need to cancel the hyper-v meeting today. We will return to the normal meeting schedule next week. Best, pp Peter J. Pouliot, CISSP Senior SDET, OpenStack Microsoft New England Research & Development Center One Memorial Drive,Cambridge, MA 02142 [email protected]

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

On Mon, Aug 5, 2013 at 8:37 PM, Ian Wienand wrote: > I think Anvil is working with the package management system so that > scenario doesn't happen. The "fine, those can be re-installed with > pip" bit is where the problem occurs. Agreed. > The "whole lot" bit is important, because you can't hav

Re: [openstack-dev] [Glance] async worker design meeting tomorrow!

John, Thanks for your input, we discussed your points at the meeting. The results are here: https://etherpad.openstack.org/glance-async-worker-mtg-agenda There's one point we postponed to discuss until Thursday's regular glance meeting, you can explain it more then. Also, the complete meet

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

On Tue, Aug 6, 2013 at 4:36 AM, Ian Wienand wrote: > On Mon, Aug 05, 2013 at 03:37:24PM -0700, Jay Buffington wrote: > > I used Anvil for the first three months, but it required constant > > updating of dependency versions and it didn't support quantum. > > What do you mean by "updating" here? T

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

On Tue, Aug 6, 2013 at 3:50 AM, Bob Ball wrote: > I think we need a further constraint: > > We must ensure that yum/etc believes that the python-* packages are installed. If we want the rest of the system to use them, yes. > If we want to install a newer version of the python-* packages then we

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

I think jay your usage also was before anvil started to build all the *missing* dependencies automatically (something u inspired me to get going in the first place) so hopefully said updates to rhel.yaml are only now needed for exceptions and not the common path :) Sent from my really tiny devi

[openstack-dev] Blueprint for Nova native image building

Hello, A blueprint has been registered regarding API additions to Nova to enable the creation of base images from external OS install sources. This provides a way to build images from scratch via native OS installer tools using only the resources provided through Nova. These images can then be fu

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 08/06/2013 10:45 AM, David Chadwick wrote: On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of usability. This is the crux of the issue. Everyone who participates in standardisation

Re: [openstack-dev] [Ceilometer] Looking for some help understanding default meters

On 8/5/13 4:02 PM, "Monsyne Dragon" wrote: > > >On 8/5/13 8:40 AM, "Julien Danjou" wrote: > >>On Mon, Aug 05 2013, Thomas Maddox wrote: >> >>> Thinking about it, the latter option seems to describe a very real >>>concern >>> going forward that didn't occur to me when I was wandering around the

[openstack-dev] [Heat] The way to use one config file with new oslo module

Hi, Since https://review.openstack.org/#/c/36476/ has been merged, heat could use only one configuration file : heat.conf instead of heat-engine.conf, heat-api.conf, etc. I would like your thoughts about deleting old configuration files, since that could break something in the CI. I already made

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 08/06/2013 11:53 AM, Jay Pipes wrote: On 08/06/2013 10:45 AM, David Chadwick wrote: On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of usability. This is the crux of the issue. Eve

Re: [openstack-dev] [Nova] Blueprint approval

On 08/06/2013 02:25 AM, Gary Kotton wrote: > Hi, > > Would it be possible to get approval for the following blueprint - > https://blueprints.launchpad.net/openstack/?searchtext=vmware-nova-cinder-support > > A WIP review has been posted. Today I am going to add in the unit tests > so hopefully th

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On Tue, Aug 6, 2013 at 10:53 AM, Jay Pipes wrote: > On 08/06/2013 10:45 AM, David Chadwick wrote: > >> >> >> On 06/08/2013 14:46, Jay Pipes wrote: >> >>> API extensions are more hassle than anything else. Let us promote >>> standards, not endless extensibility at the expense of usability. >>> >>

Re: [openstack-dev] Blueprint for Nova native image building

On 08/06/2013 11:53 AM, Ian Mcleod wrote: > Hello, > > A blueprint has been registered regarding API additions to Nova to > enable the creation of base images from external OS install sources. > This provides a way to build images from scratch via native OS installer > tools using only the resourc

Re: [openstack-dev] [Nova] Blueprint approval

Thanks Russell! # Shawn Hartsock - Original Message - > From: "Russell Bryant" > To: [email protected] > Sent: Tuesday, August 6, 2013 11:30:19 AM > Subject: Re: [openstack-dev] [Nova] Blueprint approval > > On 08/06/2013 02:25 AM, Gary Kotton wrote: > > Hi, > > > > Wou

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

On 08/06/2013 11:19 AM, Dean Troyer wrote: > And that is the crux of the problem. When both can be installed > side-by-side and sys.path is in control of the order, things work. > This is such a fundamental problem in the distro that I am beginning > to thing that we need to address it ourselves.

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

On Tue, Aug 6, 2013 at 8:35 AM, Joshua Harlow wrote: > I think jay your usage also was before anvil started to build all the > *missing* dependencies automatically (something u inspired me to get going > in the first place) so hopefully said updates to rhel.yaml are only now > needed for exceptio

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 06/08/2013 16:53, Jay Pipes wrote: On 08/06/2013 10:45 AM, David Chadwick wrote: On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of usability. This is the crux of the issue. Ever

Re: [openstack-dev] [climate] Mirantis proposal to extend Climate to support virtual resources reservation

Some thoughts: 0. Should Climate also address the need for an eviction service? That is, a service that can weight incoming requests and existing resource allocations using some set of policies and evict an existing resource allocations to make room for the higher weighted request. Eviction is nec

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 08/06/2013 12:57 PM, David Chadwick wrote: On 06/08/2013 16:53, Jay Pipes wrote: On 08/06/2013 10:45 AM, David Chadwick wrote: On 06/08/2013 14:46, Jay Pipes wrote: API extensions are more hassle than anything else. Let us promote standards, not endless extensibility at the expense of u

[openstack-dev] Please release new client library releases

Hey all! As you know, we're been battling the effects of the setuptools/distribute re-merge and upgrade for about a month now. It's mostly settled down, but there are still cases where transitive dependencies on things that depend on things that depend on distribute can screw us. At the moment, th

Re: [openstack-dev] Python overhead for rootwrap

> Personally I'm of the opinion that from an architectural POV, use of > either rootwrap or sudo is a bad solution, so arguing about which is > better is really missing the bigger picture. In Linux, there has been > a move away from use of sudo or similar approaches, towards the idea > of having pr

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 06/08/2013 18:11, Jay Pipes wrote: What SMTP, DNS and LDAP extensions are in use by systems that need to interoperate in the same way that Keystone does? <-- This is a genuine question, not sarcasm. I'm truly curious. Take SMTP for example. My Thunderbird client needs to know what authent

[openstack-dev] [glance] Should image size/checksum be immutable for active images?

Hi, There are cases where an image's 'size' or 'checksum' values need to be modified before an image becomes active; but do we need, as I think we currently do, to allow users to change them once an image becomes active? Without the 'size' pinned down an operator can't necessarily trust the curr

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

Agreed with all your yum issues, its a bit of a pain. With the help of a few others in anvil we have made a small-mini helper tool (that uses the same underlying yum python apis) so that we can get better control over the whole process. - https://github.com/stackforge/anvil/tree/master/tools#yy

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 08/06/2013 01:21 PM, David Chadwick wrote: On 06/08/2013 18:11, Jay Pipes wrote: What SMTP, DNS and LDAP extensions are in use by systems that need to interoperate in the same way that Keystone does? <-- This is a genuine question, not sarcasm. I'm truly curious. Take SMTP for example. My

Re: [openstack-dev] [glance] Should image size/checksum be immutable for active images?

On 08/06/2013 01:30 PM, [email protected] wrote: Hi, There are cases where an image's 'size' or 'checksum' values need to be modified before an image becomes active; but do we need, as I think we currently do, to allow users to change them once an image becomes active? Without the 'size' pi

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

Hi, I would say, use a separated virtual environment in devstack - without the --system-site-packages switch, of course, and set it up as a user. Install the packages that are needed in order to be able to pip install them (like libxslt-dev). It's a development environment. I think my email is equ

Re: [openstack-dev] [Nova] Blueprint approval

Thank you! -Original Message- From: Russell Bryant [mailto:[email protected]] Sent: Tuesday, August 06, 2013 6:30 PM To: [email protected] Subject: Re: [openstack-dev] [Nova] Blueprint approval On 08/06/2013 02:25 AM, Gary Kotton wrote: > Hi, > > Would it be possible to

Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302

another -1 from me for dropping it from hacking. I've been bitten by both lack of explicit usage and review bikeshedding on this exact thing. -Alex -Original Message- From: "Sean Dague" Sent: Tuesday, August 6, 2013 7:32am To: [email protected] Subject: Re: [openstack-d

[openstack-dev] [Nova] nova-api won't start in devstack

I just downloaded devstack and I am getting this error: 2013-08-06 11:28:28.938 TRACE nova Traceback (most recent call last): 2013-08-06 11:28:28.938 TRACE nova File "/usr/local/bin/nova-api", line 10, in 2013-08-06 11:28:28.938 TRACE nova sys.exit(main()) 2013-08-06 11:28:28.938 TRACE nova

Re: [openstack-dev] Blueprint for Nova native image building

On 08/06/2013 12:20 PM, Russell Bryant wrote: > On 08/06/2013 11:53 AM, Ian Mcleod wrote: >> Hello, >> >> A blueprint has been registered regarding API additions to Nova to >> enable the creation of base images from external OS install sources. >> This provides a way to build images from scratch vi

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

Excerpts from Dean Troyer's message of 2013-08-05 10:03:07 -0700: > * about-face on all-packages to all-PyPI (mtaylor): I'm still on the > use packages where possible side but DevStack specifically is not in > the packaging business. If it were we'd do what Java folk (*sorry*) > have long taken th

Re: [openstack-dev] [glance] Should image size/checksum be immutable for active images?

Do u know what cases the 'size' or 'checksum' needs to be modified? I'd hope for immutability in these 2 things. On 8/6/13 10:39 AM, "Jay Pipes" wrote: >On 08/06/2013 01:30 PM, [email protected] wrote: >> Hi, >> >> There are cases where an image's 'size' or 'checksum' values need to be >> m

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

On 08/06/2013 02:44 PM, Mate Lakat wrote: > Hi, > > I would say, use a separated virtual environment in devstack - without > the --system-site-packages switch, of course, and set it up as a user. > Install the packages that are needed in order to be able to pip install > them (like libxslt-dev).

Re: [openstack-dev] Blueprint for Nova native image building

On 08/06/2013 03:46 PM, Russell Bryant wrote: > On 08/06/2013 12:20 PM, Russell Bryant wrote: >> On 08/06/2013 11:53 AM, Ian Mcleod wrote: >>> Hello, >>> >>> A blueprint has been registered regarding API additions to Nova to >>> enable the creation of base images from external OS install sources.

Re: [openstack-dev] [Nova] nova-api won't start in devstack

On Aug 6, 2013, at 1:33 PM, Edgar Magana wrote: > > I just downloaded devstack and I am getting this error: > > 2013-08-06 11:28:28.938 TRACE nova Traceback (most recent call last): > 2013-08-06 11:28:28.938 TRACE nova File "/usr/local/bin/nova-api", line 10, > in > 2013-08-06 11:28:28.938 T

[openstack-dev] Proposing Morgan Fainberg for keystone-core

Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Friday, thanks! -Dolph

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

On 08/06/2013 03:20 PM, Dolph Mathews wrote: Through feedback on code reviews and blueprints, Morgan clearly has the best interests of the project itself in mind. I'd love for his votes to carry a bit more weight! https://review.openstack.org/#/dashboard/2903 Respond with +1/-1's before Frida

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

+1 Best Regards, Lance Bragstad Software Engineer - OpenStack Cloud Solutions and OpenStack Development T/L 553-5409, External 507-253-5409 [email protected], Bld 015-2/C118 From: Dolph Mathews To: OpenStack Development Mailing List , Date: 08/06/2013 02:23 PM Subject:

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

+1 from me, Morgan would be a great addition. Henry On 6 Aug 2013, at 20:20, Dolph Mathews wrote: > Through feedback on code reviews and blueprints, Morgan clearly has the best > interests of the project itself in mind. I'd love for his votes to carry a > bit more weight! > > https://review.

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

+1! Guang From: Dolph Mathews [mailto:[email protected]] Sent: Tuesday, August 06, 2013 12:20 PM To: OpenStack Development Mailing List Subject: [openstack-dev] Proposing Morgan Fainberg for keystone-core Through feedback on code reviews and blueprints, Morgan clearly has t

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

Excerpts from Jay Pipes's message of 2013-08-06 10:34:30 -0700: > On 08/06/2013 01:21 PM, David Chadwick wrote: > > > > > > On 06/08/2013 18:11, Jay Pipes wrote: > >> What SMTP, DNS and LDAP extensions are in use by systems that need to > >> interoperate in the same way that Keystone does? <-- This

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

Easy +1 Thanks, _ Steve Martinelli | A4-317 @ IBM Toronto Software Lab Software Developer - OpenStack Phone: (905) 413-2851 E-Mail: [email protected] From: "Yee, Guang" To: OpenStack Development Mailing List , Date: 08/06/201

Re: [openstack-dev] [Nova] nova-api won't start in devstack

I found the problem: python-boto and python-cmd2 had the wrong version. I have already installed those libraries. Cheers, Edgar From: Edgar Magana Date: Tuesday, August 6, 2013 11:33 AM To: OpenStack List Subject: [Nova] nova-api won't start in devstack I just downloaded devstack and I a

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On Aug 6, 2013, at 12:34 PM, Jay Pipes wrote: > On 08/06/2013 01:21 PM, David Chadwick wrote: >> >> >> On 06/08/2013 18:11, Jay Pipes wrote: >>> What SMTP, DNS and LDAP extensions are in use by systems that need to >>> interoperate in the same way that Keystone does? <-- This is a genuine >>> q

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

+1 on Morgan. He is an outstanding contributor! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: [email protected] Assistant: Cindy Willman (919) 268-5296 From: Dolph Mathews To: OpenStack Development Mailing List Date: 08/06/2013 03:22 PM Sub

Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302

On Tue, Aug 6, 2013 at 6:32 AM, Sean Dague wrote: > > The reason we go hard and fast on certain rules is to reduce review time > by people. If something is up for debate we get bikeshedding in reviews > where one reviewer tells someone to do it one way, 2 days later they update > their review, an

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

+1 from me. -- Brant On Tue, Aug 6, 2013 at 3:10 PM, Brad Topol wrote: > +1 on Morgan. He is an outstanding contributor! > > --Brad > > Brad Topol, Ph.D. > IBM Distinguished Engineer > OpenStack > (919) 543-0646 > Internet: [email protected] > Assistant: Cindy Willman (919) 268-5296 > > > >

[openstack-dev] Motion to start using Gerrit for TC votes

Hi! Currently, we make motions by email, then we discuss them by mailing list, then we discuss them more in IRC, then we vote on them - at which point the actual thing voted on may or may not get recorded somewhere easy to find. What if instead we had a repo with a bunch of ReStructureText in it

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On 06/08/2013 20:40, Clint Byrum wrote: Agreed Jay. The successful extensible protocols like IMAP and SMTP are merely allowing new arguments to existing fundamental functions. But the key thing with these protocols is that they have a defined and standardised way of adding new extensions - a

Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302

While I'm torn on this as a developer, it comes down to an ease of understanding the code. In all cases, it is easier to understand where something comes from if you only import modules. Enforcing the import of modules tends to also ensure namespace conflicts don't occur as often. When it comes

Re: [openstack-dev] Blueprint for Nova native image building

The patch referred to (https://review.openstack.org/#/c/38650/) isn't really around adding support to build native images. We're using the existing boot from ISO support feature to load an iPXE ISO into Glance which then can then chain load a menu of installation options from an http server. T

Re: [openstack-dev] Motion to start using Gerrit for TC votes

On Tue, Aug 6, 2013 at 1:32 PM, Monty Taylor wrote: > Hi! > > Currently, we make motions by email, then we discuss them by mailing > list, then we discuss them more in IRC, then we vote on them - at which > point the actual thing voted on may or may not get recorded somewhere > easy to find. > >

Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)

James Slagle wrote: > WSME + pecan is being used in Tuskar: > https://github.com/tuskar/tuskar (OpenStack management API) > > We encountered the same issue discussed here. A solution we settled > on for now was to use a custom Renderer class that could handle > different response codes. You se

Re: [openstack-dev] Motion to start using Gerrit for TC votes

Monty Taylor writes: > Hi! > > Currently, we make motions by email, then we discuss them by mailing > list, then we discuss them more in IRC, then we vote on them - at which > point the actual thing voted on may or may not get recorded somewhere > easy to find. > > What if instead we had a repo w

Re: [openstack-dev] Motion to start using Gerrit for TC votes

+1 2013/8/6 Morgan Fainberg : > > > On Tue, Aug 6, 2013 at 1:32 PM, Monty Taylor wrote: >> >> Hi! >> >> Currently, we make motions by email, then we discuss them by mailing >> list, then we discuss them more in IRC, then we vote on them - at which >> point the actual thing voted on may or may not

Re: [openstack-dev] Motion to start using Gerrit for TC votes

On 2013-08-06 17:32:17 -0300 (-0300), Monty Taylor wrote: [...] > What if instead we had a repo with a bunch of ReStructureText in it - > perhaps a copy of the TC charter and then a dir for additional things > the TC has decided. That repo would be autopublished to a non-wiki > website ... and the

Re: [openstack-dev] Change in openstack/keystone[master]: Implement domain specific Identity backends

Hi Mark, Of particular interest are your views on the changes to keystone/common/config.py. The requirement is that we need to be able to instantiate multiple conf objects (built from different sets of config files). We tried two approaches to this: https://review.openstack.org/#/c/39530/11

Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)

On 06/08/13 21:56, Jonathan LaCour wrote: > James Slagle wrote: > >> WSME + pecan is being used in Tuskar: >> https://github.com/tuskar/tuskar (OpenStack management API) >> >> We encountered the same issue discussed here. A solution we settled >> on for now was to use a custom Renderer class that

[openstack-dev] [neutron] [ml2] [devstack] Per MechanismDriver configuration for ML2 in devstack

Neutron and devstack folks: I've written up some notes [1] on how I'd like to add per-MechanismDriver support into devstack for ML2. This will be very nice to have as the number of ML2 MechanismDrivers increase. My approach for this will allow for complex configurations via localrc variables wi

Re: [openstack-dev] Motion to start using Gerrit for TC votes

On Tue, Aug 6, 2013 at 3:32 PM, Monty Taylor wrote: > Hi! > > Currently, we make motions by email, then we discuss them by mailing > list, then we discuss them more in IRC, then we vote on them - at which > point the actual thing voted on may or may not get recorded somewhere > easy to find. > >

[openstack-dev] [Nova][Cinder] Guest Assisted Snapshots

Greetings, The following blueprint is targeted at Havana. I was reading over the design notes today. I wanted to check on the status of this as well as discuss some of the design details. https://wiki.openstack.org/wiki/Cinder/GuestAssistedSnapshotting https://blueprints.launchpad.net/n

Re: [openstack-dev] Blueprint for Nova native image building

On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote: > > On 08/06/2013 03:46 PM, Russell Bryant wrote: > > On 08/06/2013 12:20 PM, Russell Bryant wrote: > >> On 08/06/2013 11:53 AM, Ian Mcleod wrote: > >>> Hello, > >>> > >>> A blueprint has been registered regarding API additions to Nova to > >>

[openstack-dev] [Horizon][Security] BREACH/CRIME Attack Information

Many of you have probably heard about the "BREACH" attack/security vulnerability in HTTPS traffic that was disclosed recently, and I'd like to take a moment to provide some info about how that affects Horizon. I'm not following the official vulnerability management process because 1. The vulner

Re: [openstack-dev] [Nova][Cinder] Guest Assisted Snapshots

On Tue, Aug 6, 2013 at 4:05 PM, Russell Bryant wrote: > Greetings, > > The following blueprint is targeted at Havana. I was reading over the > design notes today. I wanted to check on the status of this as well as > discuss some of the design details. > > https://wiki.openstack.org/wiki/Cin

Re: [openstack-dev] Proposing Morgan Fainberg for keystone-core

+1 On Tue, 2013-08-06 at 14:20 -0500, Dolph Mathews wrote: > Through feedback on code reviews and blueprints, Morgan clearly has > the best interests of the project itself in mind. I'd love for his > votes to carry a bit more weight! > > > https://review.openstack.org/#/dashboard/2903 > > >

[openstack-dev] [marconi] API stabilization

Folks, I'd like to stabilize the v1 API by the end of the week and close out some long-standing blueprints. Please take a moment to review pending patches: https://review.openstack.org/#/q/status:open+project:stackforge/marconi,n,z Let's get these merged over the next couple of days. Note that

Re: [openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages

On Tue, Aug 6, 2013 at 12:00 PM, Monty Taylor wrote: > On 08/06/2013 02:44 PM, Mate Lakat wrote: > > I would say, use a separated virtual environment in devstack - without > > the --system-site-packages switch, of course, and set it up as a user. > > Install the packages that are needed in order

Re: [openstack-dev] [Keystone] V3 Extensions Discoverability

On Tue, 2013-08-06 at 11:17 -0400, Adam Young wrote: > On 08/06/2013 10:54 AM, Dolph Mathews wrote: > > > > > On Tue, Aug 6, 2013 at 9:28 AM, Jorge Williams > > wrote: > > > > On Aug 6, 2013, at 8:36 AM, Adam Young wrote: > > > > > On 08/06/2013 01:19 AM, Jamie

  1   2   >