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

On Mon, Feb 22, 2016, at 02:42 PM, Matt Riedemann wrote: > > > On 2/22/2016 5: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

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

On 22/02/16 17:27, "John Garbutt" wrote: >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

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

> On Feb 22, 2016, at 11:19 AM, Tim Bell wrote: > > >> On 22/02/16 18:35, "Thierry Carrez" wrote: >> >> Clayton O'Neill wrote: >>> Is the expectation that the ops mid-cycle would continue separately, >>> or be held with the meeting formerly known as

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

On 02/22/2016 11:20 AM, Daniel P. Berrange wrote: On Mon, Feb 22, 2016 at 12:07:37PM -0500, Sean Dague wrote: On 02/22/2016 10:43 AM, Chris Friesen wrote: But the fact remains that nova-compute is doing disk I/O from the main thread, and if the guests push that disk hard enough then

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

Yeah, I think the really gray issue here is the dependency thing... I think we would mostly agree that depending on a non free component for the actual implementation is bad. So, the dependency through Cassandra on the Oracle JVM is a problem. But if you allow the argument that the plugins

[openstack-dev] [nova][cinder] volumes stuck detaching attaching and force detach

Hi, Just came up on IRC, when nova-compute gets killed half way through a volume attach (i.e. no graceful shutdown), things get stuck in a bad state, like volumes stuck in the attaching state. This looks like a new addition to this conversation:

[openstack-dev] [ironic] weekly subteam status report

Hi, We are glad to present this week's subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) === - Stats (diff with 08.02.2016): - Ironic: 156 bugs (-1) + 175 wishlist items (+5). 14 new, 118 in progress (+2), 0

Re: [openstack-dev] [api][all] api variation release by release

On 13 January 2016 at 14:28, Matt Riedemann wrote: > On 1/13/2016 12:11 AM, joehuang wrote: >> >> Thanks for the information, it's good to know the documentation. The >> further question is whether there is any XML format like document will be >> published for each

[openstack-dev] [Magnum][Kuryr] Kuryr-Magnum integration (nested containers)

Hi folks, The spec [1] for Mangum-Kuryr integration is out and has already gone through good discussion and updates. Please take out some time to review, we would like to converge on the design soon. [1] https://review.openstack.org/#/c/269039/5 Thanks, Fawad Khaliq

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

On 22/02/16 18:35, "Thierry Carrez" wrote: >Clayton O'Neill wrote: >> Is the expectation that the ops mid-cycle would continue separately, >> or be held with the meeting formerly known as the Design Summit? >> >> Personally I’d prefer they be held together, but scheduled

Re: [openstack-dev] [api][all] api variation release by release

-Original Message- From: John Garbutt Reply: OpenStack Development Mailing List (not for usage questions) Date: February 22, 2016 at 12:53:49 To: OpenStack Development Mailing List (not for usage questions)

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

-Original Message- From: Brian Rosmaita Reply: OpenStack Development Mailing List (not for usage questions) Date: February 22, 2016 at 08:14:38 To: OpenStack Development Mailing List (not for usage questions)

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

On 02/22/2016 09:12 AM, Brian Rosmaita wrote: 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

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

> On 22 Feb 2016, at 17:45, Thierry Carrez wrote: > > Amrith Kumar wrote: >> [...] >> As a result of this proposal, there will still be four events each year, two >> "OpenStack Summit" events and two "MidCycle" events. > > Actually, the OpenStack summit becomes the

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

On Mon, Feb 22, 2016 at 05:20:21PM +, Amrith Kumar wrote: > Thierry and all of those who contributed to putting together this write-up, > thank you very much. > > TL;DR: +0 > > Longer version: > > While I definitely believe that the new proposed timing for "OpenStack > Summit" which is

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

On 02/22/2016 07:14 AM, Thierry Carrez wrote: Hi everyone, TL;DR: Let's split the events, starting after Barcelona. Time is ripe for a change. After Tokyo, we at the Foundation have been considering options on how to evolve our events to solve those issues. This proposal is the result of

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

On 02/22/2016 09:45 AM, Thierry Carrez wrote: Amrith Kumar wrote: [...] As a result of this proposal, there will still be four events each year, two "OpenStack Summit" events and two "MidCycle" events. Actually, the OpenStack summit becomes the midcycle event. The new separated

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

On Mon, Feb 22, 2016 at 11:51 AM, Walter A. Boring IV wrote: > On 02/22/2016 09:45 AM, Thierry Carrez wrote: > >> Amrith Kumar wrote: >> >>> [...] >>> As a result of this proposal, there will still be four events each year, >>> two "OpenStack Summit" events and two

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

On 2/22/2016 5: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] [nova] python-novaclient region setting

That's just what I was after - thanks for that! On 23 February 2016 at 03:02, Monty Taylor wrote: > 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

[openstack-dev] [ironic] [stable] iPXE / UEFI support for stable liberty

Hi Ironicers, I wanted to draw attention to iPXE / UEFI support in our stable liberty branch. There are environments that require support for UEFI, while ironic does have this support in master, it is not capable of this in many configurations when using the stable liberty release and the docs

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

On Mon, Feb 22, 2016 at 7:14 AM, Thierry Carrez wrote: > Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona > Thank you for the excellent write-up, Thierry (and everyone else behind it)! This sounds great to me. > Long long version: > > In a global

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] A prototype implementation towards the "shared state scheduler"

