Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

On Tue, 2014-09-16 at 15:42 -0400, Zane Bitter wrote: > On 16/09/14 15:24, Devananda van der Veen wrote: > > On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter wrote: > >> On 16/09/14 13:56, Devananda van der Veen wrote: > >>> > >>> On Mon, Sep 15, 2014 at 9:00 AM, Steven Hardy wrote: > > Fo

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

You're quite probably correct - going through the OWASP threat list in more detail is on my TODO. That was just off the top of my head as something that has me concerned but I've not investigated it thoroughly. On 17 September 2014 14:15, Adam Young wrote: > On 09/16/2014 08:56 PM, Richard Jone

[openstack-dev] [sahara] weekly team meeting Sept 18 1800 UTC

Hi folks, We'll be having the Sahara team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20140918T18

Re: [openstack-dev] [sahara] weekly team meeting Sept 18 1800 UTC

correct time link is: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20140918T18 On Wednesday, September 17, 2014, Sergey Lukjanov wrote: > Hi folks, > > We'll be having the Sahara team meeting as usual in > #openstack-meeting-alt channel. > > Agenda: > https://wiki

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

Hi, as part of general housekeeping on our reviews, it was discussed at last week's meeting [1] that we should set workflow -1 for stale reviews (like gerrit used to do when I were a lad). The specific criteria discussed was 'items that have a -1 from a core but no response from author for 14 day

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

On Tue, Sep 16, 2014 at 02:06:59PM -0700, Devananda van der Veen wrote: > On Tue, Sep 16, 2014 at 12:42 PM, Zane Bitter wrote: > > On 16/09/14 15:24, Devananda van der Veen wrote: > >> > >> On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitter wrote: > >>> > >>> On 16/09/14 13:56, Devananda van der Veen

[openstack-dev] [neutron] Creating resources for non-existent tenants

Hi, all! I have been looking at the bug https://bugs.launchpad.net/neutron/+bug/1338885 and it turned out that it is relevant not only for firewall rules but for all resources that take tenant-is for create and update. I need a piece of advice on a preferable way of solving the problem. First of

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

> 1. Not everyone will have an enterprise CMDB, so there should be some way > to input inventory without one (even if it is a text file fed into > ironicclient). The bulk-loading format to do this is TBD. > > 2. A way to generate that inventory in an automated way is desirable for > some folks, but

Re: [openstack-dev] [tripleo][heat][ironic] Heat Ironic resources and "ready state" orchestration

On Wed, 2014-09-17 at 10:36 +0100, Steven Hardy wrote: > On Tue, Sep 16, 2014 at 02:06:59PM -0700, Devananda van der Veen wrote: > > On Tue, Sep 16, 2014 at 12:42 PM, Zane Bitter wrote: > > > On 16/09/14 15:24, Devananda van der Veen wrote: > > >> > > >> On Tue, Sep 16, 2014 at 11:44 AM, Zane Bitt

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

Thanks for the feedback! I need to look closer to Cinder Agent specs. Walter, Hope, I could help you and Duncan with making this. Regards, Ivan Kolodyazhny On Wed, Sep 17, 2014 at 2:32 AM, Mathieu Gagné wrote: > On 2014-09-16 7:03 PM, Walter A. Boring IV wrote: > > The upside to brick not ma

Re: [openstack-dev] Feature freeze + Juno-3 milestone candidates available

A bit late reply. As one of translators, I can say wrong strings are worse. "String Freeze" is a soft freeze and it just declares we don't make big change mainly due to feature additions. It does not necessarily prevent fixes including string changes. In Horizon case, after starting translations

[openstack-dev] [heat] Convergence - persistence desired and observed state

