Re: [openstack-dev] [neutron] Networking-foo projects and release management in the Neutron Stadium

On Tue, Jul 7, 2015 at 8:23 PM, Kyle Mestery wrote: > After some consultation with Doug and Thierry, we've boiled the change I'm > recommending below down to two options: > > 1. independent, ad-hoc backport branches, tag yourself > This makes sense. Standard instructions on tagging/release manag

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

"Mitaka" seems very beautiful name. I am pretty sure it will be really beautiful city as Michael described. Anyway, I will follow any process to pick the name. As long as I know, there has already been active discussion on versioning. Switching from year-based policy to sem versioning. For the re

[openstack-dev] [manila] share dismantling policies

Hi, I'm tossing in the term "dismantling" to indicate the act of making a share less available (deprovision (deny access to) / unmanage / delete it). I find it ambiguous what is to be done with the share's data('s accessibility) upon dismantling. Wrt. the concerns to follow below, I have these qu

Re: [openstack-dev] [Fuel][Plugins] generators support in environment_config.yaml for plugins

Hi Sergiy, Currently it's not possible to use generators in environment_config file, the reason for this is generators get unwrapped before we add plugin's attributes [1]. Could you please create a bug for fuel-python team, we'll address this issue. Thanks, [1] https://github.com/stackforge/fuel

Re: [openstack-dev] [qa][tempest] "kwargs" of service clients for POST/PUT methods

Hi Ghansyham, Thank you for your comment. 2015-07-08 14:07 GMT+09:00 GHANSHYAM MANN : > On Wed, Jul 8, 2015 at 12:27 PM, Ken'ichi Ohmichi > wrote: >> >> By defining all parameters on each method like update_quota_set(), it >> is easy to know what parameters are available from caller/programer >

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

+1 for enabling auto-abandon Sergii, I think the period should be smaller, 2 weeks - 1 month, if patch is important, the author will unabandon it. Thanks, On Wed, Jul 8, 2015 at 3:50 AM, Sergii Golovatiuk wrote: > 3 Months should be a good period. Sometimes, people have one month > vacation th

[openstack-dev] [Fuel] Fuel CI maintenance

Hello everyone, We're starting maintenance of Fuel CI Jenkins master to update SSL certificate, Jenkins version and Jenkins plugins. Expected downtime is under 30 minutes. Services affected: - Fuel CI (https://ci.fuel-infra.org - Jenkins master will be down, Gerrit

[openstack-dev] [manila][devstack] xtrace in devstack plugin

Hi, In manila devstack plugin, the xtrace option is explicitly disabled : https://github.com/openstack/manila/blob/master/devstack/plugin.sh#L26 Any important reason for that ? It can be pretty annoying in a CI context to figure out what happened when things go wrong. I could submit a patch to r

Re: [openstack-dev] [Fuel] Fuel CI maintenance

Maintenance is over, everything went as planned. For retriggering builds affected by maintenance please contact #fuel-devops in irc. Thanks for attention. -- Igor Belikov Fuel DevOps ibeli...@mirantis.com > On 08 Jul 2015, at 11:03, Igor Belikov wrote: > > Hello everyone, > > We're starti

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

Michael Chapman wrote: > I'd like to propose we just use numbers for versioning our software. > Both random words and the year.cadence scheme are irritating in their > own special way. We do use numbers to version our software. OpenStack is made of a lot of components and those need to be versione

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

Long Quan Sha wrote: > I have the same concern as a Chinese, Emperor Meiji will be linked to a > war happened in 1895, also invasion of Taiwan. That is so bad historical > memory for Chinese. Refer to : > https://en.wikipedia.org/wiki/First_Sino-Japanese_War > > I recommend selecting another candi

[openstack-dev] [Security] security specs

Security people, We now have a specs repository for proposing and discussing changes to our projects and documentation. (Thanks to Priti and Andreas for their help with this) I have added the core groups from security-docs, anchor and bandit as cores for the specs project. Let me know if you

[openstack-dev] [nova] why eventlet.monkey_patch(os=False) in nova

we use eventlet in nova code base , at the beginning of each nova service we monkey_patched standard libraries like: import eventlet from nova import debugger if debugger.enabled(): # turn off thread patching to enable the remote debugger eventlet.monkey_patch(os=False, thread=False) el

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

Robert Collins wrote: > We've finally gotten all the kinks worked out and now > upper-constraints proposals should be coming in daily. > > *** These are timely and important: without them, no new releases of > *anything* are consumed. *** > > https://review.openstack.org/#/c/199353/ is an example

Re: [openstack-dev] [requirements] separating the code and data in openstack/requirements

Robert Collins wrote: > I wanted to see what folk thought about moving the requirements > management code (update.py etc etc) to a branchless model. > > e.g.: > openstack/requirements > - global-requirements.txt > - upper-constraints.txt > - README.rst > - nothing else. Not even a setup.py

[openstack-dev] [manila][devstack] xtrace in devstack plugin

Oups, forgot the [openstack-dev] in the subject. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mai

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

> > I just wonder why nobody raised issues with the name while it was on the > proposed names wiki page, while it was on the ballot, or while it was > under final consideration. We've known that "Meiji" was an option for > one month, and that it was #3 in the candidate names for more than 2 > weeks

[openstack-dev] [Fuel] Separate repo for Fuel Agent

Dear colleagues, I am going to move Fuel Agent into a separate git repository. The thing is that we have quite a few review requests to fuel-web with changes for Fuel Agent. The new repository is going to look like this https://github.com/kozhukalov/fuel-agent i.e. there is no additional sub-direc

Re: [openstack-dev] Segmentation Fault in nova-compute service on ARM platform.

I suggest you verify your platform bottom up. In this case make sure the virtualization layer works before integrating openstack. Perhaps there is a test suite for libvirt or something that you could try. /Hans On 2015-07-07 14:55, Pradeep kumar wrote: Ohk sean I am Using a platform with low co

Re: [openstack-dev] [Fuel] Separate repo for Fuel Agent

There were some questions from Alexandra Fedorova about independent release cycle. >according to the configuration [1] Infra team won't be able to do >branching or any kind of release management for new repository. >Could you please clarify, do we plan to version new repository the >same way as w

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

+1 On Wed, Jul 8, 2015 at 10:44 AM, Evgeniy L wrote: > +1 for enabling auto-abandon > > Sergii, I think the period should be smaller, 2 weeks - 1 month, > if patch is important, the author will unabandon it. > > Thanks, > > On Wed, Jul 8, 2015 at 3:50 AM, Sergii Golovatiuk < > sgolovat...@mirant

[openstack-dev] [CI] How to set a proxy for zuul.

Hi all, I'm now installing constructing CI system following this document: https://github.com/rasselin/os-ext-testing When running zuul, I got this error: 2015-07-07 13:44:09,035 ERROR gerrit.GerritWatcher: Exception on ssh event stream: Traceback (most recent call last): File "/usr/local/

Re: [openstack-dev] [CI] How to set a proxy for zuul.

So as per my understanding this is happening after CI master VM installation. On Wed, Jul 8, 2015 at 3:26 PM, Tang Chen wrote: > Hi all, > > I'm now installing constructing CI system following this document: > > https://github.com/rasselin/os-ext-testing > > When running zuul, I got this error:

[openstack-dev] [kolla] Note on standard-start blueprint

All, If you are helping on this bp, can you please remember to check if the KOLLA_BOOTSTRAP section is needed when updating start.sh. I believe this needs to be added around any operation that is not idempotent, usually crux operations and db_sync. See docker/common/glance/glance-api/start.s

Re: [openstack-dev] Thoughts on ReleaseNoteImpact git commit message tag

Matt Riedemann wrote: > [...] > So we kicked around the idea of a ReleaseNoteImpact tag so that we can > search for those at the end of the release in addition to UpgradeImpact. I like the idea -- could be a commit message tag or waiting for the wiki update to approve (as Dan suggested), I think b

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

+1 for one month. On Wed, Jul 8, 2015 at 12:54 PM, Vladimir Kuklin wrote: > +1 > > On Wed, Jul 8, 2015 at 10:44 AM, Evgeniy L wrote: > >> +1 for enabling auto-abandon >> >> Sergii, I think the period should be smaller, 2 weeks - 1 month, >> if patch is important, the author will unabandon it. >

Re: [openstack-dev] [requirements] separating the code and data in openstack/requirements

On 07/07/2015 07:36 PM, Robert Collins wrote: > I wanted to see what folk thought about moving the requirements > management code (update.py etc etc) to a branchless model. > > e.g.: > openstack/requirements > - global-requirements.txt > - upper-constraints.txt > - README.rst > - nothing e

Re: [openstack-dev] [Neutron] Linux Bridge CI status report

Nice job all! Really awesome. I just approved 195653, so it will show up in the check queue non voting shortly. -Sean On 07/07/2015 10:01 PM, Sean M. Collins wrote: > Hi, > > At the risk of jinxing it, I'd like to report that with the merge of a > couple patches to fix race conditions[1]

Re: [openstack-dev] Thoughts on ReleaseNoteImpact git commit message tag

Putting release notes in the git repo so that they simply will get merged along with the corresponding code seems like a no-brainer. What am I missing? Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.o

[openstack-dev] [Security][Anchor] Proposing Stanislaw Pitucha as Anchor Core Developer

All, Stan has been an active developer on Anchor for a long time, he wrote much of the second iteration code before taking a break and travelling the world. He's back now and contributing large amounts of code to the project as well as carrying out multiple reviews and I think it's only fair th

[openstack-dev] [nova] disk I/O perfomance

Hello, all. We have measured disk I/O performance on openstack virtual machines with aid of FIO tool. We've tested performance on root dist drive device, test consists of write operationby 4kb blocks to file with size 90Gb (prefilled in advance). We use qcow2 image for vm, ephemeral drive a

[openstack-dev] [murano] [congress] Congress needs to fetch environments from all tenants.

Hi all, I started implement bp [1]. Problem is that congress needs data about environments from all tenants but murano API lists only environments of user's current tenant. We decided to ipmplement it similarly like listing servers in nova where is query parameter all_tenants=true for that (u

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

Given this is _inactivity_ timeout, 2 weeks seem more than enough. Mind that the discussion without any patch sets incoming counts against this limit as well. And basically, if you go on a lenghty vacation, you better finish with all your CRs before that. During that time it's likely that changes

[openstack-dev] [ceilometer] virtual mid-cycle tomorrow (9th) and Friday (10th)

The ceilometer mid-cycle is virtual and starts tomorrow (Thursday 9th of July) at 0700 UTC. The topical agenda is here: https://wiki.openstack.org/wiki/Meetings/Ceilometer/Liberty_Virtual_Mid-Cycle and the daily schedule is here: https://www.google.com/calendar/embed?src=cXZqcTY2ZXJj

Re: [openstack-dev] [murano] [congress] Congress needs to fetch environments from all tenants.

1) This does raise a security concern. We can however cover it with a separate policy-based permission, that would check if a user can view all tenants. nova seem to do so, see:  https://github.com/openstack/nova/blob/4209d0140774adf3e162b7bde3cbd6b417065dd5/etc/nova/policy.json#L13 2) Will give

Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules

All, I went ahead and wrote the temp module that will fill the gaps that the GPLv3 modules will eventually solve. It appears that upstream Shade still doesn't have merge the capability to create roles, even though mordred has the reviews up. This means even if we solve the licensing issue, we will

[openstack-dev] [murano][yaql] yaql 0.2.7 released

Hi folks, A bugfixing release of yaql 0.2.x - v0.2.7 - has been released. It fixes the compatibility with ply 3.6 (which has been pinned to 3.6 in upper-constraints [1]) and returns yaql CLI utility back in place (it was missing in 0.2.6 for some weird reason), thus closing bug 1463040 ([2]) As

[openstack-dev] [Tricircle]Weekly Meeting 2015.07.08

Hi Team, We didn't have meeting last week due to work schedule, let's resume the weekly meeting today. The agenda is to discuss the tricircle design google doc listed under the BP https://review.openstack.org/#/c/196564/ -- Zhipeng (Howard) Huang Standard Engineer IT Standard & Patent/IT Proo

Re: [openstack-dev] [grenade] future direction on partial upgrade support

On 07/06/2015 09:31 PM, Anita Kuno wrote: > On 07/06/2015 09:02 PM, Armando M. wrote: >> Thanks Sean, comments inline. >> >> On 6 July 2015 at 16:58, Sean M. Collins wrote: >> >>> I'd also like to chime in - we've had some discussions on -infra today >>> about the partial upgrade issue, and collec

[openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Hello, folks! Somehow it happened that we have 2 different kinds of regions: the service regions inside Keystone catalog and AVAILABLE_REGIONS setting inside Horizon, yet use the same name 'regions' for both of them. That creates a lot of confusion when solving some region-related issues at the Ho

Re: [openstack-dev] Should project name be uppercase or lowercase?

On 07/07/2015 10:36 PM, Anne Gentle wrote: > How do you think which should we use uppercase vs lowercase for > representing project names? > > > I'll be patching the governance repo with some guidelines we have been > using to make them official. The projects.yaml file is the reference >

[openstack-dev] [tc] [all] thinking additional tags

Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria that we used to use for integration requirements". I strongly agree with that perspective. A few ideas I was thinkin

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Timur Sufiev wrote on 07/08/2015 07:50:49 AM: > From: Timur Sufiev > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 07/08/2015 07:53 AM > Subject: [openstack-dev] [horizon] [keystone] [docs] Two kinds of > 'region' entity: finding better names for them > > Hello, f

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

On 07/08/2015 08:50 AM, Timur Sufiev wrote: Hello, folks! Somehow it happened that we have 2 different kinds of regions: the service regions inside Keystone catalog and AVAILABLE_REGIONS setting inside Horizon, yet use the same name 'regions' for both of them. That creates a lot of confusion whe

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

Excerpts from Thierry Carrez's message of 2015-07-08 11:01:39 +0200: > Robert Collins wrote: > > We've finally gotten all the kinks worked out and now > > upper-constraints proposals should be coming in daily. > > > > *** These are timely and important: without them, no new releases of > > *anythi

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

I have dealt with the confusion caused by this issue on multiple occasions and would love to see AVAILABLE_REGIONS changed to something like AVAILABLE_KEYSTONE_ENDPOINTS which would be much clearer. Justin On 7/8/2015 8:10 AM, Douglas Fish wrote: Timur Sufiev wrote on 07/08/2015 07:50:49 AM:

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

In one case horizon uses region to refer to completelely seperate clouds. +1 for coming up with a different term for that concept. Thanks, Kevin From: Jay Pipes Sent: Wednesday, July 08, 2015 6:35:22 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstac

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Hi, Jay! As Doug said, Horizon regions are just different Keystone endpoints that Horizon could use to authorize against (and retrieve the whole catalog from any of them afterwards). Another example of how complicated things could be: imagine that Horizon config has two Keystone endpoints inside

Re: [openstack-dev] [swift] Stategy to port Swift to Python 3

Hi, On 07/07/2015 19:42, John Dickinson wrote: For the dependencies (pyeclib), we'll get those as we can. The first priority is getting the Swift code, which we control, ... I used the hack suggested by Cyril Roelandt: patch pyeclib in tox. With this hack, tox -e py34 now works even if pyecl

Re: [openstack-dev] [murano] [congress] Congress needs to fetch environments from all tenants.

There are two things to remember here. 1) When you configure the Congress datasource driver to talk to Murano, you choose which user rights Congress should use. If you need to get all of the tenants data, you want to choose an admin user for the Murano driver. Personally I always use admin users

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

