Re: [openstack-dev] [gate] RFC dropping largeops tests

makes sense to me. thanks for concise update and tracking this. On 10/02/2016 7:59 AM, Davanum Srinivas wrote: > +1 from me > > On Wed, Feb 10, 2016 at 7:56 AM, Jay Pipes wrote: >> On 02/10/2016 07:33 AM, Sean Dague wrote: >>> >>> The largeops tests at this point are mostly

[openstack-dev] [Neutron] Distributed Multicast and IGMP Support in Dragonflow

Hello, We're in the process of adding IGMP and multicast support to Dragonflow[1]. The added feature will route multicast packets only to relevant and registered VMs, compute nodes, and handle IGMP packets. This feature has some configuration parameters for subnets and router interfaces. Some

[openstack-dev] [Manila] HDFS CI broken

The gate-manila-tempest-dsvm-hdfs jenkins job has been failing for a long time now. It appears to be a config issue that's probably not hard to fix, but nobody is actively maintaining this code. Since it's a waste of resources to continue running this broken job, I plan to disable it, and if

[openstack-dev] [release] removing python 2.6 classifiers from package metadata

We stopped running tests under python 2.6 a while back, and I submitted a bunch of patches to projects that still had the python package classifier indicating support for python 2.6. Most of those merged, but quite a few are still open [1]. Please take a look at the list and if you find any for

Re: [openstack-dev] [Neutron] Distributed Multicast and IGMP Support in Dragonflow

This is a work we are doing in Dragonflow and is relatively simple to implement leveraging Dragonflow current infrastructure and reactive local controller. This will significantly reduce duplicating packets for IGMP aware VMs. and hence reduce multicast load. We would love to help and bring this

Re: [openstack-dev] [gate] RFC dropping largeops tests

Lots of questions, I'm sorry. Are you planning to drop them indefinitely or is it temporary ? Is it to help alleviate the gate from it's current misery ? Why were these tests introduced in the first place ? To find issues or bottenecks relative to scale or amount of operations ? Was it a request

Re: [openstack-dev] [gate] RFC dropping largeops tests

+1, although I would like to keep them to find scale bottlenecks. Maybe when the new infra-cloud is up (we'll have full control over it, includind hw access), we can pin these tests just to it. Ghe Rivero Quoting Sean Dague (2016-02-10 13:33:44) > The largeops tests at this point are mostly

Re: [openstack-dev] [gate] RFC dropping largeops tests

On 02/10/2016 08:42 AM, David Moreau Simard wrote: > Lots of questions, I'm sorry. > > Are you planning to drop them indefinitely or is it temporary ? Is it to > help alleviate the gate from it's current misery ? > > Why were these tests introduced in the first place ? To find issues or >

Re: [openstack-dev] [gate] RFC dropping largeops tests

On 10/02/16 07:33 -0500, Sean Dague wrote: The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were

[openstack-dev] [release][release] reno 1.5.0 release

We are delighted to announce the release of: reno 1.5.0: RElease NOtes manager With source available at: http://git.openstack.org/cgit/openstack/reno With package available at: https://pypi.python.org/pypi/reno Please report issues through launchpad:

Re: [openstack-dev] [kolla] Make "central logging" optional

On Fri, Feb 5, 2016 at 4:46 PM, Eric LEMOINE wrote: > Hi Kolla devs > > The other day inc0 said that we would like "central logging" to be > optional in Mitaka, and still use Rsyslog and keep the current > behavior if "central logging" is disabled. > > I would like to

Re: [openstack-dev] [gate] RFC dropping largeops tests

Sean Dague wrote: The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were very

[openstack-dev] [Openstack][Neutron][Monasca]

Hi, I'm doing a university project in OpenStack. The aim is to monitor virtual routers per tenant with Monasca(which according to my knowledge hasn't been implemented yet). The initial features would include monitoring of in/out traffic per interface. I'm writing a plugin in Monasca for that

