Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

On Tue, Mar 1, 2016 at 2:14 PM, Sean Dague wrote: > On 02/29/2016 05:23 PM, Matt Riedemann wrote: > > > > > > On 2/29/2016 2:54 PM, Sean Dague wrote: > >> On 02/29/2016 11:59 AM, Sean Dague wrote: > >>> The nova/hooks.py infrastructure has been with us since early Nova. > It's > >>> currently onl

[openstack-dev] [puppet] adding ovs dpdk agent into neutron

Hi all, we have puppet module for ovs deployments with dpdk support https://github.com/openstack/networking-ovs-dpdk/tree/master/puppet and we would like to adapt it in a way that it can be used within upstream neutron module e.g. to introduce class like this neutron::agents::ml2::ovsdpdk Curren

Re: [openstack-dev] [Horizon] Blueprints for Outreachy internship

On 29/02/16 12:41, Sayali Lunkad wrote: > Hi Matthias, > > Thanks for the links to the blueprints. I in fact did checkout the list > of bps earlier but I found many of them have not been approved yet. I > can give you a list of bps I would like to mentor for, from which we > could perhaps select o

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

On Tuesday, March 1, 2016 7:29 PM, John Garbutt wrote > On 1 March 2016 at 08:34, Cheng, Yingxin wrote: > > Hi, > > > > I have simulated the distributed resource management with the incremental > update model based on Jay's benchmarking framework: > https://github.co

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

Le 02/03/2016 09:15, Cheng, Yingxin a écrit : On Tuesday, March 1, 2016 7:29 PM, John Garbutt wrote On 1 March 2016 at 08:34, Cheng, Yingxin wrote: Hi, I have simulated the distributed resource management with the incremental update model based on Jay's bench

Re: [openstack-dev] [Horizon] Blueprints for Outreachy internship

Hi Sayali, Sorry I missed your original message, and thanks Matthias for responding. Indeed the new Swift UI is currently being merged. Some of those blueprints you list are things I'd like to see once the basic reimplementation is landed. Select-all is already in the new version though (though we

Re: [openstack-dev] FW: [magnum][magnum-ui] Liaisons for I18n

One thing to note. The role of i18n liaison is not to keep it well translated. The main role is in a project side, for example, to encourage i18n related reviews and fixes, or to suggest what kind of coding is recommended from i18n point of view. Akihiro 2016-03-02 12:17 GMT+09:00 Shuu Mutou : >

Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility

Hi, > Merging this code is relatively non-intrusive to core Fuel Library code > as it is merely re-organizing the file structure of the osnailyfacter > module to be compatible with Puppet Master. It looks like super-intrusive to me. Modular manifests are, actually, the core of Fuel Library. And t

[openstack-dev] [nova] Non-Admin user can show deleted instances using changes-since parameter when calling list API

Hi, Nova, While I'm working on add "changes-since" parameter support for python-novaclient "list" CLI. I realized that non-admin can list all deleted instances using "changes-since" parameter. This is reasonable in some level, as delete is an update to instances. But as we have a limitation that

[openstack-dev] [Fuel] [FFE] Component registry improvements

Hi, I would like to request a feature freeze exception for "Component registry improvements" feature [0] It's related only with components and hasn't any impact on other Fuel parts. We have 2 patches [1], [2] which currently on review but blocked with CI issue due separation of fuel-web and fuel-

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

On Tue, Mar 01, 2016 at 01:53:18PM -0500, Rob Crittenden wrote: > Daniel P. Berrange wrote: > > On Mon, Feb 29, 2016 at 12:36:03PM -0700, Rich Megginson wrote: > >> On 02/29/2016 12:19 PM, Chris Friesen wrote: > >>> On 02/29/2016 12:22 PM, Daniel P. Berrange wrote: > >>> > There's three core s

Re: [openstack-dev] [TripleO] core members for tripleo-ui