On 21 February 2016 at 13:51, Cheng, Yingxin wrote: > On 19 February 2016 at 5:58, John Garbutt wrote: >> On 17 February 2016 at 17:52, Clint Byrum wrote: >> > Excerpts from Cheng, Yingxin's message of 2016-02-14 21:21:28 -0800: >> Long term, I see a

Re: [openstack-dev] [neutron] Backup port info to restore the flow rules

Jian Wen wrote: I don't think it's enough for a large scale cloud. When the neutron server is not available and the flow rules are gone, we need the backup to restore the flow rules. Flows should not be reset when neutron-server is down. If that’s the case,

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] [neutron] Backup port info to restore the flow rules

I don't think it's enough for a large scale cloud. When the neutron server is not available and the flow rules are gone, we need the backup to restore the flow rules. We have more than a thousand physical servers in our production environment. Rare events will occur where combined

Re: [openstack-dev] [QA][Tempest]Run only multinode tests in multinode jobs

Assaf Muller wrote: On Tue, Feb 16, 2016 at 2:52 PM, Matthew Treinish wrote: On Tue, Feb 16, 2016 at 10:07:19AM +0100, Jordan Pittier wrote: Hi list, I understood we need to limit the number of tests and jobs that are run for each Tempest patch

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

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-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] [cinder] adding a new /v3 endpoint for api-microversions

On 22 February 2016 at 06:40, 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

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] [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] [kolla][vote] port neutron thin containers to stable/liberty

On 02/21/2016 05:18 PM, Michał Jastrzębski wrote: So for thin containers, as opposed to data containers, there is no migration script needed whatsoever. All it takes is to tear down neutron-agents and start thin containers. OK, so from what I understand, we need to do what you wrote here in

Re: [openstack-dev] [openstack-infra] Getting Started Guide

On 2016-02-23 04:45, Kenny Johnston wrote: > * The Product Work Group (PWG) uses the openstack-user-stories > repository and gerrit to review and produce .rst formatted user stories > * The PWG is comprised (mostly) of non-developers > * We've found the Getting Started guide a bit

[openstack-dev] [tricircle]weekly meeting of Feb.24

IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 13:00. We did not talk a lot on our agent last meeting, let's continue the discussion. Agenda: # Progress of To-do list review: https://etherpad.openstack.org/p/TricircleToDo # SEG # Quota

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

Hi Daisy, AFAIK the following horizon plugins are ready for translation. I tested and confirmed translations of these two work well with Japanese. A minor improvement on devstack or other stuff are in progress but it does not affect translation. * trove-dashboard * sahara-dashboard The

Re: [openstack-dev] [horizon][i18n] Any Horizon plugins ready for translation in Mitaka?

On 2016-02-23 07:52, Ying Chun Guo wrote: > Hi, > > Mitaka translation will be started from March 4 and ended in the week of > March 28. > I'd like to know which Horizon plugins[1] are ready for translation in > Mitaka release. > If there are, I'm happy to include them in the Mitaka translation

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] [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.

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

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] [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] [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-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] [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] [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] [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] [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-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] [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

[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] [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] 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] 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] [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] [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] [nova][neutron] How would nova microversion get-me-a-network in the API?

On 2/22/2016 2:27 PM, Sean Dague wrote: On 02/22/2016 02:50 PM, Andrew Laski wrote: On Mon, Feb 22, 2016, at 02:42 PM, Matt Riedemann wrote: On 2/22/2016 5: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

[openstack-dev] [heat][magnum] Magnum gate issue

Hi Heat team, It looks Magnum gate broke after this patch was landed: https://review.openstack.org/#/c/273631/ . I would appreciate if anyone can help for trouble-shooting the issue. If the issue is confirmed, I would prefer a quick-fix or a revert, since we want to unlock the gate ASAP.

Re: [openstack-dev] [fuel] Move virtualbox scripts to a separate directory

New git repository fuel-virtualbox has been created https://github.com/openstack/fuel-virtualbox.git and since now all review requests that are related to virtualbox scripts for releases 9.0 and later should be sent to the new git repository. Checklist status: - Launchpad bug:

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

On Mon, Feb 22, 2016 at 1:52 PM, Jay Pipes wrote: > On 02/22/2016 12:45 PM, Thierry Carrez wrote: > >> I don't think the proposal removes that opportunity. Contributors /can/ >> still go to OpenStack Summits. They just don't /have to/. I just don't >> think every contributor

Re: [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

[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

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] [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 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

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-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] [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

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

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

-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] 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

+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] [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

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] [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] [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

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-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.

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-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] [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] [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] [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-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-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

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] [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 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] [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

[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

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] Do we need lock fencing?

On 02/19/2016 06:05 PM, Joshua Harlow wrote: Hi all, After reading over the following interesting article about redis and redlock (IMHO it's good overview of distributed locking in general):

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

On Mon, Feb 22, 2016 at 11:51 AM, Tim Bell wrote: > > > > > > On 22/02/16 17:27, "John Garbutt" wrote: > > >On 22 February 2016 at 15:31, Monty Taylor wrote: > >> On 02/22/2016 07:24 AM, Russell Bryant wrote: > >>> On Mon, Feb 22,

[openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

Before migrating into oslo.db the opportunistic testing for database backends was pretty simple. Create an openstack_citest@openstack_citest pw:openstack_citest and you could get tests running on mysql. This no longer seems to be the case. I went digging through the source code a bit and it's not

  1   2   >