Hi, My 2 cents on it. Let's abandon patch: * if there's at least one -1, and there were no activity for 2 weeks * if it has positive feedback, bat there were no activity for 4 weeks Thanks, Igor On Wed, Jul 8, 2015 at 2:33 PM, Oleg Gelbukh wrote: > Given this is _inactivity_ timeout, 2 weeks

[openstack-dev] [ceilometer] July 9 meeting cancelled

hi, just a reminder, since we're running our virtual meetup tomorrow and Friday[1], the regularly scheduled meeting will be cancelled‎. all are welcomed. jasonamyers has offered snacks -- you just need to fly to Raleigh. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/06891

Re: [openstack-dev] [openstack-community] OpenStack Meiji (明治) - Our next release name has been selected

On 07/08/2015 01:51 AM, Tristan Goode wrote: > There's an easy solution to this and a great first step of the community to > improve diversity by inclusion. Names will always offend someone somewhere > on the planet, and this time we've made a cracker by offending an entire > country. (Though it mi

Re: [openstack-dev] [horizon] [keystone] [docs] Two kinds of 'region' entity: finding better names for them

Got it, thanks for the excellent explanation, Timur! Yeah, I think renaming to AVAILABLE_KEYSTONE_ENDPOINTS would be a good solution. Best, -jay On 07/08/2015 09:53 AM, Timur Sufiev wrote: Hi, Jay! As Doug said, Horizon regions are just different Keystone endpoints that Horizon could use to a

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 2015-07-08 09:44:59 -0400 (-0400), Doug Hellmann wrote: > Do the updates only look for third-party packages, or are they going to > be picking up releases from within the community, too? Do we want > community releases handled separately, since there should be less > discussion of those? Releas

Re: [openstack-dev] [Fuel] python-fuelclient-6.1.2

Alexandra, the versioning scheme was defined in the refactoring blueprint [1]. TL;DR — only x and y are bound to versions of Fuel, z is free for use. The stable/6.1.2 branch is for hiding changes from ISO build system because it does not support different version numbers for different components

Re: [openstack-dev] [openstack-community] OpenStack Meiji (明治) - Our next release name has been selected

On 2015-07-08 10:08:07 -0400 (-0400), Monty Taylor wrote: > On 07/08/2015 01:51 AM, Tristan Goode wrote: [...] > > So let's give up naming things like toys in our play crib, start acting > > like grown ups and using semver or plain old integers. At worst, we might > > have some people see bugs in v

[openstack-dev] Rescinding the M name decision

Hi everyone! In light of issues raised concerning the initially selected name for the M release (Meiji), that name will not be used. It turns out fully open community and fully inclusive collaboration is a hard thing to get right. On the one hand, we do not want to exclude anyone's input or contr

[openstack-dev] [Fuel] Fuel library CI changes due to transition to Kilo

Hi, everyone, let's discuss a bit CI changes required for fuel-library repository as we merge Kilo support and discard support for CentOS 6.5. Current situation We run 6 deployment tests: Three jobs running against Juno-based ISO: master.fuel-library.pkgs.centos.ha_no

[openstack-dev] [Tricircle]Tricircle Weekly Team Meeting 2015.07.08 Roundup

e: Calit2 Building Room 2402 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado Tricircle Weekly Meeting 20150708 chatlog.docx Description: MS-Word 2007 document __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [openstack-community] OpenStack Meiji (明治) - Our next release name has been selected

I do agree with Jeremy. We are being away from the original topic of this thread. I suggest we initiate a separate thread on single mailing list regarding release naming policy. -- Jaesuk Ahn On Wed, Jul 8, 2015 at 11:38 PM Jeremy Stanley wrote: > On 2015-07-08 10:08:07 -0400 (-0400), Monty Tay

Re: [openstack-dev] [Security][Anchor] Proposing Stanislaw Pitucha as Anchor Core Developer

+1 Every single review on the first page of results at https://review.openstack.org/#/q/project:stackforge/anchor,n,z has Stan as owner… From: "Clark, Robert Graham" mailto:robert.cl...@hp.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@list

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

On 07/08/2015 01:50 AM, Michael Micucci wrote: > Dear all, > > #4 was Mitaka (三鷹, meaning "three hawks"), I believe? > > Mitaka is a very beautiful city, if I may say so (I lived there, so I'm > a bit biased :)), with Inokashira Park, a zoo, and many walking trails. > Plus, the Ghibli Museum is

Re: [openstack-dev] [oslo.messaging][zeromq] Next step

>> On 6/12/15, 3:55 PM, "Clint Byrum" wrote: >> >> > >> >> >> > >> >I think you missed "it is not tested in the gate" as a root cause for >> >some of the ambiguity. Anecdotes and bug reports are super important for >> >knowing where to invest next, but a test suite would at least establish a >>

Re: [openstack-dev] [Tricircle]Tricircle Weekly Team Meeting 2015.07.08 Roundup

Hi, Thank you very much for posting the log. I had to leave this meeting earlier. I would love to participate and collaborate on any related item use cases/requirements/design. BR, Irena On Wed, Jul 8, 2015 at 5:49 PM, Zhipeng Huang wrote: > Hi Team, > > Thanks a lot for attending today's meeti

Re: [openstack-dev] [Fuel] Fuel library CI changes due to transition to Kilo

> > Let's set three voting jobs: > > - master.fuel-library.pkgs.UBUNTU.ha_nova_vlan > - master.fuel-library.pkgs.ubuntu.ha_neutron_vlan > - master.fuellib_review_pkgs_master_node > > and one non-voting: > > master.fuel-library.pkgs.centos.ha_NEUTRON_vlan > > All of them based on latest ISO with

[openstack-dev] [Neutron][Nova]Miguel Lavalle to be the Neutron team point of contact for the Nova Cells V2 effort

Hi, This message is to announce that I have volunteered to be the point of contact in the Neutron team for the Nova Cells V2 effort. Regards Miguel Lavalle IRC: mlavalle __ OpenStack Development Mailing List (not for usage q

Re: [openstack-dev] [Fuel] Fuel library CI changes due to transition to Kilo

+1 On Wed, Jul 8, 2015 at 6:32 PM, Sergey Vasilenko wrote: > Let's set three voting jobs: >> >> - master.fuel-library.pkgs.UBUNTU.ha_nova_vlan >> - master.fuel-library.pkgs.ubuntu.ha_neutron_vlan >> - master.fuellib_review_pkgs_master_node >> >> and one non-voting: >> >> master.fuel-library.

Re: [openstack-dev] [nova] bp and/or spec required for new metadata service API version?

On 6 July 2015 at 19:14, Andrew Laski wrote: > On 07/06/15 at 07:37pm, Sylvain Bauza wrote: >> >> Le 06/07/2015 19:22, Matt Riedemann a écrit : >>> >>> Related to this change [1] which adds a new LIBERTY openstack version to >>> the metadata service API, it's pretty trivial but it's akin to microv

Re: [openstack-dev] [Fuel] Fuel library CI changes due to transition to Kilo

Hi, If we plan to make a changes here, lets choose one of ha env with ceph (or cinder, but ceph is preferable) To be sure that we do not miss any data for storage. On Wed, Jul 8, 2015 at 7:03 PM, Vladimir Kuklin wrote: > +1 > > On Wed, Jul 8, 2015 at 6:32 PM, Sergey Vasilenko > wrote: > >> Le

Re: [openstack-dev] [Neutron][Nova]Miguel Lavalle to be the Neutron team point of contact for the Nova Cells V2 effort

Thanks Miguel! On 07/08/2015 11:50 AM, Miguel Lavalle wrote: Hi, This message is to announce that I have volunteered to be the point of contact in the Neutron team for the Nova Cells V2 effort. Regards Miguel Lavalle IRC: mlavalle

Re: [openstack-dev] [Fuel] Fuel library CI changes due to transition to Kilo

+1 On Wed 8 Jul 2015 at 11:13 Tatyana Leontovich wrote: > Hi, > If we plan to make a changes here, lets choose one of ha env with ceph (or > cinder, but ceph is preferable) To be sure that we do not miss any data for > storage. > > > > On Wed, Jul 8, 2015 at 7:03 PM, Vladimir Kuklin > wrote: > >

Re: [openstack-dev] [grenade] future direction on partial upgrade support

On 07/08/2015 08:48 AM, Sean Dague wrote: > On 07/06/2015 09:31 PM, Anita Kuno wrote: >> On 07/06/2015 09:02 PM, Armando M. wrote: >>> Thanks Sean, comments inline. >>> >>> On 6 July 2015 at 16:58, Sean M. Collins wrote: >>> I'd also like to chime in - we've had some discussions on -infra tod

Re: [openstack-dev] [grenade] future direction on partial upgrade support

On 07/08/2015 12:27 PM, Russell Bryant wrote: > On 07/08/2015 08:48 AM, Sean Dague wrote: >> On 07/06/2015 09:31 PM, Anita Kuno wrote: >>> On 07/06/2015 09:02 PM, Armando M. wrote: Thanks Sean, comments inline. On 6 July 2015 at 16:58, Sean M. Collins wrote: > I'd also like

Re: [openstack-dev] [tc] [all] thinking additional tags

On 08/07/15 09:03, Sean Dague wrote: Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria that we used to use for integration requirements". I strongly agree with that

Re: [openstack-dev] Thoughts on ReleaseNoteImpact git commit message tag

Soren Hansen wrote: > Putting release notes in the git repo so that they simply will get > merged along with the corresponding code seems like a no-brainer. What > am I missing? For stable branches it prevents us from just backporting master changes using straight cherry-picks. For example you wa

Re: [openstack-dev] [tc] [all] thinking additional tags

Sean Dague wrote: > Personally, I'm running out of steam on tags for this cycle, but Zane > brought up a good point in the TC meeting yesterday, which was that "it > would be nice to have tags for criteria that we used to use for > integration requirements". I strongly agree with that perspective.

[openstack-dev] sqlalchemy-migrate 0.9.7 released

PyPI: https://pypi.python.org/pypi/sqlalchemy-migrate/0.9.7 Change Log: mriedem@ubuntu:~/git/sqlalchemy-migrate$ git log --oneline --no-merges 0.9.6..0.9.7 050b646 Revert "Revert "uncap pbr and sqla requirements"" dc07f8d Update flake8 related dependencies e4d0e5b Revert "uncap pbr and sqla re

Re: [openstack-dev] [Security][Anchor] Proposing Stanislaw Pitucha as Anchor Core Developer

+1 As a current core I absolutely stand behind this nomination, Stans coding is excellent and he has made huge contributions to this project. Doug -Original Message- From: Finnigan, Jamie Sent: 08 July 2015 16:05 To: OpenStack Development Mailing List (not for usage questions) Subject

Re: [openstack-dev] [grenade] future direction on partial upgrade support

On 07/08/2015 12:35 PM, Sean Dague wrote: > On 07/08/2015 12:27 PM, Russell Bryant wrote: >> On 07/08/2015 08:48 AM, Sean Dague wrote: >>> On 07/06/2015 09:31 PM, Anita Kuno wrote: On 07/06/2015 09:02 PM, Armando M. wrote: > Thanks Sean, comments inline. > > On 6 July 2015 at 16:58

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

On 08/07/15 11:16 -0400, Russell Bryant wrote: On 07/08/2015 01:50 AM, Michael Micucci wrote: Dear all, #4 was Mitaka (三鷹, meaning "three hawks"), I believe? Mitaka is a very beautiful city, if I may say so (I lived there, so I'm a bit biased :)), with Inokashira Park, a zoo, and many walking

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

Excerpts from Thierry Carrez's message of 2015-07-08 01:43:32 -0700: > Long Quan Sha wrote: > > I have the same concern as a Chinese, Emperor Meiji will be linked to a > > war happened in 1895, also invasion of Taiwan. That is so bad historical > > memory for Chinese. Refer to : > > https://en.wiki

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

I tend to agree with this. Sure names are cool and all, but how much time and effort have we collectively spent in determining a name? I see no problem with a release 15, and cutting a 15-1, 15-2, 15-3. A friendly reminder, we only have 13 more releases before we run out of letters anyways. :

Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules

That sounds like option #4, so then I guess we don’t need the TC to evaluate the “legalness” of this approach since it does not trigger GPL contamination. TC apologies for the noise – Sam said option #4 was difficult to do :) Regards -steve From: Sam Yaple mailto:sam...@yaple.net>> Reply-To: "

Re: [openstack-dev] [horizon] Modifying existing dashboards with plugins

The 07/07/2015 11:35, Thai Q Tran wrote: >Right, this was the suggestion I also recommended in IRC. The only issue >here is if/when another plugin attempt to extend from the same panel, then >we'd run into conflicts that would require manual resolution (but I'm not >sure there is an

Re: [openstack-dev] [neutron] Networking-foo projects and release management in the Neutron Stadium

For now, I've modified the patch so everything follows #1. If we "graduate" some things like l2gw and octavia, we can modify them into #2. Thanks for the input! On Tue, Jul 7, 2015 at 10:38 PM, Takashi Yamamoto wrote: > it seems two kinds of sub projects. > one is vendor plugins, for which optio

Re: [openstack-dev] [Neutron] Linux Bridge CI status report

This is great work! I see most of the devstack patches have now merged, and the Neutron ones are merging to. On Wed, Jul 8, 2015 at 5:37 AM, Sean Dague wrote: > Nice job all! Really awesome. I just approved 195653, so it will show up > in the check queue non voting shortly. > > -Sean > >

Re: [openstack-dev] [Neutron][Nova]Miguel Lavalle to be the Neutron team point of contact for the Nova Cells V2 effort

++, thanks for taking on this valuable role Miguel! On Wed, Jul 8, 2015 at 11:20 AM, Jay Pipes wrote: > Thanks Miguel! > > > On 07/08/2015 11:50 AM, Miguel Lavalle wrote: > >> Hi, >> >> This message is to announce that I have volunteered to be the point of >> contact in the Neutron team for the

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

Excerpts from John Dewey's message of 2015-07-08 10:36:25 -0700: > I tend to agree with this. > > Sure names are cool and all, but how much time and effort have we > collectively spent in determining a name? I see no problem with a release > 15, and cutting a 15-1, 15-2, 15-3. > > A friendly r

Re: [openstack-dev] [Neutron] Issue with pymysql

Hi, Another brief update on the matter: Failure rate trends [1] are showing that unstable (w/ multiple API workers + pymysql driver) and stable configurations (w/o) are virtually aligned and I am proposing that it is time to drop the unstable infra configuration [2,3] that allowed the team to tri

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 8 July 2015 at 21:01, Thierry Carrez wrote: > Robert Collins wrote: >> We've finally gotten all the kinks worked out and now >> upper-constraints proposals should be coming in daily. >> >> *** These are timely and important: without them, no new releases of >> *anything* are consumed. *** >> >>

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

Let's keep it at >4 weeks without comment, and Jenkins failed - similar to the script that Kyle Mestery uses for Neutron. In fact, we could actually just use his script ;) https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh -- Sean M. Collins ___

Re: [openstack-dev] [tc] [all] thinking additional tags

On 08/07/15 12:51, Thierry Carrez wrote: Sean Dague wrote: Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria that we used to use for integration requirements". I st

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 07/08/2015 03:49 PM, Robert Collins wrote: > On 8 July 2015 at 21:01, Thierry Carrez wrote: >> Robert Collins wrote: >>> We've finally gotten all the kinks worked out and now >>> upper-constraints proposals should be coming in daily. >>> >>> *** These are timely and important: without them, no

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

On 07/08/2015 04:21 PM, Monty Taylor wrote: > On 07/08/2015 03:49 PM, Robert Collins wrote: >> On 8 July 2015 at 21:01, Thierry Carrez wrote: >>> Robert Collins wrote: We've finally gotten all the kinks worked out and now upper-constraints proposals should be coming in daily. *

Re: [openstack-dev] [Neutron] Issue with pymysql

I agree and I would make the switch as soon as possible. The graphite graph you posted showed that since 6/28 the difference in failure rate is such that isn't even statistically significant. However, spikes in failure rates of the unstable job also suggest that you're starting to chase a moving ta

Re: [openstack-dev] [Neutron] Issue with pymysql

On 8 July 2015 at 14:30, Salvatore Orlando wrote: > I agree and I would make the switch as soon as possible. The graphite > graph you posted showed that since 6/28 the difference in failure rate is > such that isn't even statistically significant. However, spikes in failure > rates of the unstabl

[openstack-dev] [app-catalog] July 9 meeting cancelled

Unless there are any specific agenda items anyone else wishes to discuss tomorrow during the weekly App Catalog IRC meeting, I propose we push this off until next week. Please do speak up here on the mailing list or on the IRC channel (#openstack-app-catalog) if there is anything you would like co

Re: [openstack-dev] [python-openstacksdk] Moratorium on services, features until post-1.0

On Jul 7, 2015, at 11:34 AM, Brian Curtin wrote: > In the interest of moving towards a 1.0 release of OpenStack SDK, > we're going to halt accepting any new resources on existing services, > and any entirely new services. After release, we'll open back up and > both deepen and broaden our support

Re: [openstack-dev] [tc] [all] thinking additional tags

On 09/07/15 04:39, Zane Bitter wrote: On 08/07/15 09:03, Sean Dague wrote: Personally, I'm running out of steam on tags for this cycle, but Zane brought up a good point in the TC meeting yesterday, which was that "it would be nice to have tags for criteria that we used to use for integration req

  1   2   >