Re: [Openstack-operators] Snapshots taking long time

Hello Saverio, Thanks for your answer. In that case the problem is that I thought the patch you are referring to was already make in Kilo. Doing snapshots directly from ceph goes fast: [root@ceph01: ~] # time rbd -p volumes snap create volume-fecc8258-e6d8-4d3c-9ac2-fe98b5dbbc2f@mytestsnap

Re: [Openstack-operators] Snapshots taking long time

Hello Andreas, what kind of snapshot are you doing ? 1) Snapshot of a instance running on a ephimeral volume ? 2) Snapshot of a instance booted from Volume ? 3) Snapshot of a volume ? in case 1 the ephemeral volume is in the volume pool with the name _disk when you snapshot, this must be read

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

[Openstack] [X-POST]I Know What You Are Going To Do This Summer 2016

Hi, Do you want to see your name next time you install GNU/Linux in your friend's computer? If yes, then go ahead and read ... We are happy to announce "I Know What You Are Going To Do This Summer 2016",[1] a free (as in freedom), online (IRC-based) [2] training sessions for new comers to

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-operators] Snapshots taking long time

We are currently installing a new openstack cluster (Liberty) with openstack-ansible and an already existing ceph cluster. We have both images and volumes located in ceph with rbd. My current problem is that snapshots take a very long time and I can see that snapshots are temporary created

[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

Re: [Openstack-operators] [openstack-community] Recognising Ops contributions

On Wed, Mar 2, 2016 at 3:37 PM, Edgar Magana wrote: > We want to make this a reality by gathering a list of criteria that we as > a community feel that shows someone has demonstrated technical > contributions, using their skills as Ops. Our current ideas are as

[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-operators] Setting affinity based on instance type

What would prevent the next user from having workloadB collocated with an other user's workloadA if that's the only capacity available? Unless aggregates are used, it will be hard to guaranty that workloadA and workloadB (from any users) are never collocated. You could probably play with custom

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!

[Openstack-operators] [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-operators] Setting affinity based on instance type

Hi Kris, When using aggregates as an example, anyone can assign workloadA<>aggregateA and workloadB<>aggregateB. That's easy. But if we have outstanding requests for workloadB and have a glut of capacity in aggregateA, workloadB won't be able to use those hosts so we have spare capacity and no

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.

Re: [Openstack-operators] Workload Management (post-instantiation)

Okay that is pretty much aligned with what I was thinking - custom monitor/trigger/action. An ask coming out of one of our design discussions today was what products exist that do (or attempt to) address what is normally handled by workload management toolkits such as VMware DRS. //adam *Adam

Re: [Openstack-operators] Setting affinity based on instance type

We're looking at two workloads with different usage patterns: Type A follows a typical cyclical performance pattern (high/low day/night). Type B represents a consistent pattern (constant/predictable pattern). We want a way to ensure Patterns A will have an affinity to stick together, Patterns B

[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-operators] Workload Management (post-instantiation)

We would love to have something like that as well. However, to do it in openstack would mean that something would have to gather/monitor the health of the HV's and not only disable new provisions but kick off/monitor the migrations off the host and onto the new chosen destinations . Also, due

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-operators] Configuration tool for Openstack

Hello Chris, Please, consider to move your code to OSOps Repos: https://wiki.openstack.org/wiki/Osops Let me know if you need some assistance, Edgar From: "chrishul...@gmail.com" > Date: Wednesday, March 2, 2016

Re: [Openstack-operators] Workload Management (post-instantiation)

We have done it with nagios checks and customize ruby code. Edgar From: Adam Lawson > Date: Wednesday, March 2, 2016 at 1:48 PM To: "openstack-operators@lists.openstack.org"

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

[Openstack-operators] Setting affinity based on instance type

I'm sure this is possible but I'm trying to find the info I need in the docs so I figured I'd pitch this to you guys while I continue looking: Is it possible to set an affinity/anti-affinity policy to ensure instance Type A is weighted for/against co-location on the same physical host with

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

