Re: [openstack-dev] battling stale .pyc files

On Sep 15, 2014, at 4:34 AM, Lucas Alvares Gomes wrote: > So, although I like the fix proposed and I would +1 that idea, I'm > also not very concerned if most of the people don't want that. Because > as you just said we can fix it locally easily. I didn't set it to my > .local but the way I do n

Re: [openstack-dev] [requirements][horizon] Dependency freeze exceptions

Radomir Dopieralski wrote: > I would like to request dependency freeze exceptions for the following > patches for Horizon: > > https://review.openstack.org/#/c/121509/ > https://review.openstack.org/#/c/122410/ > > and > > https://review.openstack.org/#/c/113184/ > > They are all fixing high pr

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

On 09/18/2014 09:25 PM, Gordon Sim wrote: > On 09/18/2014 03:45 PM, Flavio Percoco wrote: >> On 09/18/2014 04:09 PM, Gordon Sim wrote: >>> Is the replication synchronous or asynchronous with respect to client >>> calls? E.g. will the response to a post of messages be returned only >>> once the repl

Re: [openstack-dev] Oslo final releases ready

Thomas Goirand wrote: > However, I made a small mistake. I used 1.4.0.0~a5 instead of 1.4.0~a5. > As a consequence, I may upload 1.4.0.0 instead of 1.4.0, so that it is > greater than 1.4.0.0~a5 (to avoid adding an EPOC, which is ugly and > annoying to maintain). It's going to be the same version t

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

On 09/18/2014 07:19 PM, Joe Gordon wrote: > > > On Thu, Sep 18, 2014 at 7:45 AM, Flavio Percoco > wrote: > > On 09/18/2014 04:09 PM, Gordon Sim wrote: > > On 09/18/2014 12:31 PM, Flavio Percoco wrote: > >> On 09/17/2014 10:36 PM, Joe Gordon wrote: > >>>

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

On 09/18/2014 07:16 PM, Devananda van der Veen wrote: > On Thu, Sep 18, 2014 at 8:54 AM, Devananda van der Veen > wrote: >> On Thu, Sep 18, 2014 at 7:45 AM, Flavio Percoco wrote: >>> On 09/18/2014 04:09 PM, Gordon Sim wrote: On 09/18/2014 12:31 PM, Flavio Percoco wrote: > Zaqar guarantee

Re: [openstack-dev] [heat][nova] VM restarting on host, failure in convergence

> > All, > > > > Currently OpenStack does not have a built-in HA mechanism for tenant > > instances which could restore virtual machines in case of a host > > failure. Openstack assumes every app is designed for failure and can > > handle instance failure and will self-remediate, but that is

Re: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core

> Hi, > > Nejc has been doing a great work and has been very helpful during the > Juno cycle and his help is very valuable. > > I'd like to propose that we add Nejc Saje to the ceilometer-core group. > > Please, dear ceilometer-core members, reply with your votes! With eight yeas and zero nay

Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

> Hi, > > Dina has been doing a great work and has been very helpful during the > Juno cycle and her help is very valuable. She's been doing a lot of > reviews and has been very active in our community. > > I'd like to propose that we add Dina Belova to the ceilometer-core > group, as I'm convi

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

Joe Gordon wrote: > On Thu, Sep 18, 2014 at 9:02 AM, Devananda van der Veen > mailto:[email protected]>> wrote: >> - guaranteed message order >> - not distributing work across a configurable number of back ends >> >> These are scale-limiting design choices which are reflected in

Re: [openstack-dev] [ceilometer] Performance degradation (docs) for sampling rate less than 10 mins

Hi Tyaptin, Thanks for sharing the document. I appreciate that. Its well documented and shares all the info i was looking for in detail. May be it should be documented along with the Ceilometer for reference purpose. Cheers, Srikanta InIT ¦ ICCLab ZHAW

Re: [openstack-dev] [heat][nova] VM restarting on host failure in convergence

> > In short, what we'll need from nova is to have 100% reliable > > host-health monitor and equally reliable rebuild/evacuate mechanism > > with fencing and scheduler. In heat we need scallable and reliable > > event listener and engine to decide which action to perform in given > > situation

[openstack-dev] Will glance return a deleted image?