On 29 February 2016 at 17:32, Ana Krivokapic wrote: > On Mon, Feb 29, 2016 at 4:27 PM, Dan Prince wrote: > > There is a new projects for the ui called tripleo-ui. As most of the > > existing TripleO core members aren't going to be reviewing UI specific > > patches is seems reasonable that we mig

Re: [openstack-dev] [kolla][security] Obtaining the vulnerability:managed tag

Please count me as well. I'd be interesting in joining the team, as well as in introducing SELinux to kolla-mesos and/or helping in introducing SELinux to kolla in general if that will be needed. __ OpenStack Development Ma

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

Vitaly Thanks for bringing this up. Actually the spec has been on review for almost 2 weeks: https://review.openstack.org/#/c/282695/. Essentially, this is not introducing new DSL but replacing the existing one with more powerful extendable language which is being actively developed within OpenSta

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

Sean, I do understand why we have tempest for python-cinderclient now. But my point is: tempest runs more than 200 tests per each cinderclient change request which takes a lot of time. Why can't we just introduce few integration tests which will tests nova<=>python-cinderclient API. Also, Nova i

Re: [openstack-dev] [Openstack-operators] [neutron] network issue with separate subnets under single public-network

Rahul Sharma wrote: Hi All, I am trying to fix a network-issue in our environment and would like to know some suggestions on how I can achieve it. Here is the issue:- I have two subnets(10.10.10.0/25 and 10.10.10.128/26) with separate gateways for each subnet and I expose the whole to en

[openstack-dev] [magnum][heat] spawn a group of nodes on different availability zones

Hi all, I am looking at a way to spawn nodes in different specified availability zones when deploying a cluster with Magnum. Currently Magnum directly uses predefined Heat templates with Heat parameters to handle configuration. I tried to reach my goal by sticking to this model, however I couldn'

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

Hey Dmitry, No offence, but I rather against that exception. We have too many things to do in Mitaka, and moving to CentOS 7.2 means * extra effort from core team * extra effort from qa team Moreover, it might block development by introducing unpredictable regressions. Remember 8.0? So I think i

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

Oh, so there is a spec. I was worried that this patch has "WIP-no-bprint-assigned-yet" string in the commit message, so I thought there is no spec for it. So the commit message should be updated to avoid such confusion. It's really good I've seen this spec. There are plans to overhaul UI data form

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On Wednesday 02 of March 2016 12:24:57 Ivan Kolodyazhny wrote: > Sean, > > I do understand why we have tempest for python-cinderclient now. > > But my point is: tempest runs more than 200 tests per each cinderclient > change request which takes a lot of time. Why can't we just introduce few > int

Re: [openstack-dev] [nova] nova hooks - document & test or deprecate?

On 03/02/2016 03:01 AM, Juan Antonio Osorio wrote: > > > On Tue, Mar 1, 2016 at 2:14 PM, Sean Dague > wrote: > > On 02/29/2016 05:23 PM, Matt Riedemann wrote: > > > > > > On 2/29/2016 2:54 PM, Sean Dague wrote: > >> On 02/29/2016 11:59 AM, Sean Dague w

[openstack-dev] [cinder] Proposal: changes to our current testing process

Hi Team, Here are my thoughts and proposals how to make Cinder testing process better. I won't cover "3rd party CI's" topic here. I will share my opinion about current and feature jobs. Unit-tests - Long-running tests. I hope, everybody will agree that unit-tests must be quite simple and

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

Luigi, >From my point of view, Tempest should verify Cinder for DefCore requirements [1] only. Such integration tests won't be just a re-implementation if a Tempest tests. It will me more extended set of tests for integration between cinderclient and other projects. [1] https://github.com/opens

Re: [openstack-dev] [Fuel] [FFE] FF exception request for SR-IOV

> And we need to write a new patch for: https://blueprints.launchpad.net/fuel/+spec/nailgun-should-serialize-sriov It is on review now: https://review.openstack.org/286704 Complete list of patches on review: https://review.openstack.org/#/q/status:open++branch:master+topic:bp/support-sriov Ale