Re: [openstack-dev] [mistral][stable] Inappropriate changes backported to stable/liberty

On 1/29/2016 12:08 AM, Renat Akhmerov wrote: On 28 Jan 2016, at 17:40, Matt Riedemann wrote: With regards to the trove 'plugin' stuff, it adds a new dependency on python-troveclient which was not in sahara 1.0.0 in liberty GA, so IMO it's not valid to release

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

Excerpts from Thierry Carrez's message of 2016-02-10 08:35:19 -0800: > Chris Dent wrote: > > [...] > > Observing this thread and "the trouble with names"[1] one I get > > concerned that we're trending in the direction of expecting > > projects/servers/APIs to be done and perfect before they will

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

Chris Dent wrote: [...] Observing this thread and "the trouble with names"[1] one I get concerned that we're trending in the direction of expecting projects/servers/APIs to be done and perfect before they will ever be OpenStack. This, of course, runs entirely contrary to the spirit of open

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

It changes mostly nothing for case of furious plugin development when big parts of code changed from one release to another. You will have 6 different deployment_tasks directories and 30 a little bit different files in root directory of plugin. Also you forgot about repositories directory (+6 at

Re: [openstack-dev] [Fuel] CentOS bootstrap image retirement

Colleagues, Centos bootstrap image (that we used to build together with the ISO) code has been removed from fuel-main. Now the only available option is the Ubuntu based bootstrap image that is built on the master node in run time. >From this moment we are ready to get rid of building Fuel

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

Ihar Hrachyshka wrote: > UPD: seems like enforcing instance mtu to 1400 indeed makes us pass forward > into tempest: > > http://logs.openstack.org/59/265759/3/experimental/gate-grenade-dsvm-neutron-multinode/a167a59/console.html > > And there are only three failures there: > >

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

Sean M. Collins wrote: Ihar Hrachyshka wrote: UPD: seems like enforcing instance mtu to 1400 indeed makes us pass forward into tempest: http://logs.openstack.org/59/265759/3/experimental/gate-grenade-dsvm-neutron-multinode/a167a59/console.html And there are only three

Re: [openstack-dev] [gate] RFC dropping largeops tests

Excerpts from Sean Dague's message of 2016-02-10 04:33:44 -0800: > The largeops tests at this point are mostly finding out that some of our > new cloud providers are slow - http://tinyurl.com/j5u4nf5 > > This is fundamentally a performance test, with timings having been tuned > to pass 98% of the

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

Ihar Hrachyshka wrote: > Actually, we already have 1450 for network_device_mtu for the job since: > > https://review.openstack.org/#/c/267847/4/devstack-vm-gate.sh > Ah! Forgot about that one. Cool. > Also, I added some interface state dump for worlddump, and here is how the > main node

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

On Wed, Feb 10, 2016 at 4:57 PM, 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

Re: [openstack-dev] [Manila] ALLOWED_EXTRA_MISSING is cover.sh

Hello, John Note, that digit "4" defines amount of "python code blocks", not "python code lines". So, you can have uncovered some log message that consists of 100 lines. But it will be counted as just 1. Who "we" have requirement that new drivers have 90% unit test coverage? And, Manila CI

[openstack-dev] [Manila] ALLOWED_EXTRA_MISSING is cover.sh

Hi, I noticed that the coverage script is enforcing a hard limit of 4 on the number of extra missing lines introduced. We have a requirement that new drivers have 90% unit test coverage, which the ceph driver meets[1], but it's tripping up on that absolute 4 line limit. What do folks think

Re: [openstack-dev] [gate] RFC dropping largeops tests

On 10/02/16 18:48, "Clint Byrum" wrote: >Excerpts from Sean Dague's message of 2016-02-10 04:33:44 -0800: >> The largeops tests at this point are mostly finding out that some of our >> new cloud providers are slow - http://tinyurl.com/j5u4nf5 >> >> This is fundamentally a

[openstack-dev] [Openstack][Neutron][Monasca]

Hi, I'm doing a university project in OpenStack. The aim is to monitor virtual routers per tenant with Monasca(which according to my knowledge hasn't been implemented yet). The initial features would include monitoring of in/out traffic per interface. I'm writing a plugin in Monasca for that

