Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

On 2/22/16, 10:13 AM, "Jeff Peeler" wrote: >On Mon, Feb 22, 2016 at 9:07 AM, Steven Dake (stdake) >wrote: >> The issue isn't about reviewing patches in my opinion. Obviously people >> shouldn't jam patches through the review queue that they know will be

Re: [openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO

On Mon, Feb 22, 2016 at 12:07:37PM -0500, Sean Dague wrote: > On 02/22/2016 10:43 AM, Chris Friesen wrote: > > Hi all, > > > > We've recently run into some interesting behaviour that I thought I > > should bring up to see if we want to do anything about it. > > > > Basically the problem seems to

Re: [openstack-dev] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

As a reminder, we will proceed with a formal vote on $subject at the next RDO meeting on Wednesday, 24th Feb, 2016 1500 UTC [1]. Feel free to join us on #rdo on freenode. [1]: https://etherpad.openstack.org/p/RDO-Meeting David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard =

Re: [openstack-dev] [all] A proposal to separate the design summit

> On Feb 22, 2016, at 8:52 AM, Clayton O'Neill wrote: > > I think this is a great proposal, but like Matt I’m curious how it > might impact the operator sessions that have been part of the Design > Summit and the Operators Mid-Cycle. > > As an operator I got a lot out of

Re: [openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO

On 02/22/2016 11:30 AM, Chris Friesen wrote: On 02/22/2016 11:17 AM, Jay Pipes wrote: On 02/22/2016 10:43 AM, Chris Friesen wrote: Hi all, We've recently run into some interesting behaviour that I thought I should bring up to see if we want to do anything about it. Basically the problem

Re: [openstack-dev] [Rdo-list] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

On Mon, Feb 22, 2016 at 9:46 AM, Dan Prince wrote: > Does this mean RDO Manager will be adopting use of the nicely rounded > owl mascot as well? > > http://tripleo.org/ > > As far as upstream branding goes this would really make it crystal > clear to me... :) "RDO Manager"

[openstack-dev] [release][oslo] oslo.messaging 4.4.0 release (mitaka)

We are content to announce the release of: oslo.messaging 4.4.0: Oslo Messaging API This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.messaging With package available at:

[openstack-dev] [release][oslo] tooz 1.32.0 release (mitaka)

We are happy to announce the release of: tooz 1.32.0: Coordination library for distributed systems. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/tooz With package available at: https://pypi.python.org/pypi/tooz

[openstack-dev] [release][oslo] taskflow 1.29.0 release (mitaka)

We are amped to announce the release of: taskflow 1.29.0: Taskflow structured state management library. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/taskflow With package available at:

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

On Mon, Feb 22, 2016 at 9:07 AM, Steven Dake (stdake) wrote: > The issue isn't about reviewing patches in my opinion. Obviously people > shouldn't jam patches through the review queue that they know will be > counter-productive to the majority view of the core reviewers. If

[openstack-dev] [release][oslo] oslo.service 1.6.0 release (mitaka)

We are tickled pink to announce the release of: oslo.service 1.6.0: oslo.service library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.service With package available at:

[openstack-dev] [release][oslo] oslotest 2.2.0 release (mitaka)

We are gleeful to announce the release of: oslotest 2.2.0: Oslo test framework This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslotest With package available at: https://pypi.python.org/pypi/oslotest Please report

[openstack-dev] [release][oslo] oslo.privsep 1.2.0 release (mitaka)

We are tickled pink to announce the release of: oslo.privsep 1.2.0: OpenStack library for privilege separation This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.privsep With package available at:

Re: [OpenStack-Infra] [Shade]

On 2/22/16 9:44 AM, Monty Taylor wrote: > It sounds like a thing we should do in normalize_neutron_floating_ips > for sure. I'd love to see if we can figure out why we're not getting a > status - or if there are any cases where supplying 'active' when we get > nothing might harm us. > > We also

[openstack-dev] [release][oslo] oslo.config 3.8.0 release (mitaka)

We are pumped to announce the release of: oslo.config 3.8.0: Oslo Configuration API This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.config With package available at: https://pypi.python.org/pypi/oslo.config

[openstack-dev] [release][oslo] oslo.concurrency 3.5.0 release (mitaka)

We are chuffed to announce the release of: oslo.concurrency 3.5.0: Oslo Concurrency library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.concurrency With package available at:

[openstack-dev] [release][oslo] oslo.log 3.1.0 release (mitaka)

We are pleased to announce the release of: oslo.log 3.1.0: oslo.log library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.log With package available at: https://pypi.python.org/pypi/oslo.log Please report

[openstack-dev] [release][oslo] oslo.context 2.1.0 release (mitaka)

We are tickled pink to announce the release of: oslo.context 2.1.0: Oslo Context library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.context With package available at:

Re: [openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO

On 02/22/2016 10:43 AM, Chris Friesen wrote: > Hi all, > > We've recently run into some interesting behaviour that I thought I > should bring up to see if we want to do anything about it. > > Basically the problem seems to be that nova-compute is doing disk I/O > from the main thread, and if it

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Back to the original thread: what does "no open core" mean in OpenStack 2016 ? I think working on that could help sway the Poppy decision one way or another: my original clarification proposal ("It should have a fully-functional, production-grade open source implementation") would mean we

[openstack-announce] [release][openstack] cliff 2.0.0 release (mitaka)

We are glad to announce the release of: cliff 2.0.0: Command Line Interface Formulation Framework This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/cliff With package available at: https://pypi.python.org/pypi/cliff

Re: [openstack-dev] [all] A proposal to separate the design summit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/22/2016 10:45 AM, Jay Pipes wrote: >> If you now have a separate summit/meeting for the developers away >> from the big splashy business event, I'm wondering if we might >> make it harder for many developers to get funded for this >> travel.

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

On 22 February 2016 at 08:52, Ihar Hrachyshka wrote: > Armando M. wrote: > > >> >> On 22 February 2016 at 04:56, Ihar Hrachyshka >> wrote: >> Sean M. Collins wrote: >> >> Armando M. wrote: >> Now that the

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/20/2016 02:42 PM, Duncan Thomas wrote: On 20 Feb 2016 00:21, "Walter A. Boring IV" > wrote: > Not that I'm adding much to this conversation that hasn't been said already, but I am pro v2 API, purely because of how painful and long

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Armando M. wrote: On 22 February 2016 at 04:56, Ihar Hrachyshka wrote: Sean M. Collins wrote: Armando M. wrote: Now that the blocking issue has been identified, I filed project-config change [1] to enable us to test the Neutron

Re: [openstack-dev] [all] A proposal to separate the design summit

I think this is a great proposal, but like Matt I’m curious how it might impact the operator sessions that have been part of the Design Summit and the Operators Mid-Cycle. As an operator I got a lot out of the cross-project designs sessions in Tokyo, but they were scheduled at the same time as

Re: [openstack-dev] [all] A proposal to separate the design summit

+1 Ghe Rivero Quoting Monty Taylor (2016-02-22 08:31:44) > On 02/22/2016 07:24 AM, Russell Bryant wrote: > > > > > > On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > > wrote: > > > > Hi everyone, > > > > TL;DR: Let's split the

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 11:36 AM, Ed Leafe wrote: One thing that hasn't been mentioned is the push by many of the larger companies involved to have their devs give as many presentations as possible at the Summit in the hope of improving their visibility in the OpenStack world, and possibly also providing

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

On 22 February 2016 at 04:56, Ihar Hrachyshka wrote: > Sean M. Collins wrote: > > Armando M. wrote: >> >>> Now that the blocking issue has been identified, I filed project-config >>> change [1] to enable us to test the Neutron Grenade multinode more >>>

Re: [openstack-dev] [all] A proposal to separate the design summit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/22/2016 09:14 AM, Thierry Carrez wrote: > The second event would be the main downstream business conference, > with high-end keynotes, marketplace and breakout sessions. It would > be organized two or three months /after/ the release, to give

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 10:14 AM, Thierry Carrez wrote: Hi everyone, TL;DR: Let's split the events, starting after Barcelona. Long long version: In a global and virtual community, high-bandwidth face-to-face time is essential. This is why we made the OpenStack Design Summits an integral part of our

Re: [Openstack-operators] [openstack-dev] [all] A proposal to separate the design summit

Cross-post to openstack-operators... As an operator, there's value in me attending some of the design summit sessions to provide feedback and guidance. But I don't really need to be in the room for a week discussing minutiae of implementations. So I probably can't justify 2 extra trips just to

Re: [openstack-dev] [all] A proposal to separate the design summit

Cross-post to openstack-operators... As an operator, there's value in me attending some of the design summit sessions to provide feedback and guidance. But I don't really need to be in the room for a week discussing minutiae of implementations. So I probably can't justify 2 extra trips just to

Re: [openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO

On 02/22/2016 11:17 AM, Jay Pipes wrote: On 02/22/2016 10:43 AM, Chris Friesen wrote: Hi all, We've recently run into some interesting behaviour that I thought I should bring up to see if we want to do anything about it. Basically the problem seems to be that nova-compute is doing disk I/O

Re: [openstack-dev] [all] A proposal to separate the design summit

On 22 February 2016 at 15:31, Monty Taylor wrote: > On 02/22/2016 07:24 AM, Russell Bryant wrote: >> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez >> > wrote: >>> Hi everyone, >>> TL;DR: Let's split the events,

Re: [openstack-dev] [all] A proposal to separate the design summit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/22/2016 10:09 AM, Thierry Carrez wrote: >> We really want to make sure we keep the mid-cycles portrayed as >> optional small scale "hackathons", and not something that >> contributors feel obligated to attend. IMHO they're already >> risking

Re: [openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO

On 02/22/2016 10:43 AM, Chris Friesen wrote: Hi all, We've recently run into some interesting behaviour that I thought I should bring up to see if we want to do anything about it. Basically the problem seems to be that nova-compute is doing disk I/O from the main thread, and if it blocks then

Re: [openstack-dev] [all] A proposal to separate the design summit

Daniel P. Berrange wrote: On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote: Hi everyone, TL;DR: Let's split the events, starting after Barcelona. Yes, please. Your proposal addresses the big issue I have with current summits which is the really poor timing wrt start of each dev

Re: [openstack-dev] [all] A proposal to separate the design summit

+1 hits all the points. Solid proposal. On Feb 22, 2016 7:14 AM, "Thierry Carrez" wrote: > Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona. > > Long long version: > > In a global and virtual community, high-bandwidth face-to-face time is >

Re: [Openstack] [openstack][swift] Question about Swift consistency and concurrent requests

inline On 22 Feb 2016, at 5:06, Kévin Bernard-Allies wrote: > Hello, > > I've some questions about the handling of concurrent requests by Swift. > Any help would be great:) > > > If I understand correctly, a PUT request on swift-proxy will be transmitted > to at least half the storage nodes

Re: [openstack-dev] [all] A proposal to separate the design summit

I agree with Daniel + a couple more comments inline. On 02/22/2016 04:49 PM, Daniel P. Berrange wrote: On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote: Hi everyone, TL;DR: Let's split the events, starting after Barcelona. Yes, please. Your proposal addresses the big issue I

Re: [openstack-dev] [all] A proposal to separate the design summit

Anne Gentle wrote: [...] In practice, the split means that we need to stagger the events and cycles. We have a long time between Barcelona and the Q1 Summit in the US, so the idea would be to use that long period to insert a smaller cycle (Ocata) with a release early March, 2017

Re: [Openstack-operators] COMMERCIAL:Re: How to install magnum?

Mike (Perez) I believe he’s referring to me. I volunteered to help write Operator/Production oriented documentation assuming that there are RPMs I can use (and that eventually those RPMs are part of RDO) Mike Smith Lead Cloud Systems Architect Overstock.com On Feb

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 10:31 AM, Monty Taylor wrote: > On 02/22/2016 07:24 AM, Russell Bryant wrote: >> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > > wrote: >> >> Hi everyone, >> >> TL;DR: Let's split the events, starting after Barcelona.

[openstack-dev] [Watcher] mid-cycle highlights

Hi Watcher team, The etherpad related to our last mid-cycle meetup [1]. Main highlights are : - use cases refresh [2] - Mitaka priorities review [3] - Discussions around Watcher data model - Discussions around using Nova API for migrating VMs [4] - Creation of watcher-dashboard project [5] -

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 10:14 AM, Thierry Carrez wrote: > The idea would be to split the events. The first event would be for > upstream technical contributors to OpenStack. It would be held in a > simpler, scaled-back setting that would let all OpenStack project teams > meet in separate rooms, but in a

Re: [Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

On 2/20/2016 5:29 PM, Matt Riedemann wrote: On 2/19/2016 4:48 PM, Kris G. Lindgren wrote: ___ Kris Lindgren Senior Linux Systems Engineer GoDaddy On 2/19/16, 10:07 AM, "Matt Riedemann"

Re: [Openstack-operators] COMMERCIAL:Re: How to install magnum?

On 02/17/2016 10:05 AM, Adrian Otto wrote: Mike, I’m thrilled to hear that you are willing to help with this. I approved the blueprint. Please let me know if you need any help getting set up to contribute your work so we can get it published at docs.openstack.org .

Re: [openstack-dev] [all] A proposal to separate the design summit

On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote: > Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona. Yes, please. Your proposal addresses the big issue I have with current summits which is the really poor timing wrt start of each dev cycle. > The idea

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

On 02/20/2016 03:58 PM, Steven Dake (stdake) wrote: Neutron, the largest project in OpenStack by active committers and reviewers as measured by the governance repository teamstats tool, has a limit of 2 core reviewers per company. They do that for a reason. I expect Kolla will grow over time

Re: [openstack-dev] [all] A proposal to separate the design summit

On Mon, Feb 22, 2016 at 9:14 AM, Thierry Carrez wrote: > Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona. > > Long long version: > > In a global and virtual community, high-bandwidth face-to-face time is > essential. This is why we made the

Re: [OpenStack-Infra] [Shade]

On 02/21/2016 09:42 AM, David Cramer wrote: Hi there, We've encountered an edge case where Shade (via the os_server module in Ansible 2.0) fails because the call to v2.0/floatingips/{id} is not returning a status. We have tenants in different data centers. It is only in one of these that we

[openstack-dev] [nova] nova-compute blocking main thread under heavy disk IO

Hi all, We've recently run into some interesting behaviour that I thought I should bring up to see if we want to do anything about it. Basically the problem seems to be that nova-compute is doing disk I/O from the main thread, and if it blocks then it can block all of nova-compute (since all

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/16 17:31, Monty Taylor wrote: > On 02/22/2016 07:24 AM, Russell Bryant wrote: >> >> >> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > > wrote: >> >> Hi everyone, >> >> TL;DR: Let's split the events, starting after

Re: [Openstack] openstack swift

Th short answer is that no you cannot specify a storage node for a given object. Data placement is done with the hash ring, so placement is based on the hash of the object name and the current state of the drives in the cluster. --John On 22 Feb 2016, at 4:06, pgh pgh wrote: > Hello All, >

Re: [openstack-dev] [all] A proposal to separate the design summit

+1 Matt On Mon, Feb 22, 2016 at 3:31 PM, Monty Taylor wrote: > On 02/22/2016 07:24 AM, Russell Bryant wrote: > >> >> >> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > > wrote: >> >> Hi everyone, >> >>

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 22 February 2016 at 15:14, John Garbutt wrote: > On 22 February 2016 at 12:01, Jay Pipes wrote: >> On 02/22/2016 06:56 AM, Sean Dague wrote: >>> On 02/19/2016 12:49 PM, John Garbutt wrote: >>> Consider a user that uses these four clouds: *

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 07:24 AM, Russell Bryant wrote: On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > wrote: Hi everyone, TL;DR: Let's split the events, starting after Barcelona. This proposal sounds fantastic. Thank you very much to

Re: [openstack-dev] [all] A proposal to separate the design summit

On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez wrote: > Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona. > This proposal sounds fantastic. Thank you very much to those that help put it together. -- Russell Bryant

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

-Original Message- From: Mike Perez Reply: OpenStack Development Mailing List (not for usage questions) Date: February 19, 2016 at 19:21:13 To: openstack-dev@lists.openstack.org Subject:  Re:

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 22 February 2016 at 12:01, Jay Pipes wrote: > On 02/22/2016 06:56 AM, Sean Dague wrote: >> On 02/19/2016 12:49 PM, John Garbutt wrote: >> >>> Consider a user that uses these four clouds: >>> * nova-network flat DHCP >>> * nova-network VLAN manager >>> * neutron with a

[openstack-dev] [all] A proposal to separate the design summit

Hi everyone, TL;DR: Let's split the events, starting after Barcelona. Long long version: In a global and virtual community, high-bandwidth face-to-face time is essential. This is why we made the OpenStack Design Summits an integral part of our processes from day 0. Those were set at the

[openstack-dev] [puppet] CI issues

Hey, Just to let you know about 2 CI issues that we're working on: * puppet-keystone beaker jobs are broken - Sofer and I work on it: https://review.openstack.org/#/c/280385/ * scenario001 fails on centos7 because of MariaDB update in RDO - should be fixed by today or so. Please ask me any CI

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks for the +1s everyone. Since there have been no objections, I'd like to welcome Fernando to the Barbican Core team. Thanks, - - Douglas Mendizábal On 2/17/16 11:33 AM, John Wood wrote: > +1 > > On 2/16/16, 12:52 PM, "Ade Lee"

Re: [openstack-dev] [horizon] [octavia] [heat] [docs] Meeting times and the -cp meeting room

On Mon, Feb 22, 2016 at 8:49 AM, Anne Gentle wrote: > Hi all, > > The docs team has been seeking a new meeting time for North America/Europe > for a couple of months now. With that search comes the search for a meeting > room. Here's what we know: > > We want Wed

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Sean M. Collins wrote: Also, what do we do with non-partial flavour of the job? Is it staying? Is it useful? I think operators are more likely to upgrade components of a cluster incrementally - so the partial jobs are going to reflect the reality on the ground better.

[openstack-dev] [horizon] [octavia] [heat] [docs] Meeting times and the -cp meeting room

Hi all, The docs team has been seeking a new meeting time for North America/Europe for a couple of months now. With that search comes the search for a meeting room. Here's what we know: We want Wed 20:00. Heat, Horizon, and Octavia are currently in the three meeting rooms in the time slot we

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On Mon, Feb 22, 2016, at 07:07 AM, Chris Dent wrote: > On Mon, 22 Feb 2016, Sean Dague wrote: > > > that being said... I think the behavior of CLI tools should default to > > nic auto being implied. The user experience there is different. You use > > cli tools for one off boots of things, so

Re: [openstack-dev] [api] header non proliferation (that naming thing, _again_)

On 02/22/2016 07:00 AM, Sean Dague wrote: On 02/21/2016 01:41 PM, Jay Pipes wrote: On 02/21/2016 12:50 PM, Chris Dent wrote: In a recent api-wg meeting I set forth the idea that it is both a bad idea to add lots of different headers and to add headers which have meaning in the name of the

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 2/22/16, 9:33 AM, "Sean McGinnis" wrote: >On Sun, Feb 21, 2016 at 07:59:17PM +0200, Duncan Thomas wrote: >> >> So we can't get users to change endpoints, or write our libraries to >>have >> sensible defaults, but we're somehow going to magically get consumers >>to do

Re: [openstack-dev] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

On Wed, 2016-02-17 at 11:27 -0500, David Moreau Simard wrote: > Greetings, > > (Note: cross-posted between rdo-list and openstack-dev to reach a > larger audience) > > Today, because of the branding and the name "RDO Manager", you might > think that it's something other than TripleO - either

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Ihar Hrachyshka wrote: > I guess the next steps are: > - monitoring the job for a week, making sure it’s stable enough (comparing > failure rate to non-partial grenade job?); > - if everything goes fine, propose project-config change to make it voting; > - propose governance patch to enable

Re: [openstack-dev] [TripleO] Stable branch policy for Mitaka

On Wed, 2016-02-10 at 15:57 +, Steven Hardy wrote: > Hi all, > > We discussed this in our meeting[1] this week, and agreed a ML > discussion > to gain consensus and give folks visibility of the outcome would be a > good > idea. > > In summary, we adopted a more permissive "release branch"

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Sun, Feb 21, 2016 at 07:59:17PM +0200, Duncan Thomas wrote: > > So we can't get users to change endpoints, or write our libraries to have > sensible defaults, but we're somehow going to magically get consumers to do > the much harder job of doing version probes in their code/libraries so that

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

Hey Steve, I think the concept of having a limit on cores from a company or a block on # core reviewers from the same company on a patch is not the right approach. I understand the methodology behind this is to make sure we stay honest to the code base and objective when reviewing, but I

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On Mon, Feb 22, 2016 at 12:40:48PM +0800, Thomas Goirand wrote: > > I'd vote for the extra round trip and implementation of caching whenever > possible. Using another endpoint is really annoying, I already have > specific stuff for cinder to setup both v1 and v2 endpoint, as v2 > doesn't fully

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

Hi folks, I thought long and hard as how to not make this an exception and came up with the following. I would be in favor (+1) of this particular feature addition, on the conditions that: 1. This does not set a precedent that features will be backported by the typical +2/+2/+W 2. Any

[openstack-dev] [Bareon] Weekly update

Hi, Here is weekly update from Bareon team. 1. 3 specs from Cray team were merged [0], roadmap was properly adjusted [1] 2. Changing deployment data using extensions in Nailgun [2], spec is merged, code is on review [3] 3. Extensions testing procedure, spec is in progress [4] 4. Dynamic

Re: [openstack-dev] [kolla]

removed multiple python packages via yum and pip uninstall. that made it past it. now hitting a mariadb error early in the deploy If anyone can help I would really appreciate it. Im on #kolla @ wadeholler http://pastebin.com/83jL0ege On Sat, Feb 20, 2016 at 9:45 AM Wade Holler

Re: [openstack-dev] [glance]one more use case for Image Import Refactor from OPNFV

Hello everyone, Joe, I think you are proposing a perfectly legitimate use case, but it's not what the Glance community is calling "image import", and that's leading to some confusion. The Glance community has defined "image import" as: "A cloud end-user has a bunch of bits that they want to give

Re: [openstack-dev] [kolla] discussion about core reviewer limitations by company

From: Eric LEMOINE > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > Date: Monday, February 22, 2016 at 1:13 AM To: "OpenStack Development

Re: [openstack-dev] [nova] python-novaclient region setting

On 02/21/2016 11:40 PM, Andrey Kurilin wrote: Hi! `novaclient.client.Client` entry-point supports almost the same arguments as `novaclient.v2.client.Client`. The difference is only in api_version, so you can set up region via `novaclient.client.Client` in the same way as

Re: [openstack-dev] [sahara][horizon] translation support in sahara-dashboard and INSTALLED_APPS

My best guess is that the current setting for INSTALLED_APPS wound-up being derived from the slightly nomadic history (moving from its own repo, then into horizon, then into contrib, then back to its own repo). I most likely didn't think much it other than to shorten the way that we reference our

Re: [Openstack] Whole sections of ml2_conf.ini being ignored?

I highly recommend using the correct config files vs the symlink configuration. I think the guide should be updated to reflect the config based on the driver instead... when you run yum update ect it will break neutron until you re-edit the systemd files. From: "Matt Kassawara"

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

Hi all. I'm a little conflicted with my vote. I'm against the concept of backporting a feature, but this feature also has some important additions to stability. It's just whether or not the stability advantages are critical enough. To me, it seems like they are. I just want to note that we

Re: [Openstack] nova service-disable

OK, thanks Jay! I've now disabled this compute node, and all instances are up and active ;-) Thanks a lot for your help! Best regards Yngvi -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 22. febrúar 2016 11:40 To: openstack@lists.openstack.org Subject: Re:

[Openstack] [openstack][swift] Question about Swift consistency and concurrent requests

Hello, I've some questions about the handling of concurrent requests by Swift. Any help would be great:) If I understand correctly, a PUT request on swift-proxy will be transmitted to at least half the storage nodes plus one, before returning the response. A subsequent GET request should

Re: [openstack-dev] OpenStack Contributor Awards

Oh I missed this thread... really great initiative! It's time to recognize the effort of our fellow stackers :D Raspi/Arduino kits or limited edition t-shirts are very cool goodies Cheers, V 2016-02-22 0:21 GMT-03:00 Steve Martinelli : > limited edition (and hilarious)

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Sean M. Collins wrote: Armando M. wrote: Now that the blocking issue has been identified, I filed project-config change [1] to enable us to test the Neutron Grenade multinode more thoroughly. [1] https://review.openstack.org/#/c/282428/ Indeed - I want to profusely

[Openstack] Cannot setup network: Cannot find any PID under container

Hi, I am using nova-docker to run docker containers from Openstack. Some of my containers are not able to setup network and they give this error: *Cannot setup network: Cannot find any PID under container* I have already tried to set *tty:True* on the driver.py and it still fails. When I fire up

[Openstack] openstack swift

Hello All, I'm a beginner with openstack but I'm mainly interested in Swift... I was wonder if in addition to use the Swift modified consistent hashing ring, is possible to manually specify the storage node, if so, how does Swift to maintain load balancing ? *Thanks and best regards,* *Pgh*

Re: [openstack-dev] [api] header non proliferation (that naming thing, _again_)

On 02/22/2016 07:00 AM, Sean Dague wrote: On 02/21/2016 01:41 PM, Jay Pipes wrote: On 02/21/2016 12:50 PM, Chris Dent wrote: In a recent api-wg meeting I set forth the idea that it is both a bad idea to add lots of different headers and to add headers which have meaning in the name of the

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On Mon, 22 Feb 2016, Sean Dague wrote: that being said... I think the behavior of CLI tools should default to nic auto being implied. The user experience there is different. You use cli tools for one off boots of things, so should be as easy as possible. Thanks Sean, throughout this entire

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 02/22/2016 06:56 AM, Sean Dague wrote: On 02/19/2016 12:49 PM, John Garbutt wrote: Consider a user that uses these four clouds: * nova-network flat DHCP * nova-network VLAN manager * neutron with a single provider network setup * neutron where user needs to create their own network For

Re: [openstack-dev] [api] header non proliferation (that naming thing, _again_)

On 02/21/2016 01:41 PM, Jay Pipes wrote: > On 02/21/2016 12:50 PM, Chris Dent wrote: >> >> In a recent api-wg meeting I set forth the idea that it is both a >> bad idea to add lots of different headers and to add headers which >> have meaning in the name of the header (rather than just the value).

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 02/19/2016 12:49 PM, John Garbutt wrote: > > Consider a user that uses these four clouds: > * nova-network flat DHCP > * nova-network VLAN manager > * neutron with a single provider network setup > * neutron where user needs to create their own network > > For the first three, the user

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/21/2016 12:59 PM, Duncan Thomas wrote: > On 21 February 2016 at 19:34, Jay S. Bryant > > > wrote: > > Spent some time talking to Sean about this on Friday afternoon and > bounced back and forth between the two

Re: [Openstack] nova service-disable

On 02/22/2016 05:38 AM, Yngvi Páll Þorfinnsson wrote: Hi I want to stop instances from beeing created on one of our compute nodes, i.e. „*compute1*“ But I want all current instances on *compute1* to be active and available. I thus disable the nova service for this node: # nova

Re: [Openstack] Protest against Glance V2 usability, it is worse than V1! Bring back "--location to image-create"! Or am I missing something here? (fwd)

Hi Martinx, Thanks for your feedback. You're not the only person to have been affected. The (lack of) backwards compatibilty of the v2 CLI is captured here: https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability A small number of these incompatabilities are due to unmaskable

Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty

+1 I'm against this on a theoretical basis as I don't think backporting features/architectural changes is good practice for a stable branch. People will say this will increase stability (no longer lose namespaces on container restart), in reality the chances are it will decrease stability

<    1   2   3   >