Re: [openstack-dev] [fuel] Fuel 8.0 is released

Hi any plan support install Openstack controller in CentOS 7.x? On Wed, Mar 2, 2016 at 10:20 AM, Dmitry Borodaenko wrote: > We are proud to announce the release of Fuel 8.0, deployment and > management tool for OpenStack. > > This release initroduces support for OpenStack Liberty, adds a number

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On 03/02/2016 05:24 AM, Ivan Kolodyazhny wrote: > Sean, > > I do understand why we have tempest for python-cinderclient now. > > But my point is: tempest runs more than 200 tests per each cinderclient > change request which takes a lot of time. Why can't we just introduce > few integration test

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

Sean, In such case, can we configure which tests should be run for the python-cinderclient src job? Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 1:45 PM, Sean Dague wrote: > On 03/02/2016 05:24 AM, Ivan Kolodyazhny wrote: > > Sean, > > > > I do understand why we hav

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

Hi Igor, Postponing this till Fuel 10 means we have to elaborate a plan to do such upgrade for Fuel 9 after the release - the underlying system will not get updated on it's own, and the security issues will not close themselves. The problem here is that such upgrade of deployed master node require

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On 03/02/2016 06:58 AM, Ivan Kolodyazhny wrote: > Sean, > > In such case, can we configure which tests should be run for > the python-cinderclient src job? No, there really isn't a mechanism for this because getting it right is quite complicated and error prone. What is the motivation here? Mayb

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Hi Ivan! On Wed, Mar 2, 2016 at 1:25 PM, Ivan Kolodyazhny wrote: > Hi Team, > > Here are my thoughts and proposals how to make Cinder testing process > better. I won't cover "3rd party CI's" topic here. I will share my opinion > about current and feature jobs. > > > Unit-tests > >- Long-runn

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

Sean, I've mentioned above, that current tempest job runs ~1429 tests and only about 10 of them uses cinderclient. It tooks a lot of time without any benefits for cinder, e.g.: tests like tempest.api.network.* verifies Neutron, not python-cinderclient. Regards, Ivan Kolodyazhny, http://blog.e0ne.

[openstack-dev] [Congress] congressclient checks

Hi folks, I checked whether python-congressclient works well or not for M release. Within my QA for the client, it seems to functionally work well for all existing API. Bugs[1][2] I found are only about help messages and output format. So it means there would be no critical bugs for new release.

Re: [openstack-dev] [cinder][all] Integration python-*client tests on gates

On 03/02/2016 07:34 AM, Ivan Kolodyazhny wrote: > Sean, > > I've mentioned above, that current tempest job runs ~1429 tests and only > about 10 of them uses cinderclient. It tooks a lot of time without any > benefits for cinder, e.g.: tests like tempest.api.network.* verifies > Neutron, not python

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

+1 to making the testing process better. It has been discussed that services could/should consider devoting some or all of a release cycle to stability and/or quality. I propose the Cinder team makes improving and fixing the tests and test process a priority for the Newton cycle. Scott D'Angelo

[openstack-dev] [qa] openstack health accounting problem

I noticed in looking at the last 10 failures in the gate view - http://status.openstack.org//openstack-health/#/ that 2 of them were tearDown in test_volume_boot_pattern. However, it looks like these don't count against the test_volume_boot_pattern success rate. Which means the real fail rate of t

Re: [openstack-dev] [Fuel] [FFE] Use packetary for building ISO

Hi Vladimir, Till what date do you want FFE ? Regards, Andrey Maximov Fuel Project Manager On Tue, Mar 1, 2016 at 5:36 PM, Vladimir Kozhukalov < [email protected]> wrote: > Dear colleagues, > > I'd like to request a feature freeze exception for "Use packetary for > building ISO". BP [0]

Re: [openstack-dev] Openstack Cinder - Wishlist

Thank you Yatin! From: yatin kumbhare [mailto:[email protected]] Sent: Tuesday, March 1, 2016 4:43 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Openstack Cinder - Wishlist Hi Ashraf, you can find all such information over launchpad. ht

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