[Openstack-operators] Recognising Ops contributions

Dear Users and Operators, The Foundation User Committee [1] has received multiple requests to enable a formal recognition of your contributions to the OpenStack community. This email is our approach to formalize this recognition and make sure that we all feel and are part of the community.

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-operators] Cloud Upgrade Strategies

- In-place Full Release upgrades (upgrade an entire cloud from Icehouse to Kilo for instance) This tends to be the most likely scenario with CI/CD being almost impossible for anyone using supported openstack components ( such as SDN / NAS / other hardware integration pieces ). That's not

[Openstack-operators] Workload Management (post-instantiation)

Hello fellow Ops-minded stackers! I understand OpenStack uses scheduler logic to place a VM on a host to ensure the load is balanced across hosts. My 64 million dollar question is: Has anyone identified a way to monitor capacity across all hosts on an ongoing basis and automatically live migrate

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

[Openstack-operators] Cloud Upgrade Strategies

Hey all, So I've been discussing cloud design with the team and of course the topic comes up about how upgrades will be handled. Handling OpenStack code updates generally consists of three paths in my experience: - CI/CD (continuous incremental upgrades) - In-place Full Release upgrades

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-operators] Configuration tool for Openstack

sounds fun. I might give it a go after and see if it explodes =P On Wed, Mar 2, 2016 at 4:12 PM, wrote: > I'm going to use Pluto to do a basic Liberty install. In a couple of > days I'll have a full set of the basic six install files instead of just > the one I

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-operators] Configuration tool for Openstack

I'm going to use Pluto to do a basic Liberty install. In a couple of days I'll have a full set of the basic six install files instead of just the one I included for glance. They will be geared around a one box install at first. I'll update the site. Chris Sent from my iPhone > On Mar

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-operators] Configuration tool for Openstack

Not yet. I'm totally open to suggestions. - Chris. Sent from my iPhone > On Mar 2, 2016, at 1:07 PM, Silence Dogood wrote: > > This is neat man. Any support for versioning? > >> On Wed, Mar 2, 2016 at 3:54 PM, wrote: >> Hi all; >> >> I'm

Re: [Openstack-operators] Configuration tool for Openstack

This is neat man. Any support for versioning? On Wed, Mar 2, 2016 at 3:54 PM, wrote: > Hi all; > > I'm still a bit new to the world of stacking, but like many of you I have > suffered thru the process of manual Openstack installation. > > I've been a developer for

[Openstack-operators] Configuration tool for Openstack

Hi all; I'm still a bit new to the world of stacking, but like many of you I have suffered thru the process of manual Openstack installation. I've been a developer for decades, so please excuse me for "productizing" a simple tool. I hope this is useful. Feedback much appreciated.

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] [ceilometer] Troubleshooting Ceilometer

Nadya, The logs for agent-notification appear to be clear of errors. Here is an an excerpt from it: (I turned on debug to see if there is any additional information that might be suppressed, but there doesn't seem to be much there) 2016-03-02 13:43:23.194 31681 DEBUG ceilometer.pipeline [-]

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

[Openstack] migrating instance to another machine

Hi all, I¹m having trouble migrating a virtual instance to another host. I¹m setting up a small private openstack environment. Currently I only have two hosts; call them os1 and os2. Os1 is the controller and also a compute node, and os2 is a compute node. There is one vm running on os2, and I'd

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

[OpenStack-Infra] Proposal: Weekly status update on Infracloud

Hi Folks, As most of us already know and agree, the infracloud is a really important project but also a complex undertaking with a lot of dependencies and moving parts. Some amazing progress has been made before and during the infracloud sprint last week. To help keep that momentum going, I'd

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-operators] [neutron] Default security group discussion on openstack-dev

Hi Operators, There is a discussion going on right now on the openstack-dev mailing list which I think is important for operators to weigh in on. The short summary is that some believe the default security group and rules (which allow only outbound by default, and no inbound) should be changed.

[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

  1   2   >