Re: [openstack-dev] [ironic] Remember to follow RFE process

Thanks Ruby to point this out. On Thu, Mar 3, 2016 at 3:25 PM, Haomeng, Wang wrote: > Hi Ruby, > > Yes, just noticed that RFE is in 'Wishlist' status now, sorry for missing > the bug status yesterday, so we need to follow the process, and I will help > to revert the patch

Re: [openstack-dev] [ironic] Remember to follow RFE process

Hi Ruby, Yes, just noticed that RFE is in 'Wishlist' status now, sorry for missing the bug status yesterday, so we need to follow the process, and I will help to revert the patch and get it back to review again once the REF is reviewed. -- Haomeng On Thu, Mar 3, 2016 at 3:07 AM, Ruby Loo

Re: [openstack-dev] [Neutron] VM could not get IP from dhcp server

Hi Jingting, just few general hints (probably already checked): - security group rules in openstack (check both igress, egress, ….) – it’s quite common that after deployment it’s have to be modified - Iptables / fw ? – check if some packets are dropped - Cross-check

[openstack-dev] [fuel] Fuel 9.0/Mitaka is now in Feature Freeze

Feature Freeze [0] for Fuel 9.0/Mitaka is now in effect. From this moment and until stable/mitaka branch is created at Soft Code Freeze, please do not merge feature related changes that have not received a feature freeze exception. [0] https://wiki.openstack.org/wiki/FeatureFreeze We will

Re: [openstack-dev] [nova][cinder] Limits on volume read throughput?

Hi Preston, > The benchmark scripts are in: > > https://github.com/pbannister/openstack-bootstrap in case that might help, here are a few notes and hints about doing benchmarks for the DRDB block device driver: http://blogs.linbit.com/p/897/benchmarking-drbd/ Perhaps there's something

[openstack-dev] [Neutron] VM could not get IP from dhcp server

Hi guys: I have openstack Liberty(linuxbridge + vxlan) installed, and the vm could not get IP from dhcp server. Troubleshooting: Using tcpdump can get dhcp discover packet on physical NIC on network node, but can't get it on vxlan port(vxlan-100) on network node. In opposite direction,

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

On 3/2/2016 11:45 AM, Markus Zoeller wrote: 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

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

Don't quote me on this, but the tool that generates the dev docs is the one the docs team for the config ref use to generate that document. And they have been looped in on the upcoming improvements. --Rocky -Original Message- From: Matthew Treinish [mailto:mtrein...@kortar.org] Sent:

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

On 02/29/2016 01:49 PM, Andrew Laski wrote: On Mon, Feb 29, 2016, at 01:18 PM, Dan Smith wrote: Forgive my ignorance or for playing devil's advocate, but wouldn't the main difference between notifications and hooks be that notifications are asynchronous and hooks aren't? The main difference

[openstack-dev] [app-catalog] IRC Meeting Thursday March 3rd at 17:00UTC

Join us Thursday for our weekly meeting, scheduled for March 3rd at 17:00UTC in #openstack-meeting-3 The agenda can be found here, and please add to if you want to get something on the agenda: https://wiki.openstack.org/wiki/Meetings/app-catalog Looking forward to seeing everyone there tomorrow!

Re: [openstack-dev] [nova][cinder] Limits on volume read throughput?

First, my degree from school is in Physics. So I know something about designing experiments. :) The benchmark scripts runs "dd" 218 times, against different volumes (of differing sizes), with differing "bs". Measures are collected both from the physical host, and from the within the instance.

[openstack-dev] [fuel] Newton PTL and CL elections

Team, We're only two weeks away from the beginning of the Newton elections period. Based on the Fuel 9.0/Mitaka release schedule [0], I propose the following dates for PTL and CL self-nomination and election periods: PTL self-nomination: March 13-20 PTL election: March 21-27 CL self-nomination:

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

no removal without an upgrade path. I've got v1 LB's and there still isn't a migration script to go from v1 to v2. Thanks, Kevin From: Stephen Balukoff [sbaluk...@bluebox.net] Sent: Wednesday, March 02, 2016 4:49 PM To: OpenStack Development Mailing List (not