hi all: I find a strange behavior that when I use nova image-show uuid, I can get a deleted image it is marked as deleted. is this the correct behavior ? [tagett@stack-01 devstack]$ nova image-show bda62c0e-2b6c-4495-b06e-1fa1e591da80 +--+--+

Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

Thank you folks, it's a big pleasure and responsibility, and I'm really happy to join you :) Thanks! Dina On Fri, Sep 19, 2014 at 12:54 PM, Eoghan Glynn wrote: > > > > Hi, > > > > Dina has been doing a great work and has been very helpful during the > > Juno cycle and her help is very valuable.

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

On 09/19/2014 11:00 AM, Thierry Carrez wrote: > Joe Gordon wrote: >> On Thu, Sep 18, 2014 at 9:02 AM, Devananda van der Veen >> mailto:[email protected]>> wrote: >>> - guaranteed message order >>> - not distributing work across a configurable number of back ends >>> >>> These are

Re: [openstack-dev] [Heat] naming of provider template for docs

> From: Mike Spreitzer > To: "OpenStack Development Mailing List \(not for usage questions\)" > > Date: 19/09/2014 07:15 > Subject: Re: [openstack-dev] [Heat] naming of provider template for docs > > Angus Salkeld wrote on 09/18/2014 09:33:56 PM: > > > Hi > > > I am trying to add some docs to op

Re: [openstack-dev] Oslo final releases ready

Here you are!:) https://review.openstack.org/#/c/122667 On Fri, Sep 19, 2014 at 9:02 AM, Michael Still wrote: > I would like to do a python-novaclient release, but this requirements > commit hasn't yet turned into a requirements proposal for novaclient > (that I can find). Can someone poke that

Re: [openstack-dev] [Heat][Zaqar] Integration plan moving forward

