[openstack-dev] [heat] About intrinsic function to convert string to map/json

Hi, Is there any intrinsic function can convert string to map/json? When I’m writing templates for senlin resources, I use following yaml: profile: type: OS::Senlin::Profile properties: type: os.heat.stack-1.0 properties: template: {get_file: server.yaml} H

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

Le 20 févr. 2016 18:12, "Steven Dake (stdake)" a écrit : > > Hey folks, > > Mirantis has been developing a big footprint in the core review team, and Red Hat already has a big footprint in the core review team. These are all good things, but I want to avoid in the future a situation in which one

Re: [openstack-dev] [Fuel] Wildcards instead of

On 20.02.2016 10:29, Evgeniy L wrote: > Hi, > > +1 to Igor, plugin developer should be able to granularly define what > she/he wants to be executed on the node, without assumptions from our side. > > `exclude` - field doesn't look like a good solution to me, it will be > hard to support and migra

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

Hi Matt, thanks for good hint ! Issue disappeared with newer python-openstackclient-1.0.3-3.fc23.noarch python-openstackclient-1.0.1-1.fc22.noarch is too old, it’s interesting, as supported platforms for puppet-openstack is fedora21,22 and I get it running just with fc23 ☺ best regards, Michal

Re: [openstack-dev] [kuryr] Failed to create network with kuryr driver type

Hi, updated the latest kuryr version, my test results as follows, still have problem with docker network( docker cannot list the created net, but neutron can show the net): ubuntu@kuryr1:~$ docker network create --driver=kuryr --ipam-driver=kuryr --subnet 10.10.1.0/24 --gateway 10.10.1.1 --ip-ran

Re: [openstack-dev] [stable][i18n] What is the backport policy on i18n changes?

Matt Riedemann wrote: I don't think we have an official policy for stable backports with respect to translatable string changes. I'm looking at a release request for ironic-inspector on stable/liberty [1] and one of the changes in that has translatable string changes to user-facing error message

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

Sorry for chiming in late. It sounds natural to me that when no --nic option is specified and no neutron network exists 'get-me-a-network' feature is used. After a network for a project is created by a get-me-a-network or when a project already has one network, a user do not need to specify --nic

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

So, that thread is becoming hard to follow, but I'll try to reply. Le 21/02/2016 20:56, Jay Pipes a écrit : Yingxin, sorry for the delay in responding to this thread. My comments inline. On 02/17/2016 12:45 AM, Cheng, Yingxin wrote: To better illustrate the differences between shared-state,

Re: [openstack-dev] Do we need lock fencing?

Joshua Harlow wrote: After reading over the following interesting article about redis and redlock (IMHO it's good overview of distributed locking in general): http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html#protecting-a-resource-with-a-lock (I personally recommend peopl

Re: [openstack-dev] [Fuel] Wildcards instead of

Would namespaces be compatible with existing plugins? On Mon, Feb 22, 2016 at 7:33 PM, Bogdan Dobrelya wrote: > On 20.02.2016 10:29, Evgeniy L wrote: > > Hi, > > > > +1 to Igor, plugin developer should be able to granularly define what > > she/he wants to be executed on the node, without assumpt

Re: [openstack-dev] [Fuel] Wildcards instead of

On 22.02.2016 10:28, Kyrylo Galanov wrote: > Would namespaces be compatible with existing plugins? It should be, if the default namespace will be "core" > > On Mon, Feb 22, 2016 at 7:33 PM, Bogdan Dobrelya > wrote: > > On 20.02.2016 10:29, Evgeniy L wrote: >

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

Jian Wen wrote: Hello, If we restart OvS/ovs-agent when one or more of Neutron, MySQL and RabbitMQ is not available, the flow rules in OvS will be gone. If Neutron/MySQL/RabbitMQ doesn't become available in time, the VMs will lose their network connections. It's not easy for an operations engi

Re: [openstack-dev] [kolla][vote] Proposing Angus Salkeld for kolla-core

+1 On 22/02/16 03:23, Jeffrey Zhang wrote: +1 Nick work! On Mon, Feb 22, 2016 at 10:27 AM, Ryan Hallisey mailto:[email protected]>> wrote: +1. Nice work Angus! -Ryan > On Feb 19, 2016, at 11:51 PM, Michał Jastrzębski mailto:[email protected]>> wrote: > > +1 on co

Re: [openstack-dev] [swift] Account ACL with keystone auth

Account ACL in Swift is not supported with keystoneauth. It is not described in the keystone auth section of [1]. You can probably achieve similar by assigning the appropriate roles to users in keystone. [1] http://docs.openstack.org/developer/swift/overview_auth.html Alistair From: Sampath,

Re: [openstack-dev] [stable][i18n] What is the backport policy on i18n changes?

Thierry Carrez wrote: Matt Riedemann wrote: I don't think we have an official policy for stable backports with respect to translatable string changes. I'm looking at a release request for ironic-inspector on stable/liberty [1] and one of the changes in that has translatable string changes to

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 fully implements wha

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 because our resources are not unlimited. I

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 world where there are multiple scheduler Nova

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 tw

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, it’s a bug to fix (and

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 on

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 > mailto:[email protected]>> > wrote: > > Spent some time talking to Sean about this on Friday afternoon and > bounced back and forth between the two options. At first, /v3 made > th

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 specif

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/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 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 con

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 head

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 thank everyone that I re

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) t-shirts are always fun

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 ne

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] [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 `novaclient.v2.client.Cli

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

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

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]

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 wrote: > Tha

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

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 f

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 imp

[openstack-dev] [Smaug]- IRC Meeting tomorrow (02/23) - 1400 UTC

Hi All, We will hold our bi-weekly IRC meeting tomorrow (Tuesday, 02/23) at 1400 UTC in #openstack-meeting Please review the proposed meeting agenda here: https://wiki.openstack.org/wiki/Meetings/smaug Please feel free to add to the agenda any subject you would like to discuss. Thanks, Eran ___

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 don't

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

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 rolling

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 some

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 head

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 >> the much harder job

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 sho

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

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. I guess we could giv

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 20:00. > > Heat, Horizon, and Oct

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" wrote: > >>

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

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

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 single provider network s

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: [email protected] Subject:  Re: [openstack-dev] [all] [tc] "No Open Core" in 2016 > On 02/18/2016 09:05 PM, Cody A.W. Somervil

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] 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 mailto:[email protected]>> 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 t

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: * nova-network flat DHCP * nova-network

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, >> >> TL;DR: Let's split the events, starting after Barcel

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 Barcelona. >> >> >> This proposal

[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 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 OpenStack Design Summits an int

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

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

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

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. >> >> >> This proposal s

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 a

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 ha

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 > essential. This is why we made t

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

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 g

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, starting after Barcelona. >> This proposal sou

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 fro

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 giv

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 proc

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 >>> thoroughly. >>> >>> [1] https://review.ope

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 a

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 events, starting after Barcel

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 Grenade multinode more thoroughly. [1] https://review.opensta

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 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 it's been to get the off

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 blocking issue has been identified, I filed project-config >> change [1] to enable us to

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

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 b

[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: https://pypi.python.org/pypi/oslo.conte

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

[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: https://pypi.python.org/pypi/osl

[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: https://pypi.pyth

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

[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.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: https://pypi.python.org/pypi/oslo.servi

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 they do, > they can e

[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: https://pypi.python.org/pypi

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

[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: https://pypi.python.org/pypi/oslo.messagin

  1   2   >