That would be great. The boot from volume test remains one of the top failure scenarios, both in the gate, and for end users. It would be really good to get a handle on why and get that shored up. -Sean On 03/02/2016 08:18 AM, D'Angelo, Scott wrote: > +1 to making the testing process bett

Re: [openstack-dev] [Fuel] [FFE] Use packetary for building ISO

Andrew, I think everything will be ready by Wednesday 03/09/2016. We have just fixed one critical bug in Packetary, now it seems working. Vladimir Kozhukalov On Wed, Mar 2, 2016 at 4:21 PM, Andrew Maksimov wrote: > Hi Vladimir, > > Till what date do you want FFE ? > > Regards, > Andrey Maximov

Re: [openstack-dev] [Fuel][FFE] Use RGW as a default object store instead of Swift

Igor, You are right. I have updated a request - https://review.openstack.org/287195 Thanks. On Tue, Mar 1, 2016 at 6:01 PM, Igor Kalnitsky wrote: > Hey Konstantin, > > I see that provided patch [1] is for stable/8.0. Fuel 8.0 is recently > released and we usually do not accept any features to

[openstack-dev] [RDO] On-site Mitaka M3 test day in Brno

If you're anywhere in the Brno area (Czech Republic), I want to remind you that we're planning an on-site test day next week to test the Mitaka milestone 3 RDO packages, March 10th and 11th. For those not in the Brno area, we're doing the test day on the #rdo IRC channel (Freenode). Details for b

Re: [openstack-dev] [Fuel] FFE request for osnailyfacter refactoring for Puppet Master compatibility

This is not possible to move to 10. This is a critical feature that our 2 largest customers are dependent on for deployment at the end of May. Puppet Master flat out will not work with a Fuel deployed environment without doing this unless we were to create our own composition layer, which would

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/02/2016 06:25 AM, Ivan Kolodyazhny wrote: > Hi Team, > > Here are my thoughts and proposals how to make Cinder testing process > better. I won't cover "3rd party CI's" topic here. I will share my opinion > about current and feature jobs. > > > Unit-tests > >- Long-running tests. I hop

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Eric, There are Gorka's patches [10] to remove API Races [10] https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 4:27 PM, Eric Harney wrote: > On 03/02/2016 06:25 AM,

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

Igor, please note that this is pretty much not like update of master node which we had in 8.0. This is minor _update_ of CentOS from 7.1 to 7.2 which team tested for more than 2 months already. We don't expect it to require any additional efforts from core or qa team. Very important thing is that

[openstack-dev] [Fuel] Nominate Maksim Malchuk for the fuel-virtualbox-core team

Hey Fuelers, Since we've successfully moved [1] virtual-box scripts from fuel-main [2] to separate fuel-virtualbox [3] git repo, I propose to update fuel-virtualbox-core team [4] by adding Maksim Malchuk. Maksim is the main contributor to these scripts during Mitaka release cycle [5] Fuel Cores,

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

Hi all, Thank you for the nominations and +1s. I would like to propose Michael Polenchuk to add as a maintainer to fuel-library to take my spot when I leave the maintainers list. Best Regards, Matthew Mosesohn On Fri, Feb 26, 2016 at 3:54 PM, Kyrylo Galanov wrote: > Finally! +2 ! > > On Fri, Fe

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/02/2016 09:36 AM, Ivan Kolodyazhny wrote: > Eric, > > There are Gorka's patches [10] to remove API Races > > > [10] > https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > So the

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Rally is not part of the gate. Also making performance test without 3rd party CI will not be very useful. It is a good idea to run Rally performance and scenario testing but outside gate process. From: Ivan Kolodyazhny [mailto:[email protected]] Sent: Wednesday, March 02, 2016 8:36 AM To: OpenStack

[openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?

Hi, I have just notices the following change: https://review.openstack.org/#/c/286381 which aims to remove LBaaS v1. Is this planned for Mitaka or for Newton? While LBaaS v2 is becoming the default, I think that we should have the following before we replace LBaaS v1: 1. Horizon Support -

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Arkady, It's not true. We've got non-voting Rally job on Cinder gates called "gate-rally-dsvm-cinder". Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 4:52 PM, wrote: > Rally is not part of the gate. > > Also making performance test without 3rd party CI will not be ver

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Eric, For now, we test Cinder API with some concurrency only with Rally, so, IMO, it's reasonable get more scenarios for API races fixes. It's not a hard task to implement new scenarios, they are pretty simple: [11] and [12] [11] https://github.com/openstack/rally/blob/master/rally/plugins/opens

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 02/03, Ivan Kolodyazhny wrote: > Eric, > > There are Gorka's patches [10] to remove API Races > > > [10] > https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified > I looked at Rally a long time ago so apologies if I'm totally off base here, bu

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

Dmitry, Igor, > Very important thing is that CentOS 7.1 which master node is based now > don't get updates any longer. If you are using "fixed" release you must be ready that you won't get any updates. So with CentOS 7.2 the problem still the same. However, let's wait for Fuel PTL decision. I on

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/02/2016 10:07 AM, Ivan Kolodyazhny wrote: > Eric, > > For now, we test Cinder API with some concurrency only with Rally, so, IMO, > it's reasonable get more scenarios for API races fixes. > > It's not a hard task to implement new scenarios, they are pretty simple: > [11] and [12] > Sure,

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

I'll try to implement such scenario and step-by-step guideline soon. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 5:16 PM, Eric Harney wrote: > On 03/02/2016 10:07 AM, Ivan Kolodyazhny wrote: > > Eric, > > > > For now, we test Cinder API with some concurrency only wi

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?

Hi, A few things: - It’s not proposed for removal in Mitaka. That patch is for Newton. - HEAT and Horizon are planned for Mitaka (see neutron-lbaas-dashboard for the latter.) - I don’t view this as a “keep or delete” question. If sufficient folks are interested in maintaining it, there is a thi

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

Igor, Your statement about updates for 7.2 isn't correct - it will receive updates, because it's the latest release ATM. There is *no* pinning inside ISO, and the only place where it was 8.0 were docker containers just because we had to workaround some issues. But there are no docker containers i

[openstack-dev] [Fuel][FFE] Enable UCA repositories for deployment

Hi all, I would like to request a feature freeze exception for "Deploy with UCA packages" feature. I anticipate 2 more days to get tests green and add some depth to the existing test. https://blueprints.launchpad.net/fuel/+spec/deploy-with-uca-packages The impact to BVT stability is quite small

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are we ready?

As for the horizon support, much of it will make Mitaka. See the blueprint and gerrit topic: https://blueprints.launchpad.net/horizon/+spec/horizon-lbaas-v2-ui https://review.openstack.org/#/q/topic:bp/horizon-lbaas-v2-ui,n,z - Justin On 3/2/16 9:22 AM, Doug Wiegley wrote: Hi, A few things:

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

On 03/02/2016 04:11 PM, Gorka Eguileor wrote: > On 02/03, Ivan Kolodyazhny wrote: >> Eric, >> >> There are Gorka's patches [10] to remove API Races >> >> >> [10] >> https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified >> > I looked at Rally a long t

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

Igor, couple of points from my side. CentOS 7.2 will be getting updates for several more months, and we have snapshots and all the mechanics in place to switch to the next version when needed. Speaking of getting this update into 9.0, we actually don't need FFE, we can merge remaining staff today

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

On Tue, Mar 1, 2016 at 4:52 PM, Kevin Benton wrote: > Second, would it be acceptable to make this operator configurable? This > would mean users could receive different default filtering as they moved > between clouds. > If you must do this, please make it discoverable by the user/instance via a

Re: [openstack-dev] [Fuel] Nominate Maksim Malchuk for the fuel-virtualbox-core team

+1 On Wed, Mar 2, 2016 at 5:47 PM, Sergey Kulanov wrote: > Hey Fuelers, > > Since we've successfully moved [1] virtual-box scripts from fuel-main [2] > to > separate fuel-virtualbox [3] git repo, I propose to update > fuel-virtualbox-core > team [4] by adding Maksim Malchuk. Maksim is the main c

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

And as for the Heat support, the resources have made Mitaka, with additional functional tests on the way soon.   blueprint: https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport gerrit topic: https://review.openstack.org/#/q/topic:bp/lbaasv2-suport BRYAN M. JONES Software Engineer - OpenStack

Re: [openstack-dev] [cinder] Proposal: changes to our current testing process

Hi, I will try to be short. - Voting unit test coverage job is ready, and you can just use it as is from rally source code: you need this file https://github.com/openstack/rally/blob/master/tests/ci/cover.sh and this change in tox: https://github.com/openstack/rally/blob/master/tox.ini#L51-

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

Walter A. Boring IV said on Mon, Feb 22, 2016 at 11:47:16AM -0800: > I'm trying to follow this here. If we want all of the projects in > the same location to hold a design summit, then all of the > contributors are still going to have to do international travel, > which is the primary cost for at

Re: [openstack-dev] Openstack Cinder - Wishlist

There's actually a Launchpad category for this very thing. Under the importance tag. On Wed, Mar 2, 2016 at 6:27 AM, wrote: > Thank you Yatin! > > > > *From:* yatin kumbhare [mailto:[email protected]] > *Sent:* Tuesday, March 1, 2016 4:43 PM > *To:* OpenStack Development Mailing List (not

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

On Wed, Mar 2, 2016 at 7:52 AM, Dean Troyer wrote: > On Tue, Mar 1, 2016 at 4:52 PM, Kevin Benton wrote: > >> Second, would it be acceptable to make this operator configurable? This >> would mean users could receive different default filtering as they moved >> between clouds. >> > > If you must

[openstack-dev] [manila][python-manilaclient] Should we really be tagging "admin" CLIs?

Hi Manila community, This is regarding the "bug": https://bugs.launchpad.net/python-manilaclient/+bug/1457155 in the python-manilaclient. A commit was made for this and it merged yesterday: https://github.com/openstack/python-manilaclient/commit/37f2e50bd433149b893d30a478947f3e17f928e9 (

Re: [openstack-dev] [Fuel][library] Switching to external fixtures for integration Noop tests

An update. The task is done, the noop tests framework now has automatic docs builds to readthedocs [0] and a Fuel infra CI gate that tests changes against the fuel-library master, by running existing integration noop rspecs. So the CI is now mutual: changes to the fuel library are tested against t

Re: [openstack-dev] [sahara]FFE Request for nfs-as-a-data-source

Hi, It's different between Sahara and Manila for this feature support. This feature is to put NetApp Hadoop NFS Connector into Hadoop Cluster and let Hadoop can support NFS protocol. And it can also work with Manila NFS driver, since Manila only need to expose the NFS address from the storage si

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

On Wed, Mar 2, 2016 at 10:10 AM, Fawad Khaliq wrote: > Neutron security groups APIs should already allow discovery of what > default gets created. This should work or are you suggesting something > else? > So the default here for an allow all would be to include a single rule to do that? That's

Re: [openstack-dev] [Fuel][FFE] API handler for serialized graph

Thanks everyone, patch was merged. On Tue, Mar 1, 2016 at 6:22 PM, Dmitriy Shulyak wrote: > Hello folks, > > I am not sure that i will need FFE, but in case i wont be able to land > this patch [0] tomorrow - i would like to ask for one in advance. I will > need FFE for 2-3 days, depends mainly o

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

+1 for Michael :) ср, 2 мар 2016, 17:50 Matthew Mosesohn : > Hi all, > > Thank you for the nominations and +1s. I would like to propose Michael > Polenchuk to add as a maintainer to fuel-library to take my spot when > I leave the maintainers list. > > Best Regards, > Matthew Mosesohn > > On Fri,