Hi All, The convergence blueprint (https://review.openstack.org/#/c/95907/) introduces two new database tables (resource_observed and resource_properties_observed ) for storing the observed state of a resource (currently under review: https://review.openstack.org/#/c/109012/). However, it can

[openstack-dev] [MagentoDB] Tomorrow IRC meeting

Hello stackers, MagnetoDB team is having IRC meeting tomorrow 13:00 UTC The agenda can be found here[1] Feel free to join and add items to agenda [1] https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda Have a nice day, Ilya Sviridov isviridov @ FreeNode __

[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 rarely the case for the very

Re: [openstack-dev] [heat] Convergence - persistence desired and observed state

On Wed, Sep 17, 2014 at 12:27:34PM +, Gurjar, Unmesh wrote: > Hi All, > > The convergence blueprint (https://review.openstack.org/#/c/95907/) > introduces two new database tables (resource_observed and > resource_properties_observed ) for storing the observed state of a resource > (currentl

[openstack-dev] [all][TC][Zaqar] Another graduation attempt, new lessons learned

Greetings, As probably many of you already know, Zaqar (formerly known as Marconi) has recently been evaluated for integration. This is the second time this project (and team) has gone through this process and just like last time, it wasn't as smooth as we all would have liked it to be. I thought

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

Hi Adam Kristy has already added support to Horizon for federated login to Keystone. She will send you details of how she did this. One issue that arose was this: in order to give the user the list of IDPs/protocols that are trusted, the call to Keystone needs to be authenticated. But the user is

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

- Original Message - > Hi, > > as part of general housekeeping on our reviews, it was discussed at last > week's meeting [1] that we should set workflow -1 for stale reviews > (like gerrit used to do when I were a lad). > > The specific criteria discussed was 'items that have a -1 from

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. - Steve David Chadwick wrote on 09/17/2014 09:37:21 AM: > From: David Chadwick > To: [email protected], Kristy Siu , > Date: 09/17/2014 09:42 AM > Subject: Re: [openstack-dev]

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

On 17/09/14 14:40, Charles Crouch wrote: > > > - Original Message - >> Hi, >> >> as part of general housekeeping on our reviews, it was discussed at last >> week's meeting [1] that we should set workflow -1 for stale reviews >> (like gerrit used to do when I were a lad). >> >> The specifi

Re: [openstack-dev] [tripleo] Adding hp1 back running tripleo CI

On 15/09/14 22:37, Gregory Haynes wrote: > This is a total shot in the dark, but a couple of us ran into issues > with the Ubuntu Trusty kernel (I know I hit it on HP hardware) that was > causing severely degraded performance for TripleO. This fixed with a > recently released kernel in Trusty... ma

[openstack-dev] [QA] Meeting Thursday September 18th at 22:00 UTC

Hi everyone, Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, September 18th at 22:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome

[openstack-dev] [heat] Confused about the future of health maintenance and OS::Heat::HARestarter

Background: Health maintenance is very important to users, and I have users who want to do it now and into the future. Today a Heat user can write a template that maintains the health of a resource R. The detection of a health problem can be done by anything that hits a webhook. That general

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. I think this might be useful in an academic/science world but on the other hand most cloud providers from the 'business' world might be very relu

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

On 17/09/2014 14:55, Marek Denis wrote: > > > On 17.09.2014 15:45, Steve Martinelli wrote: >> ++ to your suggestion David, I think making the list of trusted IdPs >> publicly available makes sense. > > I think this might be useful in an academic/science world but on the > other hand most cloud

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

Has Kristy's patch made it into Juno ? Tim > -Original Message- > From: David Chadwick [mailto:[email protected]] > Sent: 17 September 2014 15:37 > To: [email protected]; Kristy Siu > Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation > > Hi Adam

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

On 09/17/2014 10:07 AM, David Chadwick wrote: On 17/09/2014 14:55, Marek Denis wrote: On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. I think this might be useful in an academic/science world bu

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

I had the same thought :) Config option or some documentation that outlines changes in policy.json. Either way, we should support both. David Chadwick wrote on 09/17/2014 10:07:43 AM: > From: David Chadwick > To: [email protected], > Date: 09/17/2014 10:10 AM > Subject: Re: [o

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

this would work as well, but wouldn't it require two different API calls? On 17/09/2014 15:17, Adam Young wrote: > On 09/17/2014 10:07 AM, David Chadwick wrote: >> >> On 17/09/2014 14:55, Marek Denis wrote: >>> >>> On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I th

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

This thread [1] has turned more “future focused", so I’m moving the conversation to the -dev list where we usually have those sorts of discussions. [1] http://lists.openstack.org/pipermail/openstack/2014-September/009253.html On Sep 17, 2014, at 7:54 AM, James Page wrote: > Signed PGP part > H

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

Hi Tim I don't believe she has pushed this through the official channel yet as we were very pushed for time to get something working for our GIANT CLASSe project. We only did the work in the latter half of August. I also don't know if we are too late for Juno or not. regards David On 17/09/201

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

On 09/17/2014 10:14 AM, Tim Bell wrote: Has Kristy's patch made it into Juno ? I don't see any patches from Kristy in either the merged or pending review state for non-keystone projects; https://review.openstack.org/#/q/owner:%22Kristy+Siu%22,n,z So I'm guessing it is proof-of-concept code th

[openstack-dev] [TripleO] Release Report

1. os-apply-config: release: 0.1.21 --> 0.1.22 --> https://pypi.python.org/pypi/os-apply-config/0.1.22 --> http://tarballs.openstack.org/os-apply-config/os-apply-config-0.1.22.tar.gz 2. os-refresh-config: no changes, 0.1.7 3. os-collect-config: no changes, 0.1.28 4. o

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

This has come up a couple of times in IRC now but the people that probably know the answer aren't available. There are python-novaclient patches that are adding new CLIs to the v2 (v1_1) and v3 shells, but now that we have the v2.1 API (v2 on v3) why do we still have a v3 shell in the client?

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

On 09/17/2014 10:35 AM, David Chadwick wrote: this would work as well, but wouldn't it require two different API calls? I think it would be 2 calls no matter what. OK, lets talk this through: 1. Configure Horizon to return a generic login page, with a button that says "Or do Federated" 2.

Re: [openstack-dev] [Nova] What's holding nova development back?

On 9/16/2014 1:01 PM, Joe Gordon wrote: On Sep 15, 2014 8:31 PM, "Jay Pipes" mailto:[email protected]>> wrote: > > On 09/15/2014 08:07 PM, Jeremy Stanley wrote: >> >> On 2014-09-15 17:59:10 -0400 (-0400), Jay Pipes wrote: >> [...] >>> >>> Sometimes it's pretty hard to determine whether

Re: [openstack-dev] [release] client release deadline - Sept 18th

On 9/15/2014 12:57 PM, Matt Riedemann wrote: On 9/10/2014 11:08 AM, Kyle Mestery wrote: On Wed, Sep 10, 2014 at 10:01 AM, Matt Riedemann wrote: On 9/9/2014 4:19 PM, Sean Dague wrote: As we try to stabilize OpenStack Juno, many server projects need to get out final client releases that

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

Hi, I'm horrified by what I just found. I have just found out this in glanceclient: File "/tests/test_ssl.py", line 19, in from requests.packages.urllib3 import poolmanager ImportError: No module named packages.urllib3 Please *DO NOT* do this. Instead, please use urllib3 from ... urllib3.

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

I don't know the specific situation but it's appropriate to do this if you're using requests and wish to interact with the urllib3 that requests is using. > On Sep 17, 2014, at 11:15 AM, Thomas Goirand wrote: > > Hi, > > I'm horrified by what I just found. I have just found out this in > glanc

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

Looking at the code on my phone it looks completely correct to use the vendored copy here and it wouldn't actually work otherwise. > On Sep 17, 2014, at 11:17 AM, Donald Stufft wrote: > > I don't know the specific situation but it's appropriate to do this if you're > using requests and wish t

Re: [openstack-dev] [all][TC][Zaqar] Another graduation attempt, new lessons learned

Thanks for bring this to the list, Flavio. A few thoughts in line ... > Greetings, > > As probably many of you already know, Zaqar (formerly known as Marconi) > has recently been evaluated for integration. This is the second time > this project (and team) has gone through this process and just

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

On 17/09/2014 15:38, Adam Young wrote: > On 09/17/2014 10:14 AM, Tim Bell wrote: >> Has Kristy's patch made it into Juno ? > I don't see any patches from Kristy in either the merged or pending > review state for non-keystone projects; > > https://review.openstack.org/#/q/owner:%22Kristy+Siu%22,n

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

> -Original Message- > From: Derek Higgins [mailto:[email protected]] > Sent: 17 September 2014 14:49 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [TripleO] Set WIP for stale patches? > > On 17/09/14 14:40, Charles Crouch wrote: > > > >

[openstack-dev] reopen a change / pull request for nova-pythonclient ?

hi, how does one re-open a abandoned change / pull request ? it just "timed out" and was then abandoned - https://review.openstack.org/#/c/57834/ please let me know thanks! alex ___ OpenStack-dev mailing list [email protected] http://l

Re: [openstack-dev] [all] [clients] [keystone] lack of retrying tokens leads to overall OpenStack fragility

On 16 September 2014 01:28, Nathan Kinder wrote: > The idea would be to leave normal tokens with a smaller validity period > (like the current default of an hour), but also allow one-time use > tokens to be requested. Cinder backup makes many requests to swift during a backup, one per chunk to be

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

Hi, First of all, we should clarify whether your JS client wants to implement ECP or WebSSO workflow. They are slightly different. I feel JS is smart enough to implement the ECP flow and then and it could simply implement what we already have in the keystoneclient [0]. This + some "discovery

Re: [openstack-dev] reopen a change / pull request for nova-pythonclient ?

On 09/17/2014 11:47 AM, Alex Leonhardt wrote: > hi, > > how does one re-open a abandoned change / pull request ? it just "timed > out" and was then abandoned - > > https://review.openstack.org/#/c/57834/ > > please let me know I re-opened it. You should be able to update it now. -- Russell

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

Hi, - Original Message - > From: "Adam Young" > To: [email protected] > Sent: Wednesday, September 17, 2014 5:00:16 PM > Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation > > On 09/17/2014 10:35 AM, David Chadwick wrote: > > > > this would work as we

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

Hi all, The code for my proof of concept software is at https://github.com/kwss/horizon/tree/federated (templates) And https://github.com/kwss/django_openstack_auth/tree/federated (federation handling). Please note that the horizon branch also contains some additional panels for managing Id

Re: [openstack-dev] reopen a change / pull request for nova-pythonclient ?

On Wed, Sep 17, 2014 at 04:47:06PM +0100, Alex Leonhardt wrote: > hi, > > how does one re-open a abandoned change / pull request ? it just "timed > out" and was then abandoned - > > https://review.openstack.org/#/c/57834/ > > please let me know Just re-upload the change, maintaining the same Ch

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

Hi everyone, I'd like to introduce the new activity board look and feel and other improvements in the metrics side. * What is it? Activity board is the place where you can find development metrics of the OpenStack Foundation projects. * Where to get it? === There is a l

Re: [openstack-dev] reopen a change / pull request for nova-pythonclient ?

On 09/17/2014 11:56 AM, Daniel P. Berrange wrote: > On Wed, Sep 17, 2014 at 04:47:06PM +0100, Alex Leonhardt wrote: >> hi, >> >> how does one re-open a abandoned change / pull request ? it just "timed >> out" and was then abandoned - >> >> https://review.openstack.org/#/c/57834/ >> >> please let me

Re: [openstack-dev] [Keystone][Horizon] CORS and Federation

On 17/09/2014 16:53, Marek Denis wrote: > Hi, > > First of all, we should clarify whether your JS client wants to > implement ECP or WebSSO workflow. They are slightly different. Our modification to Horizon uses WebSSO since this is the obvious profile for a browser to use as it can handle redi

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

On Sep 16, 2014, at 6:02 PM, Flavio Percoco wrote: > On 09/16/2014 11:55 PM, Ben Nemec wrote: >> Based on my reading of the wiki page about this it sounds like it should >> be a sub-project of the Storage program. While it is targeted for use >> by multiple projects, it's pretty specific to int

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

This is where Debian's "one urllib3 to rule them all" model fails in a modern fast paced world. Debian is arguably doing the right thing by pushing everyone to use one API, and one library, so that when that one library is found to be vulnerable to security problems, one update covers everyone. Als

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

I was trying request-ifying oslo.vmware and ran into this as well: https://review.openstack.org/#/c/121956/ And we don't seem to have urllib3 in global-requirements either. Should we do that first? -- dims On Wed, Sep 17, 2014 at 1:05 PM, Clint Byrum wrote: > This is where Debian's "one urllib3

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

+1 to Doug's comments. On Wed, Sep 17, 2014 at 1:02 PM, Doug Hellmann wrote: > > On Sep 16, 2014, at 6:02 PM, Flavio Percoco wrote: > >> On 09/16/2014 11:55 PM, Ben Nemec wrote: >>> Based on my reading of the wiki page about this it sounds like it should >>> be a sub-project of the Storage progr

[openstack-dev] [Mistral] callback on workflow completion

Use case: The client software fires the workflow execution and needs to be know when the workflow is complete. There is no good pool strategy as workflow can take arbitrary time from ms to days. Callback notification is needed. Solution is a webhook Option 1: pass callback URL as part of star

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

On 09/17/2014 09:03 AM, Jastrzebski, Michal wrote: > 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 ac

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

I think in the hopefully not too distant future we'll be able to make the v1_1 client handle both V2 and V2.1 (who knows. Maybe we can even rename it v2) - and that's what we should do because it will prove if we have full compatibility or not. Right now the two things holding that back are the

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

> -Original Message- > From: Jay Pipes [mailto:[email protected]] > Sent: 12 September 2014 19:37 > To: [email protected] > Subject: Re: [openstack-dev] [nova] Expand resource name allowed > characters > > Had to laugh about the PILE OF POO character :) Comments inline...

Re: [openstack-dev] [Mistral] callback on workflow completion

Ok, here is what I think... I totally support the first option for its easiness in terms of understanding how it all should work (no need to figure out if some additional objects must be deleted if a workflow has been removed etc. etc.). We actually have two BPS [0] and [1] where the idea was s

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

Excerpts from Davanum Srinivas's message of 2014-09-17 10:15:29 -0700: > I was trying request-ifying oslo.vmware and ran into this as well: > https://review.openstack.org/#/c/121956/ > > And we don't seem to have urllib3 in global-requirements either. > Should we do that first? Honestly, after re

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

Excerpts from Jastrzebski, Michal's message of 2014-09-17 06:03:06 -0700: > 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 > hand

Re: [openstack-dev] [tripleo] Adding hp1 back running tripleo CI

Excerpts from Derek Higgins's message of 2014-09-17 06:53:25 -0700: > On 15/09/14 22:37, Gregory Haynes wrote: > > This is a total shot in the dark, but a couple of us ran into issues > > with the Ubuntu Trusty kernel (I know I hit it on HP hardware) that was > > causing severely degraded performan

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

Thanks a lot for a comments! As discussed in IRC (#openstack-cinder), moving Brick to Oslo or Stackforge isn't the best solution. We're moving on making Cinder Agent (or Cinder Storage agent) [1] based on Brick code instead of making Brick as a separate python library used in Cinder and Nova. I

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

On Sep 17, 2014, at 2:46 PM, Clint Byrum wrote: > Excerpts from Davanum Srinivas's message of 2014-09-17 10:15:29 -0700: >> I was trying request-ifying oslo.vmware and ran into this as well: >> https://review.openstack.org/#/c/121956/ >> >> And we don't seem to have urllib3 in global-requiremen

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

On Tue, Sep 16, 2014 at 8:02 AM, Kurt Griffiths < [email protected]> wrote: > Right, graphing those sorts of variables has always been part of our > test plan. What I’ve done so far was just some pilot tests, and I realize > now that I wasn’t very clear on that point. I wanted to get a

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

VLAN is on the radar, vxlan/gre was done to start with. I believe Vivek mentioned the rationale in some other thread. The gist of it below: In the current architecture, we use a unique DVR MAC per compute node to forward DVR Routed traffic directly to destination compute node. The DVR routed traf

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

On 9/17/14, 1:46 PM, "Clint Byrum" wrote: >Excerpts from Davanum Srinivas's message of 2014-09-17 10:15:29 -0700: >> I was trying request-ifying oslo.vmware and ran into this as well: >> https://review.openstack.org/#/c/121956/ >> >> And we don't seem to have urllib3 in global-requirements eithe

Re: [openstack-dev] [Zaqar] Zaqar graduation (round 2) [was: Comments on the concerns arose during the TC meeting]

On 09/16/2014 08:55 AM, Flavio Percoco wrote: pub/sub doesn't necessarily guarantees messages delivery, it really depends on the implementation. As I understand it, the model for pub-sub in Zaqar is to have multiple subscribers polling the queue with gets, and have the messages removed from t

Re: [openstack-dev] [all] Design Summit planning

This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there was an Ops Meetup track. [1] I do not see where this fits into the current planning process that has been posted. I would like to assume that part of the purpose of the summit is to al

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

Interestingly enough, the distros are doing exactly what they don't want us to do, ie, rebuilding things to use 'their' tested version of dependencies rather than the included one... On Wed, Sep 17, 2014 at 2:42 PM, Ian Cordasco wrote: > > That aside, I’ve been mulling over how effectively the cl

Re: [openstack-dev] [all] Design Summit planning

On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote: > This looks great - but I am afraid that something might be missing. > > As part of the Design summit in Atlanta there was an Ops Meetup track. > [1] I do not see where this fits into the current planning process that > has been posted. > I woul

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

On Sep 17, 2014, at 3:42 PM, Ian Cordasco wrote: > > Circling back to the issue of vendoring though: it’s a conscious decision > to do this, and in the last two years there have been 2 CVEs reported for > requests. There have been none for urllib3 and none for chardet. (Frankly > I don’t think

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

On 9/17/14, 3:11 PM, "Mike Bayer" wrote: > >On Sep 17, 2014, at 3:42 PM, Ian Cordasco >wrote: > >> >> Circling back to the issue of vendoring though: it’s a conscious >>decision >> to do this, and in the last two years there have been 2 CVEs reported >>for >> requests. There have been none for

[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 will receive messages

Re: [openstack-dev] [all] Design Summit planning

On 17/09/2014 23:12, Anita Kuno wrote: > On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote: >> This looks great - but I am afraid that something might be missing. >> >> As part of the Design summit in Atlanta there was an Ops Meetup track. >> [1] I do not see where this fits into the current plan

[openstack-dev] [Sahara] Networking Service for Sahara

Hi all, What is the default networking service for Sahara? Is it Nova Network or Neutron? I referred this page http://docs.openstack.org/developer/sahara/userdoc/features.html#neutron-and-nova-network-support and it says Nova Network. Is that right? Thanks, Sharan Kumar M

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

On 18 September 2014 08:01, Dean Troyer wrote: > Interestingly enough, the distros are doing exactly what they don't want us > to do, ie, rebuilding things to use 'their' tested version of dependencies > rather than the included one... Indeed - but the distros are solving for two specific issues:

[openstack-dev] [sahara] client releases 0.7.2 & 0.7.3

Hi folks, 0.7.2 has been released with the main changes - synced oslo, updated requirements and support for security groups. The 0.7.2 release introduced stable/icehouse incompatibility and so we've released the 0.7.3 version with fix for it. Thanks. P.S. Some links: https://launchpad.net/pytho

[openstack-dev] [MagnetoDB] Core developer nomination

Hello magnetodb contributors, I'm glad to nominate Charles Wang to core developers of MagnetoDB. He is top non-core reviewer [1], implemented notifications [2] in mdb and made a great progress with performance, stability and scalability testing of MagnetoDB [1] http://stackalytics.com/report/co

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

On Wed, Sep 17, 2014 at 3:53 PM, Robert Collins wrote: > On 18 September 2014 08:01, Dean Troyer wrote: > > Interestingly enough, the distros are doing exactly what they don't want > us > > to do, ie, rebuilding things to use 'their' tested version of > dependencies > > rather than the included

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

On Wed, Sep 17, 2014 at 6:26 PM, [email protected] wrote: > Hi, > > as part of general housekeeping on our reviews, it was discussed at last > week's meeting [1] that we should set workflow -1 for stale reviews > (like gerrit used to do when I were a lad). > > The specific criteria discussed was

Re: [openstack-dev] [neutron] DVR Tunnel Design Question

Can you clarify what you mean with the thrashing condition? MAC addresses only need to be unique per-VLAN so I don't see how the same MAC on multiple VLANs from the same physical port would lead to any issues. On Wed, Sep 17, 2014 at 12:41 PM, Armando M. wrote: > VLAN is on the radar, vxlan/gre

Re: [openstack-dev] [Sahara] Networking Service for Sahara

Hi Sharan, Sahara works with either network service installed in OpenStack. If OpenStack uses neutron - sahara will use neutron too. If nova network is used, Sahara supports that as well. Thanks, Andrew. On Wed, Sep 17, 2014 at 1:38 PM, Sharan Kumar M wrote: > Hi all, > > What is the default n

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

Thanks for the effort Ivan. Your interest in brick is also helping us push forward with the idea of the agent that we've had in mind for quite some time. For those interested, I have created an etherpad that discusses some of the requirements and design decisions/discussion on the cinder/sto

[openstack-dev] [zaqar] Signing Off from Core

Hey all, I am officially removing myself as a core member of the Zaqar project. Thanks for all the good times, friends, and I wish you the best for the future! Cheers, - Alej ___ OpenStack-dev mailing list [email protected] http://lis

Re: [openstack-dev] reopen a change / pull request for nova-pythonclient ?

Thanks guys! Alex On 17 September 2014 17:16, Russell Bryant wrote: > On 09/17/2014 11:56 AM, Daniel P. Berrange wrote: > > On Wed, Sep 17, 2014 at 04:47:06PM +0100, Alex Leonhardt wrote: > >> hi, > >> > >> how does one re-open a abandoned change / pull request ? it just "timed > >> out" and wa

Re: [openstack-dev] [Cinder][Nova][Oslo] Moving Brick out of Cinder

On Sep 17, 2014 3:48 PM, "Walter A. Boring IV" wrote: > > Thanks for the effort Ivan. Your interest in brick is also helping us push forward with the idea of the agent that we've had in mind for quite some time. > > For those interested, I have created an etherpad that discusses some of the requ

[openstack-dev] pbr alpha and dev version handling

Earlier today we discovered a problem with the way pbr is generating dev version numbers for commits following tags using alpha pre-version suffixes [1]. Basically what’s happening is a commit following a tag like 1.3.0.0a3 is coming out as a 1.3.0.devX version, which then appears to be older th

Re: [openstack-dev] [zaqar] Signing Off from Core

On 09/17/2014 11:50 PM, Alejandro Cabrera wrote: > Hey all, > > I am officially removing myself as a core member of the Zaqar project. > > Thanks for all the good times, friends, and I wish you the best for the > future! Alejandro, I think I speak for everyone when I say the project is where i

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

"Sullivan, Jon Paul" writes: > I think this highlights exactly why this should be an automated > process. No errors in application, and no errors in interpretation of > what has happened. > > So the -1 from Jenkins was a reaction to the comment created by adding > the workflow -1. This is going

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-17 12:42:57 -0700: > On 9/17/14, 1:46 PM, "Clint Byrum" wrote: > > >Excerpts from Davanum Srinivas's message of 2014-09-17 10:15:29 -0700: > >> I was trying request-ifying oslo.vmware and ran into this as well: > >> https://review.openstack.org/#/c/

Re: [openstack-dev] [zaqar] Signing Off from Core

Thanks for everything Alej! Besides your contributions to the Zaqar team you also shown to be a great person. I'm truly grateful that I could have you as a mentor during GSoC. All the best :) 2014-09-17 19:14 GMT-03:00 Flavio Percoco : > On 09/17/2014 11:50 PM, Alejandro Cabrera wrote: > > Hey

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

Great question. So, some use cases, like guest agent, would like to see something around ~20ms if the agent is needing to respond to requests from a control surface/panel while a user clicks around. I spoke with a social media company who was also interested in low latency just because they have

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

On Sep 17, 2014, at 4:31 PM, Ian Cordasco wrote: > Project X pins a version of requests. Alice doesn’t know anything about > requests and does pip install X. Until Alice takes a more active role in > the development of Project X and looks into requests, she will never know > she’s installed soft

Re: [openstack-dev] [Neutron] keep old specs

I agree as well. I think moving them to an unimplemented folder makes sense and would be helpful in reviewing if one re-proposes a blueprint. On Mon, Sep 15, 2014 at 7:20 AM, Russell Bryant wrote: > On 09/15/2014 10:01 AM, Kevin Benton wrote: > > Some of the specs had a significant amount of det

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: retrying)

On a related and slightly less problematic case is another one like this... https://github.com/rholder/retrying/issues/11 On Sep 17, 2014, at 8:15 AM, Thomas Goirand wrote: > Hi, > > I'm horrified by what I just found. I have just found out this in > glanceclient: > > File "/tests/test_ssl.p

Re: [openstack-dev] [zaqar] Signing Off from Core

Thanks for all your effort on Zaqar, Alej. And all the help for me when I involved in Zaqar. I assume you will be not far away from the team and OpenStack :) On 18/09/14 09:50, Alejandro Cabrera wrote: > Hey all, > > I am officially removing myself as a core member of the Zaqar project. > > Thank

  1   2   >