[openstack-dev] openstack swift as a cache proxy for nginx, swift proxy report 401 error when authenticate

I am trying to find a way to use Openstack swift to cache static file for a web server such as nginx, the below are request step: 1.nginx is configured as a load balance proxy server and web server. 2.There are several swift , suppose there are 2, that is swift-A,swift-B

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

I am also on-board with removing LBaaS v1 as early as possible in the Newton cycle. On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici wrote: > Thank you all for your response. > > > > In my opinion given that UI/HEAT will make Mitaka and will have one cycle > to mature, it

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

Thanks for the detailed explanation, very helpful! Considering that this change is atomic and easily revertable, lets proceed with the change, the sooner we do that the more time we'll have to confirm that there is no impact and revert if necessary. -- Dmitry Borodaenko On Thu, Mar 03, 2016 at

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

Hi, let me add some details about the change: 1) There are two repositories used to build Fuel ISO: base OS repository [1], and mos repository [2], where we put Fuel dependencies and packages we rebuild due to certain version requirements. The CentOS 7.2 feature is related to the upstream repo

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

On 03/02/2016 02:46 PM, Mike Spreitzer wrote: Kevin Benton wrote on 03/02/2016 01:27:27 PM: > Does it at least also include the UUID, or is there no way to tell > from 'nova show'? No direct way to tell, as far as I can see. Yep. Best I can find is: neutron port-list

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

On Thu, Mar 03, 2016 at 10:24:28AM +1100, Tony Breeds wrote: > On Wed, Mar 02, 2016 at 06:11:47PM +, Tim Bell wrote: > > > Great. Does this additional improved text also get into the configuration > > guide documentation somehow ? > > It's certainly part of tox -egenconfig, I don't know

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

On Wed, Mar 02, 2016 at 06:11:47PM +, Tim Bell wrote: > Great. Does this additional improved text also get into the configuration > guide documentation somehow ? It's certainly part of tox -egenconfig, I don't know about docs.o.o Tony. signature.asc Description: PGP signature

[openstack-dev] [tosca-parser] [heat-translator] [heat] [tacker] Heat-Translator 0.4.0 PyPI release

Hello Everyone, On behalf of the Heat-Translator team, I am pleased to announce the 0.4.0 PyPI release of heat-translator which can be downloaded from https://pypi.python.org/pypi/heat-translator This release includes following enhancements: ▪ Uses latest tosca-parser 0.4.0

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

Kevin Benton wrote on 03/02/2016 01:27:27 PM: > Does it at least also include the UUID, or is there no way to tell > from 'nova show'? No direct way to tell, as far as I can see. __ OpenStack

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

Yeah, we've changed the default so that at very least you can ssh to the vm. If all you provide is a completely locked or a completely open sg, users will choose the completely open one every time. :/ Putting a few common cases might go a long way to keep things more secure by default.

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

On 02/03/16 05:50, Mathieu Velten wrote: 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

Re: [openstack-dev] [all][log] Ideas to log request-ids in cross-projects

Excerpts from Kekane, Abhishek's message of 2016-03-01 06:17:15 +: > Hi Devs, > > Considering return request-id to caller specs [1] is implemented in > python-*client, I would like to begin discussion on how these request-ids > will be logged in cross-projects. In logging work-group meeting

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

My opinion is that the current stance of ‘deny all’ is probably the safest bet for all parties (including users) at this point. It’s been that way for years now, and is a substantial change that may result in little benefit. After all, you’re probably looking at most users removing the default

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

Thanks Sean for bringing this up. It's a known pain point that we discussed back in Tokyo [0]. Failures in class level fixtures are difficult to handle consistently, because there is no concept of success / failure at class level in the data model. If a failure happens during setup, no test is

[openstack-dev] [packstack] New upstream integration gate jobs