Re: [openstack-dev] [Manila] ALLOWED_EXTRA_MISSING is cover.sh

Hi, John. This is but one reason the coverage job doesn¹t vote; it has other known issues. It is primarily a convenience tool that lets core reviewers know if they should look more deeply into unit test coverage. For a new driver such as yours, I typically pull the code and check coverage for

[openstack-dev] [devstack] dropping KEYSTONE_CATALOG_BACKEND - plus update your devstack plugins

Devstack has some half baked support for keystone templated service catalog. In an effort to clean up parts of devstack, we're dropping that - https://review.openstack.org/#/c/278333 However... this unfortunately led to some cargo culting, and everyone's devstack plugin is going to fail if we

[openstack-dev] [Neutron] [FwaaS] Meeting occurred early today by accident

Hi, I accidentally ran the meeting early, due to not having re-downloaded a fresh iCal export. So I had the wrong time. For background: https://github.com/openstack-infra/yaml2ical/commit/4def663a8d5259962d5c2239266ebfaa19082bf6 So anyway, please ensure that your calendar is updated with a

[openstack-dev] [infra][keystone][kolla][bandit] linters jobs

Hi, the pep8 target is our usual target to include style and lint checks and thus is used besides pep8 also for doc8, bashate, bandit, etc as documented in the PTI (=Python Test Interface, http://governance.openstack.org/reference/cti/python_cti.html). We've had some discussions to introduce a

Re: [openstack-dev] [neutron] - please review the neutron security guide

On Tue, Feb 9, 2016 at 1:21 PM, Kevin Benton wrote: > If you see any issues, either propose a patch directly or file a bug against > https://bugs.launchpad.net/openstack-manuals/+filebug with the tag > 'seg-guide' Did you want 'sec-guide'? That would seem more intuitive to me.

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

On 10/02/2016 11:35 AM, Thierry Carrez wrote: > Chris Dent wrote: >> [...] >> Observing this thread and "the trouble with names"[1] one I get >> concerned that we're trending in the direction of expecting >> projects/servers/APIs to be done and perfect before they will ever >> be OpenStack.

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

On 10/02/16 21:53, "gordon chung" wrote: > > >On 10/02/2016 11:35 AM, Thierry Carrez wrote: >> Chris Dent wrote: >>> [...] >>> Observing this thread and "the trouble with names"[1] one I get >>> concerned that we're trending in the direction of expecting >>> projects/servers/APIs

Re: [openstack-dev] [all] RFC - service naming registry under API-WG

On 02/04/2016 06:38 AM, Sean Dague wrote: > 2) Have a registry of "common" names. > > Upside, we can safely use common names everywhere and not fear collision > down the road. > > Downside, yet another contention point. > > A registry would clearly be under TC administration, though all the >

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

On Mon, Feb 8, 2016 at 9:40 AM, Assaf Muller wrote: > As for DVR, I'm searching for someone to pick up the gauntlet and > contribute some L3 fullstack tests. I'd be more than happy to review > it! I even have an abandoned patch that gets the ball rolling (The > idea is to test

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/05/2016 01:16 PM, Sean Dague wrote: > Whether or not it is, I'm not sure how it is part of a Ubiquitous > Open Source Cloud Platform. Because it only enables the use of > commerical services. > > It's fine that it's open source software. I

Re: [openstack-dev] [neutron] - please review the neutron security guide

Yes, sorry. On Feb 10, 2016 12:52, "Carl Baldwin" wrote: > On Tue, Feb 9, 2016 at 1:21 PM, Kevin Benton wrote: > > If you see any issues, either propose a patch directly or file a bug > against > > https://bugs.launchpad.net/openstack-manuals/+filebug with

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/05/2016 01:27 PM, Mike Perez wrote: >>> So while Poppy may not fully qualify for the open core label, >>> it still fails some of the tests that we want to see, such as a >>> usable open source implementation. >> From a QA perspective in

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

There's two main types of services in openstack. Those that are a multitenant aware implementation of some kind of data plane protocol with an "openstack" api. Swift/radosgw, Zaqar, MagnetoDB, etc. I think we can ignore these in this discussion. Then there's what I consider the more "Operating

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

On Tue, Feb 9, 2016 at 3:23 PM, Ildikó Váncsa wrote: > Hi Walt, > > > -Original Message- > > From: Walter A. Boring IV [mailto:walter.bor...@hpe.com] > > Sent: February 09, 2016 23:15 > > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev]