Re: [openstack-dev] [manila][python-manilaclient] Should we really be tagging "admin" CLIs?

+1. But I do not think we should necessarily do this before FF. On Wed, Mar 2, 2016 at 1:07 PM, Ravi, Goutham wrote: > Hi Manila community, > > This is regarding the "bug": > https://bugs.launchpad.net/python-manilaclient/+bug/1457155 in the > python-manilaclient. > A commit was made for this a

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

On Wed, Mar 02, 2016 at 04:11:48PM +, Alexis Lee wrote: :Walter A. Boring IV said on Mon, Feb 22, 2016 at 11:47:16AM -0800: :> I'm trying to follow this here. If we want all of the projects in :> the same location to hold a design summit, then all of the :> contributors are still going to hav

Re: [openstack-dev] [manila][python-manilaclient] Should we really be tagging "admin" CLIs?

Sure, I meant, we shouldn't leave this in the client going into Newton. Thanks, Goutham From: Rodrigo Barbieri mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:[email protected]>> Date: Wednesday, March 2, 20

Re: [openstack-dev] [Fuel][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core

+1 for Michael Polenchuk On Wed, Mar 2, 2016 at 5:33 PM, Fedor Zhadaev wrote: > +1 for Michael :) > > ср, 2 мар 2016, 17:50 Matthew Mosesohn : > >> Hi all, >> >> Thank you for the nominations and +1s. I would like to propose Michael >> Polenchuk to add as a maintainer to fuel-library to take my

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