On 09/18/2014 11:51 AM, Angus Salkeld wrote: > > On 18/09/2014 7:11 PM, "Flavio Percoco" > wrote: >> >> Greetings, >> >> If I recall correctly, Heat was planning to adopt Zaqar regardless of >> the result of the graduation attempt (please correct me if I'm wrong). >> Bas

Re: [openstack-dev] [nova] are we going to remove the novaclient v3 shell or what?

> > > > DevStack doesn't register v2.1 endpoint to keytone now, but we can use > > it with calling it directly. > > It is true that it is difficult to use v2.1 API now and we can check > > its behavior via v3 API instead. > > I posted a patch[1] for registering v2.1 endpoint to keystone, and I co

Re: [openstack-dev] [nova] Expand resource name allowed characters

On 09/18/2014 08:49 PM, Clint Byrum wrote: > Excerpts from Christopher Yeoh's message of 2014-09-18 16:57:12 -0700: >> On Thu, 18 Sep 2014 12:12:28 -0400 >> Sean Dague wrote: When we can return the json-schema to user in the future, can we say that means API accepting utf8 or utf8mb4 is

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

Monty Taylor wrote: > I've recently been thinking a lot about Sean's Layers stuff. So I wrote > a blog post which Jim Blair and Devananda were kind enough to help me edit. > > http://inaugust.com/post/108 Hey Monty, As you can imagine, I read that post with great attention. I generally like the

[openstack-dev] [metrics] Another issue when analyzing SSH Gerrit (as young as August 2014)

Hi! After having a more in depth review of data coming from Gerrit, some other issues appear when using the SSH Gerrit API. Some of the dates when reviewing the code (Code-Review, Verified, etc) seem to be inconsistent with the data found in the comments section. Example: issue https://revi

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

Vishvananda Ishaya wrote: > Great writeup. I think there are some great concrete suggestions here. > > A couple more: > > 1. I think we need a better name for Layer #1 that actually represents what > the goal of it is: Infrastructure Services? > 2. We need to be be open to having other Layer #1s

Re: [openstack-dev] [metrics] Another issue when analyzing SSH Gerrit (as young as August 2014)

On Fri, Sep 19, 2014 at 12:30:50PM +0200, Daniel Izquierdo wrote: > Hi! > > After having a more in depth review of data coming from Gerrit, some other > issues appear when using the SSH Gerrit API. > > Some of the dates when reviewing the code (Code-Review, Verified, etc) seem > to be inconsisten

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

On 18/09/2014 22:14, Doug Hellmann wrote: > > On Sep 18, 2014, at 4:34 PM, David Chadwick > wrote: > >> >> >> On 18/09/2014 21:04, Doug Hellmann wrote: >>> >>> On Sep 18, 2014, at 12:36 PM, David Chadwick >>> wrote: >>> Our recent work on federation suggests we need an improvement >

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

> Hi All, > > My understanding of Zaqar is that it's like SQS. SQS uses distributed queues, > which have a few unusual properties [0]: > Message Order > > > Amazon SQS makes a best effort to preserve order in messages, but due to the > distributed nature of the queue, we cannot guarantee you w

Re: [openstack-dev] [oslo-vmware] Propose adding Radoslav to core team

+1 From: Vui Chiap Lam [mailto:[email protected]] Sent: Tuesday, September 16, 2014 10:52 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [oslo-vmware] Propose adding Radoslav to core team +1. Rado has been very instrumental in helping with revie

Re: [openstack-dev] [requirements][horizon] Dependency freeze exceptions

Thierry Carrez wrote: > Radomir Dopieralski wrote: >> I would like to request dependency freeze exceptions for the following >> patches for Horizon: >> >> https://review.openstack.org/#/c/121509/ >> https://review.openstack.org/#/c/122410/ >> >> and >> >> https://review.openstack.org/#/c/113184/ >>

Re: [openstack-dev] [nova][cells] Flavors and cells

I was investigating this issue and this is what I found: In the boot request, the compute layer passes the instance_type_id to the driver layer (driver.spawn) and the driver layer then extracts actual flavor information. However, different drivers extract/use this information differently - - libvi

Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota

Chuck, It seems quite interesting! Are hp or community working to implement it? Giuseppe > -Original Message- > From: Carlino, Chuck [mailto:[email protected]] > Sent: 19 September 2014 04:52 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-

Re: [openstack-dev] [metrics] Another issue when analyzing SSH Gerrit (as young as August 2014)

On Fri, 2014-09-19 at 11:39 +0100, Daniel P. Berrange wrote: > On Fri, Sep 19, 2014 at 12:30:50PM +0200, Daniel Izquierdo wrote: > > Hi! > > > > After having a more in depth review of data coming from Gerrit, some other > > issues appear when using the SSH Gerrit API. > > > > Some of the dates wh

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

On Fri, Sep 19, 2014 at 4:33 AM, Thierry Carrez wrote: > Vishvananda Ishaya wrote: > > Great writeup. I think there are some great concrete suggestions here. > > > > A couple more: > > > > 1. I think we need a better name for Layer #1 that actually represents > what the goal of it is: Infrastruct

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

Excerpts from Eoghan Glynn's message of 2014-09-19 04:23:55 -0700: > > > Hi All, > > > > My understanding of Zaqar is that it's like SQS. SQS uses distributed > > queues, > > which have a few unusual properties [0]: > > Message Order > > > > > > Amazon SQS makes a best effort to preserve order

[openstack-dev] [nova] 2 weeks in the bug tracker

I've spent the better part of the last 2 weeks in the Nova bug tracker to try to turn it into something that doesn't cause people to run away screaming. I don't remember exactly where we started at open bug count 2 weeks ago (it was north of 1400, with > 200 bugs in new, but it might have been nort

[openstack-dev] [neutron] vxlan port iptables configuration

Hi I just was playing around with various neutron-openvswitch-agent vxlan configurations. The default port for vxlan traffic is 4789. I had expected that when the neutron-openvswitch-agent reads the configured vxlan port (or gets the default) it also would add an iptables rule to allow incoming tra

Re: [openstack-dev] [oslo] zeromq work for kilo

On Thu, 18 Sep 2014 17:29:27 Eric Windisch wrote: >> >> >> That?s great feedback, Eric, thank you. I know some of the other projects +1 - yes, excellent feedback - having just worked on the AMQP 1.0 driver, I think you've nicely described some of my own experiences. >> are moving drivers out of t

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

Le 19/09/2014 15:13, Sean Dague a écrit : I've spent the better part of the last 2 weeks in the Nova bug tracker to try to turn it into something that doesn't cause people to run away screaming. I don't remember exactly where we started at open bug count 2 weeks ago (it was north of 1400, with >

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On 2014-09-18 14:35:10 + (+), Ian Cordasco wrote: > Except that even OpenStack doesn’t pin requests because of how > extraordinarily stable our API is. [...] FWIW, I nearly capped it a few weeks ago with https://review.openstack.org/117848 but since the affected projects were able to rush

[openstack-dev] [Neutron] Enabling vlan trunking on neutron port.

Hi All, I have a setup which has VM on flat provider network , and I want to reach VM on VLAN provider network. The packets are forwarded till veth pair and are getting dropped by br-int. Can neutron port be configured to allow vlan trunking? Thanks, Parikshit Manur ___

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

On 2014-09-18 15:21:20 -0400 (-0400), Jay Dobies wrote: > How many of the reviews that we WIP-1 will actually be revisited? > > I'm sure there will be cases where a current developer forgetting > they had started on something, seeing the e-mail about the WIP-1, > and then abandoning the change. >

Re: [openstack-dev] [oslo] zeromq work for kilo

On Mon Sep 8 15:18:35 UTC 2014, Doug Hellmann wrote: >On Sep 8, 2014, at 10:35 AM, Antonio Messina >wrote: > >> Hi All, >> >> We tested briefly ZeroMQ with Havana last year, but we couldn't find >> any good documentation on how to implement it, and we were not able to >> get it working. We also g

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

On 09/19/2014 08:53 AM, Flavio Percoco wrote: On 09/18/2014 09:25 PM, Gordon Sim wrote: I don't see that the claim mechanism brings any stronger guarantee, it just offers a competing consumer behaviour where browsing is non-competing (non-destructive). In both cases you require the client to be

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

On Fri, Sep 19, 2014 at 09:13:29AM -0400, Sean Dague wrote: > I've spent the better part of the last 2 weeks in the Nova bug tracker > to try to turn it into something that doesn't cause people to run away > screaming. I don't remember exactly where we started at open bug count 2 > weeks ago (it wa

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

On 09/19/2014 09:58 AM, Sylvain Bauza wrote: >> == Keeping New Bugs at close to 0 == >> >> After driving the bugs in the New state down to zero last week, I found >> it's actually pretty easy to keep it at 0. >> >> We get 10 - 20 new bugs a day in Nova (during a weekday). Of those ~20% >> aren't a

[openstack-dev] [requirements] [nova] requirements freeze exception for websockify

I'd like to request a requirements freeze exception for websockify - https://review.openstack.org/#/c/122702/ The rationale for this is that websockify version bump fixes a Nova bug about zombie processes - https://bugs.launchpad.net/nova/+bug/1048703. It also sets g-r to the value we've been test

[openstack-dev] [TripleO] Set WIP for stale patches?

> Thu Sep 18 12:18:49 UTC 2014 >> On 2014-09-18 08:06:11 + (+), Sullivan, Jon Paul wrote: >> In my experience if the check results are not fresh enough the >> recheck is automatically run. I am not on the infra team, so >> without looking up code I am just guessing, but my guess is that >>

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On 9/19/14, 9:01 AM, "Jeremy Stanley" wrote: >On 2014-09-18 14:35:10 + (+), Ian Cordasco wrote: >> Except that even OpenStack doesn’t pin requests because of how >> extraordinarily stable our API is. >[...] > >FWIW, I nearly capped it a few weeks ago with >https://review.openstack.org/1

Re: [openstack-dev] [oslo] zeromq work for kilo

On 09/19/2014 08:38 AM, Ken Giusti wrote: > On Thu, 18 Sep 2014 17:29:27 Eric Windisch wrote: >>> >>> >>> That?s great feedback, Eric, thank you. I know some of the other projects > > +1 - yes, excellent feedback - having just worked on the AMQP 1.0 > driver, I think you've nicely described some o

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

I don't think anyone would be complaining if glanceclient didn't have the need to reach into and monkeypatch requests's connection pool manager[1]. Is there a way to tell requests to build the https connections differently without monkeypatching urllib3.poolmanager? glanceclient's monkeypatching o

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

> On Sep 19, 2014, at 11:54 AM, Brant Knudson wrote: > > > I don't think anyone would be complaining if glanceclient didn't have the > need to reach into and monkeypatch requests's connection pool manager[1]. Is > there a way to tell requests to build the https connections differently > with

Re: [openstack-dev] [oslo] zeromq work for kilo

Hi, For me, the lack of tests is why reviews are not done, even some of them are critical. An other issue, less problematic, of this driver is it relies on eventlet directly, but all the eventlet code should be only localized into oslo.messaging._executor.impl_eventlet. Otherwise, I have

Re: [openstack-dev] [Heat] naming of provider template for docs

On further thought, I noticed that "template-based resource" also describes an AWS::CloudFormation::Stack; and since those are template-based, you could well describe them as "custom" too. Would you consider "nested stack" to also describe resources of other types that are implemented by Python

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

On 2014-09-19 15:27:36 + (+), Sullivan, Jon Paul wrote: [...] > I think that the abandoning happening from an automated process is > easier to accept than if it came from a person, and so less likely > to create a poor and emotional response. Here we'll just have to agree to disagree. I th

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On Fri, Sep 19, 2014 at 8:59 AM, Donald Stufft wrote: > > On Sep 19, 2014, at 11:54 AM, Brant Knudson wrote: > > > I don't think anyone would be complaining if glanceclient didn't have the > need to reach into and monkeypatch requests's connection pool manager[1]. > Is there a way to tell reques

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

> On Sep 19, 2014, at 12:42 PM, Mark Washenberger > wrote: > > > > On Fri, Sep 19, 2014 at 8:59 AM, Donald Stufft > wrote: > >> On Sep 19, 2014, at 11:54 AM, Brant Knudson > > wrote: >> >> >> I don't think anyone would be complaining if glance

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

Can someone do a small little Visio or other visual to explain what's being proposed here? My head sported a small crack at around the 5-6th page... ; ) But seriously, I couldn't understand the proposal. Maybe I'm not the audience which is fine, just saying, the words got in the way. Sounds like a

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

On Sep 19, 2014, at 5:46 AM, John Griffith wrote: > > > On Fri, Sep 19, 2014 at 4:33 AM, Thierry Carrez wrote: > Vishvananda Ishaya wrote: > > Great writeup. I think there are some great concrete suggestions here. > > > > A couple more: > > > > 1. I think we need a better name for Layer #1 th

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

On Sep 19, 2014, at 3:33 AM, Thierry Carrez wrote: > Vishvananda Ishaya wrote: >> Great writeup. I think there are some great concrete suggestions here. >> >> A couple more: >> >> 1. I think we need a better name for Layer #1 that actually represents what >> the goal of it is: Infrastructure

[openstack-dev] WARNING: Oslo team is cleaning up the incubator

The Oslo team is starting to remove deprecated code from the incubator for libraries that graduated this cycle, in preparation for the work we will be doing in Kilo. Any fixes for those modules needed before the final releases for the other projects should be submitted to the stable/juno branch

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

On Fri, Sep 19, 2014 at 12:02 PM, Adam Lawson wrote: > Can someone do a small little Visio or other visual to explain what's > being > Sean's blog post included a nice diagram that is Monty's starting point: https://dague.net/2014/08/26/openstack-as-layers/ AIUI Monty's Layer 1 is basically the

Re: [openstack-dev] [oslo] zeromq work for kilo

On Sep 19, 2014, at 10:34 AM, Ken Giusti wrote: > On Mon Sep 8 15:18:35 UTC 2014, Doug Hellmann wrote: >> On Sep 8, 2014, at 10:35 AM, Antonio Messina > gmail.com> wrote: >> >>> Hi All, >>> >>> We tested briefly ZeroMQ with Havana last year, but we couldn't find >>> any good documentation on h

Re: [openstack-dev] [oslo-vmware] Propose adding Radoslav to core team

Done. Welcome to the team, Radoslav! Doug On Sep 19, 2014, at 7:52 AM, Vipin Balachandran wrote: > +1 > > From: Vui Chiap Lam [mailto:[email protected]] > Sent: Tuesday, September 16, 2014 10:52 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [opensta

Re: [openstack-dev] [Keystone][Oslo] Federation and Policy

On Sep 19, 2014, at 6:56 AM, David Chadwick wrote: > > > On 18/09/2014 22:14, Doug Hellmann wrote: >> >> On Sep 18, 2014, at 4:34 PM, David Chadwick >> wrote: >> >>> >>> >>> On 18/09/2014 21:04, Doug Hellmann wrote: On Sep 18, 2014, at 12:36 PM, David Chadwick wrote: >>>

Re: [openstack-dev] [Neutron] [LBaaS] Packet flow between instances using a load balancer

If we're talking about default haproxy driver for lbaas, then I'd say that the diagram is not quite correct because one could assume that LB_A and LB_B are kind of routing devices which have networks behind. Since haproxy is layer 4 loadbalancer, so packet received by RHB1 will have source of LB_B

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

Sorry for top-posting. Just want to say thanks for writing this up and I agree with all the points and recommendations you made. -jay On 09/19/2014 09:13 AM, Sean Dague wrote: I've spent the better part of the last 2 weeks in the Nova bug tracker to try to turn it into something that doesn't c

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

On Sep 19, 2014, at 10:14 AM, John Dickinson wrote: > > On Sep 19, 2014, at 5:46 AM, John Griffith > wrote: > >> >> >> On Fri, Sep 19, 2014 at 4:33 AM, Thierry Carrez >> wrote: >> Vishvananda Ishaya wrote: >>> Great writeup. I think there are some great concrete suggestions here. >>> >>

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

On 09/19/2014 01:15 PM, Vishvananda Ishaya wrote: > > On Sep 19, 2014, at 3:33 AM, Thierry Carrez > wrote: > >> Vishvananda Ishaya wrote: >>> Great writeup. I think there are some great concrete >>> suggestions here. >>> >>> A couple more: >>> >>> 1. I think we need a better name for Layer #1

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

On Fri, Sep 19, 2014 at 4:23 AM, Eoghan Glynn wrote: > > > > Hi All, > > > > My understanding of Zaqar is that it's like SQS. SQS uses distributed > queues, > > which have a few unusual properties [0]: > > Message Order > > > > > > Amazon SQS makes a best effort to preserve order in messages, but

Re: [openstack-dev] [requirements] [nova] requirements freeze exception for websockify

On Sep 19, 2014, at 11:22 AM, Sean Dague wrote: > I'd like to request a requirements freeze exception for websockify - > https://review.openstack.org/#/c/122702/ > > The rationale for this is that websockify version bump fixes a Nova bug > about zombie processes - https://bugs.launchpad.net/nova

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On Fri, Sep 19, 2014 at 6:58 PM, Donald Stufft wrote: > So you can remove all that code and just let requests/urllib3 handle it on > 3.2+, 2.7.9+ and for anything less than that either use conditional > dependencies to have glance client depend on pyOpenSSL, ndg-httpsclient, > and pyasn1 on Pytho

Re: [openstack-dev] [Heat][Zaqar] Integration plan moving forward

Excerpts from Flavio Percoco's message of 2014-09-18 02:07:09 -0700: > Greetings, > > If I recall correctly, Heat was planning to adopt Zaqar regardless of > the result of the graduation attempt (please correct me if I'm wrong). > Based on this assumption, I'd like to start working on a plan forwa

Re: [openstack-dev] [Heat][Zaqar] Integration plan moving forward

Excerpts from Flavio Percoco's message of 2014-09-19 02:37:08 -0700: > On 09/18/2014 11:51 AM, Angus Salkeld wrote: > > > > On 18/09/2014 7:11 PM, "Flavio Percoco" > > wrote: > >> > >> Greetings, > >> > >> If I recall correctly, Heat was planning to adopt Zaqar regardles

Re: [openstack-dev] [metrics] New version of the Activity Board

Thank you Daniel, great job. On 09/17/2014 09:03 AM, Daniel Izquierdo wrote: > * Further work > = > - Add Juno release information It's coming :) > - Allow to have projects navigation per release This is interesting > - Add Askbot data per release This is really not needed, don't spen

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

> On Sep 19, 2014, at 2:26 PM, Chmouel Boudjnah wrote: > > > On Fri, Sep 19, 2014 at 6:58 PM, Donald Stufft > wrote: > So you can remove all that code and just let requests/urllib3 handle it on > 3.2+, 2.7.9+ and for anything less than that either use conditional > d

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

Excerpts from Ian Cordasco's message of 2014-09-18 10:33:04 -0700: > > On 9/18/14, 11:29 AM, "Clint Byrum" wrote: > > >Excerpts from Donald Stufft's message of 2014-09-18 07:30:27 -0700: > >> > >> > On Sep 18, 2014, at 10:18 AM, Clint Byrum wrote: > >> > > >> > Excerpts from Donald Stufft's m

[openstack-dev] [Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

Nominations for OpenStack PTLs (Program Technical Leads) are now open and will remain open until September 26, 2014 05:59 UTC. To announce your candidacy please start a new openstack-dev at lists.openstack.org mailing list thread with the program name as a tag, example [Glance] PTL Candidacy with

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On Fri, Sep 19, 2014 at 11:26 AM, Chmouel Boudjnah wrote: > > On Fri, Sep 19, 2014 at 6:58 PM, Donald Stufft wrote: > >> So you can remove all that code and just let requests/urllib3 handle it >> on 3.2+, 2.7.9+ and for anything less than that either use conditional >> dependencies to have glanc

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

On 2014-09-18 15:21:20 -0400 (-0400), Jay Dobies wrote: How many of the reviews that we WIP-1 will actually be revisited? I'm sure there will be cases where a current developer forgetting they had started on something, seeing the e-mail about the WIP-1, and then abandoning the change. But what

[openstack-dev] [Compute][Nova] Announcing my candidacy for PTL

I'd like another term as Compute PTL, if you'll have me. We live in interesting times. OpenStack has clearly gained a large amount of mind share in the open cloud marketplace, with Nova being a very commonly deployed component. Yet, we don't have a fantastic container solution, which is our bigges

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

On 18/09/14 10:55, Flavio Percoco wrote: On 09/18/2014 04:24 PM, Clint Byrum wrote: Great job highlighting what our friends over at Amazon are doing. It's clear from these snippets, and a few other pieces of documentation for SQS I've read, that the Amazon team approached SQS from a _massive_ s

[openstack-dev] [neutron] Announcing my candidacy for PTL

All: I am writing to announce my candidacy for the OpenStack Networking (Neutron) PTL role. I am the current Neutron PTL, having lead the project during the Juno cycle. As a team, we have accomplished a lot during the Juno cycle. We have achieved the goals outlined from the TC around nova-network

Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota

I'm in HP, but not in the group that owns this effort, so I don't know what its status is. There is a havana-based implementation floating around somewhere inside HP. I'll ask around to see what I can find out. I'm pretty sure there's nothing going on in the community. Chuck On Sep 19, 2014,

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

On Fri, Sep 19, 2014 at 11:13 PM, Sean Dague wrote: > I've spent the better part of the last 2 weeks in the Nova bug tracker > to try to turn it into something that doesn't cause people to run away > screaming. I don't remember exactly where we started at open bug count 2 > weeks ago (it was north

Re: [openstack-dev] Oslo final releases ready

Thanks. That's now approved and we're waiting for the merge. Michael On Fri, Sep 19, 2014 at 7:30 PM, Andrey Kurilin wrote: > Here you are!:) > https://review.openstack.org/#/c/122667 > > On Fri, Sep 19, 2014 at 9:02 AM, Michael Still wrote: >> >> I would like to do a python-novaclient release,

Re: [openstack-dev] [Compute][Nova] Announcing my candidacy for PTL

confirmed On 09/19/2014 04:12 PM, Michael Still wrote: > I'd like another term as Compute PTL, if you'll have me. > > We live in interesting times. OpenStack has clearly gained a large > amount of mind share in the open cloud marketplace, with Nova being a > very commonly deployed component. Yet,

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

On 09/19/2014 08:13 AM, Sean Dague wrote: > I've spent the better part of the last 2 weeks in the Nova bug tracker > to try to turn it into something that doesn't cause people to run away > screaming. I don't remember exactly where we started at open bug count 2 > weeks ago (it was north of 1400, w

Re: [openstack-dev] [neutron] Announcing my candidacy for PTL

confirmed On 09/19/2014 04:40 PM, Kyle Mestery wrote: > All: > > I am writing to announce my candidacy for the OpenStack Networking > (Neutron) PTL role. > > I am the current Neutron PTL, having lead the project during the Juno > cycle. As a team, we have accomplished a lot during the Juno cycle

[openstack-dev] [Keystone] PTL Candidacy

Hello Everyone!  After contributing consistently to OpenStack since the Grizzly cycle and more specifically to Keystone since Havana, I’d like to put my name into the hat for the Keystone PTL role during the Kilo release cycle. I’ve been a core developer on Keystone since the latter part of the

Re: [openstack-dev] [Keystone] PTL Candidacy

confirmed On 09/19/2014 05:14 PM, Morgan Fainberg wrote: > Hello Everyone! > > After contributing consistently to OpenStack since the Grizzly cycle and more > specifically to Keystone since Havana, I’d like to put my name into the hat > for the Keystone PTL role during the Kilo release cycle.

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

On 09/19/2014 05:03 PM, Ben Nemec wrote: > On 09/19/2014 08:13 AM, Sean Dague wrote: >> I've spent the better part of the last 2 weeks in the Nova bug tracker >> to try to turn it into something that doesn't cause people to run away >> screaming. I don't remember exactly where we started at open bu

Re: [openstack-dev] [Heat][Zaqar] Integration plan moving forward

On 19/09/14 14:34, Clint Byrum wrote: Excerpts from Flavio Percoco's message of 2014-09-19 02:37:08 -0700: On 09/18/2014 11:51 AM, Angus Salkeld wrote: On 18/09/2014 7:11 PM, "Flavio Percoco" mailto:[email protected]>> wrote: Greetings, If I recall correctly, Heat was planning to adopt Zaqa

Re: [openstack-dev] [Heat] Request for python-heatclient project to adopt heat-translator

On 09/09/14 05:52, Steven Hardy wrote: Hi Sahdev, On Tue, Sep 02, 2014 at 11:52:30AM -0400, Sahdev P Zala wrote: Hello guys, As you know, the heat-translator project was started early this year with an aim to create a tool to translate non-Heat templates to HOT. It is a StackFo

Re: [openstack-dev] [Heat] naming of provider template for docs

On 19/09/14 01:10, Mike Spreitzer wrote: Angus Salkeld wrote on 09/18/2014 09:33:56 PM: Hi I am trying to add some docs to openstack-manuals hot_guide about using provider templates : https://review.openstack.org/#/c/121741/ Mike has suggested we use a different term, he thinks "provider

Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota

Well there is the QoS work that has been pushed to incubation or Kilo. On Fri, Sep 19, 2014 at 1:40 PM, Carlino, Chuck wrote: > I'm in HP, but not in the group that owns this effort, so I don't know what > its status is. There is a havana-based implementation floating around > somewhere inside

Re: [openstack-dev] [Neutron][QoS] Applying QoS as Quota

Sorry, forgot to include a link. https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api On Fri, Sep 19, 2014 at 4:45 PM, Kevin Benton wrote: > Well there is the QoS work that has been pushed to incubation or Kilo. > > On Fri, Sep 19, 2014 at 1:40 PM, Carlino, Chuck wrote: >> I'm in HP, b

Re: [openstack-dev] [neutron] vxlan port iptables configuration

This is the responsibility of the deployment tool. The iptables firewall driver only handles firewall rules for the VM ports. On Fri, Sep 19, 2014 at 6:28 AM, Andreas Scheuring wrote: > Hi > I just was playing around with various neutron-openvswitch-agent vxlan > configurations. The default port

Re: [openstack-dev] [Heat] naming of provider template for docs

On Fri, Sep 19, 2014 at 11:20:43AM +0200, Thomas Spatzier wrote: > > From: Mike Spreitzer > > To: "OpenStack Development Mailing List \(not for usage questions\)" > > > > Date: 19/09/2014 07:15 > > Subject: Re: [openstack-dev] [Heat] naming of provider template for docs > > > > Angus Salkeld wro

[openstack-dev] usability anti-pattern

Hey, Not to name names, but some of our client libs do this: client.Client(API_VERSION, os_username, ... ) I'm pretty sure they got the idea from python-glanceclient, so I blame Brian Waldon, since he left us for CoreOS. PLEASE STOP DOING THIS - IT CAUSES BABIES TO CRY. MORE. As a developer,

[openstack-dev] usability anti-pattern, part 2

except exc.Unauthorized: raise exc.CommandError("Invalid OpenStack credentials.") except exc.AuthorizationFailure: raise exc.CommandError("Unable to authorize user") This is pervasive enough that both of those exceptions come from openstack.common. Anyone?

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

On 09/19/2014 03:29 AM, Thierry Carrez wrote: > Monty Taylor wrote: >> I've recently been thinking a lot about Sean's Layers stuff. So I wrote >> a blog post which Jim Blair and Devananda were kind enough to help me edit. >> >> http://inaugust.com/post/108 > > Hey Monty, > > As you can imagine, I

  1   2   >