Re: [openstack-dev] [all] RFC - service naming registry under API-WG

On 02/10/2016 03:03 PM, Sean Dague wrote: On 02/04/2016 06:38 AM, Sean Dague wrote: 2) Have a registry of "common" names. Upside, we can safely use common names everywhere and not fear collision down the road. Downside, yet another contention point. A registry would clearly be under TC

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

+1 to Stas, supplanting VCS branches with code duplication is a path to madness and despair. The dubious benefits of a cross-release backwards compatible plugin binary are not worth the code and infra technical debt that such approach would accrue over time. On Wed, Feb 10, 2016 at 07:36:30PM

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

On Wed, Feb 10, 2016 at 03:30:42PM -0700, John Griffith wrote: > On Tue, Feb 9, 2016 at 3:23 PM, Ildikó Váncsa > wrote: > > > > ​This may still be in fact the easiest way to handle this. The only other > thing I am still somewhat torn on here is that maybe Nova

Re: [openstack-dev] Use of restricted and multiverse in the gate

On 2016-02-09 01:32:12 +0800 (+0800), Thomas Goirand wrote: > While it is a good idea to enhance the current Ubuntu image, at the same > time, I'd like to draw your attention that we need review for adding the > Debian image too: > https://review.openstack.org/#/c/264726 > > Igor Belikov did an

[openstack-dev] [magnum][heat] Bug 1544227

Hi Heat team, As mentioned in IRC, magnum gate broke with bug 1544227 . Rabi submitted on a fix (https://review.openstack.org/#/c/278576/), but it doesn't seem to be enough to unlock the broken gate. In particular, it seems templates with SoftwareDeploymentGroup resource failed to complete (I

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

On 10/02/16 18:05, James Slagle wrote: On Wed, Feb 10, 2016 at 4:57 PM, 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

[openstack-dev] All hail the new per-region pypi, wheel and apt mirrors

Hey everybody, tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and APT repos with additional wheel repos containing pre-built wheels for all the modules in global-requirements We've just rolled out a new change that you should mostly never notice - except that jobs

[openstack-dev] [infra] [trove] gate jobs failing with ovh apt mirrors

I started noticing more of the Trove gate jobs failing in the last 24 hours and I think i've tracked it down to this mirror specifically. http://mirror.bhs1.ovh.openstack.org/ubuntu/pool/main/p/ It looks like its missing the python-software-properties package and causing our gate job to fail. I

Re: [openstack-dev] [all] RFC - service naming registry under API-WG

Sean Dague wrote: [...] 3) This be a dedicated repository 'openstack/service-registry'. The API WG will have votes on it (I would also suggest the folks that have been working on Service Catalog TNG - myself, Anne Gentle, Brant Knudson, and Chris Dent be added to this). The actual registry will

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

On Wed, Feb 10, 2016 at 5:12 PM, Fox, Kevin M wrote: > But the issue is, when told to detach, some of the drivers do bad things. > then, is it the driver's issue to refcount to fix the issue, or is it > nova's to refcount so that it doesn't call the release before all users

Re: [openstack-dev] All hail the new per-region pypi, wheel and apt mirrors