Hi everyone ! Throughout the Mitaka cycle, we have been working hard towards getting Packstack to test itself with a self-installed Tempest implementation and I'm excited to announce that it's a great success ! This effectively allowed us not only to add three different integration tests right

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

On 2016-03-02 21:25:25 + (+), Sean M. Collins wrote: > Jeremy Stanley wrote: > > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote: > > [...] > > > In my mind, the default security group is there so that as people > > > are developing their security policy they can at least start with

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

Clark Boylan wrote: > On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote: > > Kevin Benton wrote: > > > * Neutron cannot be trusted to do what it says it's doing with the > > > security > > > groups API so users want to orchestrate firewalls directly on their > > > instances. > > > > This

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

Jeremy Stanley wrote: > On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote: > [...] > > In my mind, the default security group is there so that as people > > are developing their security policy they can at least start with > > a default that offers a small amount of protection. > > Well, not

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

On 2016-03-03 07:49:03 +1300 (+1300), Xav Paice wrote: [...] > In my mind, the default security group is there so that as people > are developing their security policy they can at least start with > a default that offers a small amount of protection. Well, not a small amount of protection. The

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

Hi MichalX, Sean, Building from sources is possible, but it will be more stable, if you will use packaging system from the OS. Also, it will be really good if your module make changes to OpenStack configuration files using puppet-nova and puppet-neutron, and it could be split for compute/agent

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

On 03/02/2016 02:48 PM, Ptacek, MichalX wrote: > Thanks Emilien, > It's becoming more clear to me what has to be done. > Did I get it correctly that using bash code inside puppet module is "nish > nish" and will NOT be accepted by the community ? It's really bad practice in my opinion. >

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

On 03/02/2016 01:53 PM, Andrew Laski wrote: On Wed, Mar 2, 2016, at 02:36 PM, Gregory Haynes wrote: Clearly, some operators and users disagree with the opinion that 'by default security groups should closed off' given that we have several large public providers who have changed these defaults

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

On Wed, Mar 02, 2016 at 06:14:30PM +, Indra Harijono wrote: > 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

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

On 03/02/2016 01:04 PM, Xav Paice wrote: On 3 March 2016 at 07:52, Sean Dague > wrote: On 03/02/2016 01:46 PM, Armando M. wrote: > IMO, I think that's a loophole that should be closed. We should all > strive to make OpenStack clouds

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