Yeah, the only thing this will due will change the default rules that are generated for a user's default security group. They will still be visible via the normal security groups API and users will be able to modify them. On Mar 2, 2016 08:22, "Dean Troyer" wrote: > On Wed, Mar 2, 2016 at 10:10 A

Re: [openstack-dev] [sahara]FFE Request for nfs-as-a-data-source

Hi, Currently, there is no plan for other plugin support in this feature. We would like to put this feature on the table at first and see if it can bring more customers who are interested in Big Data on Cloud and expecting to integrate Hadoop with different storage type support. However, it’s ju

Re: [openstack-dev] [Ceilosca][Neutron][Monasca]

On 1 Mar 2016 21:25, "Rubab Syed" wrote: > Hi all, > > I'm planning to write a plugin for Monasca that would enable router's > traffic monitoring per subnet per tenant. For that purpose, I'm using > Neutron l3 metering extension [1] that allows you to filter traffic based > on CIDRs. > > My conce

Re: [openstack-dev] [sahara]FFE Request for nfs-as-a-data-source

Hi, FFE not approved. tl;dr Spec for this feature isn't yet approved, so, I couldn't grant FFE for it, because it'll take much more time to get spec aligned and then code with it and merged code finally. Regarding the support in all plugins - I more or less agree with Vitaly that we it's bad to

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

Kevin Benton wrote: > * Instances without ingress are useless so a bunch of API calls are > required to make them useful. This is not true in all cases. There are plenty of workloads that only require outbound connectivity. Workloads where data is fetched, computed, then transmitted elsewhere for

Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Thank you all for your response. In my opinion given that UI/HEAT will make Mitaka and will have one cycle to mature, it makes sense to remove LBaaS v1 in Newton. Do we want do discuss an upgrade process in the summit? -Sam. From: Bryan Jones [mailto:[email protected]] Sent: Wednesday, March

[openstack-dev] [nova] config options help text improvement: current status

TL;DR: From ~600 nova specific config options are: ~140 at a central location with an improved help text ~220 options in open reviews (currently on hold) ~240 options todo Background == Nova has a lot of config options. Most of them weren't well documen

Re: [openstack-dev] [puppet] adding ovs dpdk agent into neutron

On 03/02/2016 03:07 AM, Ptacek, MichalX wrote: > Hi all, > > > > we have puppet module for ovs deployments with dpdk support > > https://github.com/openstack/networking-ovs-dpdk/tree/master/puppet IMHO that's a bad idea to use networking-ovs-dpdk for the puppet module. You should initiate t