On 2016-02-11 14:41:03 +1100 (+1100), Tony Breeds wrote: [...] > Okay We'll need to think about that one as the contrainst in > stable/kilo can be bogus, sometime we have a version in contraints > that isn't valid compared to g-r [...] Oh, right since there's an upper-constraints.txt in

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

I think Sean and John are in the right direction. Nova and Cinder need to be more decoupled in the area of volume attachments. I think some of the mess here is due to different Cinder backend behavior - with some Cinder backends you actually attach volumes to a host (e.g., FC, iSCSI), with some

Re: [openstack-dev] [magnum][heat] Bug 1544227

Hi, We did some analysis of the issue you are facing. One of the issues from heat side is, we convert None(singleton) resource references to 'None'(string) and the translation logic is not ignoring them. Though we don't apply translation rules to resource references[1].We don't see this issue

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

I agree with Stas, one rpm - one version. But plugin builder allows to specify several releases as compatible. The deployment tasks and repositories can be specified per release, at the same time the deployment graph is one for all releases. Currently it looks like half-implemented feature.

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

On 11/02/16 00:33, "gordon chung" wrote: > > >On 10/02/2016 4:28 PM, Tim Bell wrote: >> >> On 10/02/16 21:53, "gordon chung" wrote: >> >>> apologies if this was asked somewhere else in thread, but should we try >>> to define "production" scale or can we even? based

Re: [openstack-dev] All hail the new per-region pypi, wheel and apt mirrors

On Wed, Feb 10, 2016 at 07:07:22PM -0800, Clark Boylan wrote: > On Wed, Feb 10, 2016, at 06:02 PM, Tony Breeds wrote: > > On Wed, Feb 10, 2016 at 06:45:25PM -0600, Monty Taylor wrote: > > > Hey everybody, > > > > > > tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and > > >

[openstack-dev] [fuel] Supporting multiple Openstack versions

Right now master (targeting 9.0) is still deploying liberty and there is active work going on to support both Kilo and Mitaka. On the review queue are changes that would make fuel-library in-compatible with the prior (liberty) openstack release. However I think if we extend a little bit of effort

Re: [openstack-dev] All hail the new per-region pypi, wheel and apt mirrors

On Thu, Feb 11, 2016 at 04:46:39AM +, Jeremy Stanley wrote: > On 2016-02-11 14:41:03 +1100 (+1100), Tony Breeds wrote: > [...] > > Okay We'll need to think about that one as the contrainst in > > stable/kilo can be bogus, sometime we have a version in contraints > > that isn't valid compared

Re: [openstack-dev] [nova] nova gate blocked on eventlet release

On Tue, 9 Feb 2016, Chris Dent wrote: eventlet 0.18.2 has broken the nova unit tests at 'nova.tests.unit.test_wsgi.TestWSGIServerWithSSL' so the gate is blocked. sdague et al are working on it. Please hold off approving patches in nova until they get it resolved. Just in case it's not

[openstack-dev] [NFV][Telco] Telco Working Group Meeting for February 10th 2016 - CANCELLED

Hi all, Unfortunately today's meeting of the Telco Working Group [1] is canceled, my apologies for the late notice! Thanks, Steve [1] https://wiki.openstack.org/wiki/TelcoWorkingGroup __ OpenStack Development Mailing