On Wed, Mar 2, 2016, at 02:36 PM, Gregory Haynes wrote: > Clearly, some operators and users disagree with the opinion that 'by > default security groups should closed off' given that we have several > large public providers who have changed these defaults (despite there > being no documented

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

Thanks Emilien, It's becoming more clear to me what has to be done. Did I get it correctly that using bash code inside puppet module is "nish nish" and will NOT be accepted by the community ? (even if we move the logic into own module like openstack/ovs-dpdk) Additionally building from the src

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

On 18:14 Mar 02, Indra Harijono wrote: > 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

Re: [openstack-dev] [oslo][all] Documenting configuration options lifespan

Excerpts from Ronald Bradford's message of 2016-03-02 13:40:42 -0500: > After evaluation of oslo-config-generator and one of it's common uses by > operators in configuration option evaluation with upgrades, I am proposing > adding some meta data for all configuration options to provide better >

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

Clearly, some operators and users disagree with the opinion that 'by default security groups should closed off' given that we have several large public providers who have changed these defaults (despite there being no documented way to do so), and we have users in this thread expressing that

[openstack-dev] [ironic] Remember to follow RFE process

Hi, Ironic'ers, please remember to follow the RFE process; especially the cores. I noticed that a patch [1] got merged yesterday. The patch was associated with an RFE [2] that hadn't been approved yet :-( What caught my eye was that the commit message didn't describe the actual API change so I

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

No, there haven't been vulnerabilities where the rules you expressed in the API were not rendered as requested (unless there was a denial of service in which case the whole dataplane would fail to wire). The issues were people being able to escape their own anti-spoofing filtering so they could do

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

On 03/02/2016 01:46 PM, Armando M. wrote: > IMO, I think that's a loophole that should be closed. We should all > strive to make OpenStack clouds behave alike. It might be a loophole. But it's also data. People are doing that thing for a reason based on customer feedback. If the general norms

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

>From one operator's standpoint, some comments below. I can't imagine having to tell my customer base that we've just changed the 'default' security group from not allowing anything inbound, to allowing everything. That would mean they would all have to strip the default group from all their

Re: [openstack-dev] [puppet] Removing old puppetlabs/* forge OS modules

On 03/02/2016 01:46 PM, Hunter Haugen wrote: > Several years ago, the at-the-time Stackforge puppet modules were > published under the forge.puppetlabs.com/puppetlabs > namespace. Then those modules > were migrated to forge.puppetlabs.com/stackforge >

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

On 1 March 2016 at 14:52, Kevin Benton wrote: > Hi, > > I know this has come up in the past, but some folks in the infra channel > brought up the topic of changing the default security groups to allow all > traffic. > > They had a few reasons for this that I will try to

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

Hi, I understand that it's more user-friendly to enable by default all traffic to VMs, but it seems clearly unsecure to enable by default all traffic to VMs (including ssh from internet!!!), as it increases the VM exposition surface on internet and reduces its security. Cédric/ZZelle On

[openstack-dev] [puppet] Removing old puppetlabs/* forge OS modules

Several years ago, the at-the-time Stackforge puppet modules were published under the forge.puppetlabs.com/puppetlabs namespace. Then those modules were migrated to forge.puppetlabs.com/stackforge for a while. When they became an official OpenStack project they were migrated to

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

On Wed, Mar 2, 2016, at 09:38 AM, Sean M. Collins wrote: > Kevin Benton wrote: > > * Neutron cannot be trusted to do what it says it's doing with the security > > groups API so users want to orchestrate firewalls directly on their > > instances. > > This one really rubs me the wrong way. Can we

[openstack-dev] [oslo][all] Documenting configuration options lifespan

After evaluation of oslo-config-generator and one of it's common uses by operators in configuration option evaluation with upgrades, I am proposing adding some meta data for all configuration options to provide better applicable documentation as projects continue to evolve. I can see an easier

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

On 3/1/2016 11:36 PM, John Griffith wrote: On Tue, Mar 1, 2016 at 3:48 PM, Murray, Paul (HP Cloud) > wrote: > -Original Message- > From: D'Angelo, Scott > > Matt, changing Nova to store the connector info at volume attach

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

"Sean M. Collins" wrote on 03/02/2016 01:16:52 PM: > Meaning your users are creating new security groups and naming them > "default" - so you have the "default" default (heh) and then the one > that they created named default? > > Are security group names in Nova-Net unqiue?

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

Hi, It's still not clear for me, why we can't just add Rally jobs with scenarios related to specific project. It will work quite fast and it will cover CLI (instantly) with good integration/functional testing. Best regards, Boris Pavlovic On Wed, Mar 2, 2016 at 4:52 AM, Sean Dague

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

Does it at least also include the UUID, or is there no way to tell from 'nova show'? On Wed, Mar 2, 2016 at 10:01 AM, Mike Spreitzer wrote: > "Sean M. Collins" wrote on 03/02/2016 12:38:29 PM: > > > I think that the default security group should be left

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

It is not just about BVT. I'd suggest to monitor situation overall, including failures of system tests [1]. If we see regressions there, or some test cases will start flapping (what is even worse), then we'd have to revert back to CentOS 7.1. [1] https://github.com/openstack/fuel-qa On Wed, Mar

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

[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

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

[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

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

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

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

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]

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

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

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

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

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

[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

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:jone...@us.ibm.com] Sent: Wednesday, March

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

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

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,

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

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 > Reply-To: "OpenStack Development Mailing List (not for usage questions)"

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

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

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

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

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

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

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

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

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:yatinkumbh...@gmail.com] > *Sent:* Tuesday, March 1, 2016 4:43 PM > *To:* OpenStack

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

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:

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

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

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

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

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

[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

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

  1   2   >