[openstack-dev] [ceilometer] Unable to get ceilometer events for instances running on demo project

I have a single node configuration for devstack liberty working and I want to record all the *ceilometer events* like compute.instance.start, compute.instance.end, compute.instance.update etc occurred recently. I am unable to get any event occurred for instances running for demo project i.e when I

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

Formally, we can merge it today. Historically, every update of OS caused us instability for some time: from days to a couple of month. Taking this into account and number of other exceptions requested, overall stability of code, my opinion would be to postpone this to 10.0. Also, I'd suggest to ch

[openstack-dev] [Nova] Cells meeting cancelled next week

Since we'll be past FF by then work in progress will be slowing down. We will still meet occasionally to discuss specs or prepare for the summit, but not next week. The next meeting will be March 16th at 1700 UTC. __ OpenStac

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

On 2016-02-29 15:03:19 -0800 (-0800), James Bottomley wrote: [...] > it sounds like an an expectation that people who aren't gamers > would submit more than one patch and, indeed, become part of the > developer base. I wanted to explain why there's a significant set > of people who legitimately onl

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

"Sean M. Collins" wrote on 03/02/2016 12:38:29 PM: > I think that the default security group should be left as is - and users > should be trained that they should bring/create security groups with the > appropriate rules for their need. Could we at least make it less difficult to figure out whic

Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

"Wang, Shane" wrote on 02/05/2016 04:42:21 AM: > From: "Wang, Shane" > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 02/05/2016 04:43 AM > Subject: Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka > > Hi all, > > After discussing with TC membe

Re: [openstack-dev] [nova] Non-Admin user can show deleted instances using changes-since parameter when calling list API

On 3/2/2016 3:02 AM, Zhenyu Zheng wrote: Hi, Nova, While I'm working on add "changes-since" parameter support for python-novaclient "list" CLI. I realized that non-admin can list all deleted instances using "changes-since" parameter. This is reasonable in some level, as delete is an update to

Re: [openstack-dev] [nova] config options help text improvement: current status

Great. Does this additional improved text also get into the configuration guide documentation somehow ? Tim On 02/03/16 18:45, "Markus Zoeller" wrote: >TL;DR: From ~600 nova specific config options are: >~140 at a central location with an improved help text >~220 op

Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2

I agree with Mike's concerns, and propose to make these limitations (4 weeks before FF for OS upgrades, 2 weeks for upgrades of key dependencies -- RabbitMQ, MCollective, Puppet, MySQL, PostgreSQL, anything else?) official for 10.0/Newton. For 9.0/Mitaka, it is too late to impose them, so we just

[openstack-dev] [cinder] 3.rd Party CI requirements for compliance

Hi, I am new in this forum and openstack dev. so please my sincere apology if I submitted stupid (redundant) questions. I am writing this to clarify cinder compliance requirements (and 3.rd Party CI Testing). We are developing storage appliance and would like to run cinder on it. We don't direct

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

Mike Spreitzer wrote: > Could we at least make it less difficult to figure out which security > group is attached to a Nova instance? Right now `nova show` says only > that the security group is named "default" and guess what --- they are > *all* named default! An admin looking at this is lost

[openstack-dev] [Heat] Release of M3 milestone and FFE for rc-1

Hi all. I want to inform all, that mitaka-3 milestone was recently released: https://review.openstack.org/#/c/284198/ So now we are going to prepare mitaka-rc1. This milestone has one Feature Freeze Exception: https://blueprints.launchpad.net/heat/+spec/lbaasv2-suport For this BP we still has no

Re: [openstack-dev] [nova] config options help text improvement: current status

Excerpts from Markus Zoeller's message of 2016-03-02 18:45:45 +0100: [a lot snipped] > Appendix > > > Example of the help text improvement > --- > As an example, compare the previous documentation of the scheduler > option "scheduler_tracks_instance_chan

  1   2   >