Re: [openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?

Folks I think the easiest and the best option here is to boot iPXE or pxelinux with NFS and put master node image onto an NFS mount. This one should work seamlessly. On Wed, Feb 10, 2016 at 1:36 AM, Andrew Woodward wrote: > Unless we hope to gain some insight and

Re: [openstack-dev] [nova] nova gate blocked on eventlet release

On 02/10/2016 05:54 AM, Chris Dent wrote: > On Tue, 9 Feb 2016, Chris Dent wrote: > >> eventlet 0.18.2 has broken the nova unit tests at >> 'nova.tests.unit.test_wsgi.TestWSGIServerWithSSL' so the gate is >> blocked. >> >> sdague et al are working on it. Please hold off approving patches >> in

Re: [openstack-dev] [neutron][stable] Request to do stable point releases more often if there are going to be a lot of backports

Matt Riedemann wrote: While reviewing the neutron 7.0.2 stable/liberty point release, I noticed there were a lot of changes since 7.0.1. [1] There are 48 non-merge commits by my count. While there is no rule about how many backports should land before we cut a

Re: [openstack-dev] [Neutron] Being more aggressive with our defaults

> On 09 Feb 2016, at 21:43, Sean M. Collins wrote: > > Kevin Benton wrote: >> I agree with the mtu setting because there isn't much of a downside to >> enabling it. However, the others do have reasons to be disabled. >> >> csum - requires runtime detection of support for a

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

I like the idea of moving it to use the OpenStack infrastructure. On Wed, Feb 10, 2016 at 12:13 AM, Ben Nemec wrote: > On 02/09/2016 08:05 AM, Emilien Macchi wrote: > > Hi, > > > > TripleO is currently using puppet-pacemaker [1] which is a module hosted > > & managed by

[openstack-dev] [oslo] Liberty backward compatibility jobs are bound to fail

Hello. I've noticed once again that job "gate-tempest-dsvm-neutron-src-oslo.concurrency-liberty" is always failing. After looking at the failure I found that the core issue is ContextualVersionConflict [0]. It seems that we have conflicting requirements for oslo.utils here, and we do: in Liberty

[openstack-dev] [gate] RFC dropping largeops tests

The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were very predictable in performance. We're now

[openstack-dev] [nova] removing EC2 related code from nova

Could anyone (and especially Dan, Hans, or Ryan) check my changes? There is no new code ) only removing old code and dependency to 'boto' library. https://review.openstack.org/#/c/266425/ -- Kind regards, Andrey Pavlov. __

[openstack-dev] [Horizon]horizon angular network QoS panel

Hello All, As most of you people knows the 'QoS' feature is added in neutron during liberty release. It will be nice to have this feature in horizon, so I have added a 'network qos' panel for the same in angularJS. It will be very helpful if you people reviewing this patches and helping to

Re: [openstack-dev] [gate] RFC dropping largeops tests

On 02/10/2016 07:33 AM, Sean Dague wrote: The largeops tests at this point are mostly finding out that some of our new cloud providers are slow - http://tinyurl.com/j5u4nf5 This is fundamentally a performance test, with timings having been tuned to pass 98% of the time on two clouds that were

Re: [openstack-dev] [gate] RFC dropping largeops tests

+1 from me On Wed, Feb 10, 2016 at 7:56 AM, Jay Pipes wrote: > On 02/10/2016 07:33 AM, Sean Dague wrote: >> >> The largeops tests at this point are mostly finding out that some of our >> new cloud providers are slow - http://tinyurl.com/j5u4nf5 >> >> This is fundamentally a

[openstack-dev] [Fuel][Plugins] Multi release packages

Fuelers, We are discussing the idea to extend the multi release packages for plugins. Fuel plugin builder (FPB) can create one rpm-package for all supported releases (from metadata.yaml) but we can specify only deployment scripts and repositories per release. Current release definition (in

[openstack-dev] Mock and the stdlib

We've just had a mass gate breakage due to https://review.openstack.org/#/c/268945/ go through, so I thought I'd try to get ahead of anyone trying this again. unittest.mock in the stdlib is not static, it evolves over time. We're currently writing to - and depending on - the unittest.mock version

Re: [openstack-dev] [all][requirements] Why do we use pip install -U as our install_command

On Wed, Feb 10, 2016, at 05:46 PM, Tony Breeds wrote: > Hi All, > I confess up front that I'm pretty green in the is area and there is > a lot > of history that I just don't have. That wont stop me from asking/opening > the > discussion. > > As I ask in $subject: why do we install with

[openstack-dev] [cross_project] Ensuring there is an admin project

We have a fix for one of the most egregious bugs in the history of Keystone: https://bugs.launchpad.net/keystone/+bug/968696 The only problem is, it requires a configuration file change. A deployer needs to set the values: CONF.resource.admin_project_name CONF.resource.admin_domain_name How

Re: [openstack-dev] Mock and the stdlib

I've fast tracked the revert - https://review.openstack.org/#/c/278814/ On Wed, Feb 10, 2016 at 9:38 PM, Robert Collins wrote: > We've just had a mass gate breakage due to > https://review.openstack.org/#/c/268945/ go through, so I thought I'd > try to get ahead of

Re: [openstack-dev] Announcing a simple new tool: git-restack

Jim, I've had this reply queued up for a week now. Sorry for the delay. The problem that I run in to when I work with multiple dependent changes doesn't seem to be covered by your description. For me, the trouble with this workflow comes when there is more than one contributor working on a

Re: [openstack-dev] [fuel] Fuel Community ISO 8.0

Was a bug ever filed for this? It's still not on the landing page On Thu, Feb 4, 2016 at 4:19 AM Ivan Kolodyazhny wrote: > Thanks, Igor. > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Thu, Feb 4, 2016 at 1:21 PM, Igor Belikov > wrote: >

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

On Wed, Feb 10, 2016 at 3:59 PM, Sean McGinnis wrote: > On Wed, Feb 10, 2016 at 03:30:42PM -0700, John Griffith wrote: > > On Tue, Feb 9, 2016 at 3:23 PM, Ildikó Váncsa < > ildiko.van...@ericsson.com> > > wrote: > > > > > > > ​This may still be in fact the easiest way to

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote: > as for c) I think it's a little late to make pluggable ipam default in > Mitaka; I'd rather switch defaults early in the cycle (depending on the > entity of the config) and this one seems serious enough that I'd rather have >

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote: > Technically we can make this as sophisticated and seamless as we want, but > this is a one-off, once it's done the pain goes away, and we won't be doing > another migration like this ever again. So I wouldn't over engineer it.

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

On Wed, Feb 10, 2016 at 11:16:28PM +, Fox, Kevin M wrote: > I think part of the issue is whether to count or not is cinder driver > specific and only cinder knows if it should be done or not. > > But if cinder told nova that particular multiattach endpoints must be > refcounted, that might

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko wrote: > +1 to Stas, supplanting VCS branches with code duplication is a path to > madness and despair. The dubious benefits of a cross-release backwards > compatible plugin binary are not worth the code and infra

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

I think part of the issue is whether to count or not is cinder driver specific and only cinder knows if it should be done or not. But if cinder told nova that particular multiattach endpoints must be refcounted, that might resolve the issue? Thanks, Kevin

Re: [openstack-dev] [Nova][Cinder] Multi-attach, determining when to call os-brick's connector.disconnect_volume

But the issue is, when told to detach, some of the drivers do bad things. then, is it the driver's issue to refcount to fix the issue, or is it nova's to refcount so that it doesn't call the release before all users are done with it? I think solving it in the middle, in cinder's probably not

Re: [openstack-dev] All hail the new per-region pypi, wheel and apt mirrors

On Wed, Feb 10, 2016 at 06:45:25PM -0600, Monty Taylor wrote: > Hey everybody, > > tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and APT > repos with additional wheel repos containing pre-built wheels for all the > modules in global-requirements Woot! I do have a couple of

Re: [openstack-dev] All hail the new per-region pypi, wheel and apt mirrors

w00t! thanks infra team On Wed, Feb 10, 2016 at 7:45 PM, Monty Taylor wrote: > Hey everybody, > > tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and APT > repos with additional wheel repos containing pre-built wheels for all the > modules in

[openstack-dev] [all][requirements] Why do we use pip install -U as our install_command

Hi All, I confess up front that I'm pretty green in the is area and there is a lot of history that I just don't have. That wont stop me from asking/opening the discussion. As I ask in $subject: why do we install with --upgrade in our tox environments? Are there issues this is fixing/hiding?