Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Excerpts from Alan Kavanagh's message of 2014-01-15 19:11:03 -0800: > Hi Paul > > I posted a query to Ironic which is related to this discussion. My thinking > was I want to ensure the case you note here (1) " a tenant can not read > another tenants disk.." the next (2) was where in Ironic y

Re: [openstack-dev] [Ironic] Let's move to Alembic

On 01/15/2014 07:59 PM, Devananda van der Veen wrote: Hi all, Some months back, there was discussion to move Ironic to use Alembic instead of SqlAlchemy. At that time, I was much more interested in getting the framework together than I was in restructuring our database migrations, and what we ha

Re: [openstack-dev] a "common" client library

On Jan 15, 2014, at 6:16 PM, Doug Hellmann wrote: > > > > On Wed, Jan 15, 2014 at 5:39 PM, Dean Troyer wrote: > On Wed, Jan 15, 2014 at 1:37 PM, Doug Hellmann > wrote: > Several people have mentioned to me that they are interested in, or actively > working on, code related to a "common" c

[openstack-dev] [Ironic] Let's move to Alembic

Hi all, Some months back, there was discussion to move Ironic to use Alembic instead of SqlAlchemy. At that time, I was much more interested in getting the framework together than I was in restructuring our database migrations, and what we had was sufficient to get us off the ground. Now that the

Re: [openstack-dev] [heat] Sofware Config progress

On 01/14/2014 09:27 PM, Clint Byrum wrote: Excerpts from Prasad Vellanki's message of 2014-01-14 18:41:46 -0800: Steve I did not mean to have custom solution at all. In fact that would be terrible. I think Heat model of software config and deployment is really good. That allows configurators s

Re: [openstack-dev] a "common" client library

>I did notice, however, that neutronclient is conspicuously absent from the Work Items in the blueprint's Whiteboard. It will surely be added later. We already working on several things in parallel and we will add neutronclient soon. >I would love to see a bit more detail on the structure of the l

Re: [openstack-dev] [heat] Sofware Config progress

On 15/01/14 06:21, Clint Byrum wrote: > Hey Steve, it has taken me about a month to get enough time to go > through this. Thanks for doing it, comments in-line. > > Excerpts from Steve Baker's message of 2013-12-13 15:46:48 -0800: >> I've been working on a POC in heat for resources which perform so

[openstack-dev] question of vcpu-memory-hotplug progress

Hi, all We are interesting in vcpu-memory-hotplug under this link: https://blueprints.launchpad.net/nova/+spec/vcpu-memory-hotplug And we have already finished vcpu hotplug and done the basic tests. But this blueprint seems not be reviewed for almost half year. We think this feature is important

Re: [openstack-dev] a "common" client library

Doug Hellmann writes: > Several people have mentioned to me that they are interested in, or > actively working on, code related to a "common" client library -- something > meant to be reused directly as a basis for creating a common library for > all of the openstack clients to use. There's a blu

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Hi Paul I posted a query to Ironic which is related to this discussion. My thinking was I want to ensure the case you note here (1) " a tenant can not read another tenants disk.." the next (2) was where in Ironic you provision a baremetal server that has an onboard dish as part of the blade

[openstack-dev] [neutron] unnecessary return statement in ovs_lib

Came across the following issue while looking at ovs_lib [1]: The BaseOVS class has the add_bridge() method which after creating an OVS bridge, returns an OVSBridge object. BaseOVS class is only used by OVSBridge defined in the same file. OVSBridge has a create() method that calls the add_bridge

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Yes, Solum is interested in this too. Ideally we would like a way to specify the volume clear upon each volume creation, not in a configuration file. We would likely implement that as an attribute on the environment and assembly resources, which group various cloud resources similar to a stack i

Re: [openstack-dev] [OpenStack-Dev] Third party testing

On Wed, Jan 15, 2014 at 6:41 PM, Michael Still wrote: > John -- I agree with you entirely here. My concern is more that I > think the CI tests need to run more frequently than weekly. Completely agree, but I guess in essence to start these aren't really CI tests. Instead it's just a public healt

Re: [openstack-dev] [OpenStack-Dev] Third party testing

John -- I agree with you entirely here. My concern is more that I think the CI tests need to run more frequently than weekly. Michael On Thu, Jan 16, 2014 at 9:30 AM, John Griffith wrote: > On Wed, Jan 15, 2014 at 6:03 PM, Michael Still wrote: >> On Thu, Jan 16, 2014 at 6:28 AM, John Griffith >

Re: [openstack-dev] [OpenStack-Dev] Third party testing

On Wed, Jan 15, 2014 at 5:39 PM, Sankarshan Mukhopadhyay wrote: > On Thu, Jan 16, 2014 at 3:58 AM, John Griffith > wrote: >> A while back I started talking about this idea of requiring Cinder >> driver contributors to run a super simple cert script (some info here: >> [1]). > > Could you provide

Re: [openstack-dev] [OpenStack-Dev] Third party testing

On Wed, Jan 15, 2014 at 6:03 PM, Michael Still wrote: > On Thu, Jan 16, 2014 at 6:28 AM, John Griffith > wrote: >> Hey Everyone, >> >> A while back I started talking about this idea of requiring Cinder >> driver contributors to run a super simple cert script (some info here: >> [1]). Since then

[openstack-dev] Introduction: Rich Megginson - Designate project

Hello. My name is Rich Megginson. I am a Red Hat employee interested in working on Designate (DNSaaS), primarily in the areas of integration with IPA DNS, DNSSEC, and authentication (Keystone). I've signed up for the openstack/launchpad/gerrit accounts. Be seeing you (online). _

Re: [openstack-dev] Using heat with cfn templates

On 01/15/2014 06:17 PM, Avi L wrote: Hi I have a script that runs against AWS and uses the older cloudformation commands (i.e cfn-describe-stack or cfn-create-stack . What is the recommended way of porting this script to run against openstack so it can utilize the same / similar cfn templates

[openstack-dev] Using heat with cfn templates

Hi I have a script that runs against AWS and uses the older cloudformation commands (i.e cfn-describe-stack or cfn-create-stack . What is the recommended way of porting this script to run against openstack so it can utilize the same / similar cfn templates and use compatible heat commands? Basicia

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

On 12/26/2013 07:56 AM, cosmos cosmos wrote: > Hello. > > My name is Rucia for Samsung SDS. > > > I had in truouble in volume deleting. > > I am developing for supporting big data storage such as hadoop in lvm. > > > it use as a full disk io for deleting of cinder lvm volume because of dd th

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Exactly. :) Thanks, Kevin From: Chris Friesen [chris.frie...@windriver.com] Sent: Wednesday, January 15, 2014 4:50 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder. On 01/15/201

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

That option is too corse. For some vm's, for testing for example, I really dont need it clearing the data, and for some of my tests, I was creating 6 vm's with 4, 40 gig volumes each all on one test machine and it was taking several minutes to whipe each stack create/delete cycle I was doing whi

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Yeah, but the thing about encryption is, by nature, it isn't exactly secure. Its all based on probability: * Use a big enough set of numbers that its unlikely someone would guess or unlikely that enough compute power could be brought to bare to brute force guess it. * Try and use an algorithm th

Re: [openstack-dev] [OpenStack-Dev] Third party testing

On Thu, Jan 16, 2014 at 6:28 AM, John Griffith wrote: > Hey Everyone, > > A while back I started talking about this idea of requiring Cinder > driver contributors to run a super simple cert script (some info here: > [1]). Since then I've been playing with introduction of a third party > gate chec

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

On 01/15/2014 06:30 PM, Jay S Bryant wrote: There is already an option that can be set in cinder.conf using 'volume_clear=none' Is there a reason that that option is not sufficient? That option would be for the cloud operator and since it would apply to all volumes on that cinder node. My i

[openstack-dev] [TripleO] [Tuskar] [UX] Infrastructure Management UI - Icehouse scoped wireframes

Hi folks, thanks everybody for feedback. Based on that I updated wireframes and tried to provide a minimum scope for Icehouse timeframe. http://people.redhat.com/~jcoufal/openstack/tripleo/2014-01-16_tripleo-ui-icehouse.pdf Hopefully we are able to deliver described set of features. But if yo

Re: [openstack-dev] [OpenStack-Dev] Third party testing

On Thu, Jan 16, 2014 at 3:58 AM, John Griffith wrote: > A while back I started talking about this idea of requiring Cinder > driver contributors to run a super simple cert script (some info here: > [1]). Could you provide the link which [1] refers to? -- sankarshan mukhopadhyay

Re: [openstack-dev] [OpenStack-Dev] Third party testing

On Thu, Jan 16, 2014 at 3:58 AM, John Griffith wrote: > A while back I started talking about this idea of requiring Cinder > driver contributors to run a super simple cert script (some info here: > [1]). Could you provide the link which [1] refers to? -- sankarshan mukhopadhyay

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

There is already an option that can be set in cinder.conf using 'volume_clear=none' Is there a reason that that option is not sufficient? Jay S. Bryant IBM Cinder Subject Matter Expert & Cinder Core Member Department 7YLA, Building 015-2, Office E125, Rochester, MN Telephone: (507) 25

Re: [openstack-dev] [Ceilometer][Nova] basic setting for notification_driver

Thank you for clarifying it. But in my SLES environment, following the suse install guide: # openstack-config --set /etc/nova/nova.conf DEFAULT notification_driver nova.openstack.common.notifier.rpc_notifier # openstack-config --set /etc/nova/nova.conf DEFAULT notification_driver ceilometer.compu

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

To clarify a couple of Robert's points, since we had a conversation earlier: On 15 January 2014 23:47, Robert Li (baoli) wrote: > --- do we agree that BDF address (or device id, whatever you call it), > and node id shouldn't be used as attributes in defining a PCI flavor? > Note that the curr

Re: [openstack-dev] [devstack] libvirt default log level

Hi, > -Original Message- > From: Sean Dague [mailto:s...@dague.net] > Sent: Thursday, January 16, 2014 4:54 AM > To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage > questions) > Subject: Re: [openstack-dev] [devstack] libvirt default log level > > On 01/15/2014 0

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

On 01/15/2014 06:00 PM, Fox, Kevin M wrote: What about a configuration option on the volume for delete type? I can see some possible options: * None - Don't clear on delete. Its junk data for testing and I don't want to wait. * Zero - Return zero's from subsequent reads either by zeroing on de

Re: [openstack-dev] a "common" client library

On Wed, Jan 15, 2014 at 5:39 PM, Dean Troyer wrote: > On Wed, Jan 15, 2014 at 1:37 PM, Doug Hellmann < > doug.hellm...@dreamhost.com> wrote: > >> Several people have mentioned to me that they are interested in, or >> actively working on, code related to a "common" client library -- something >> m

[openstack-dev] [State-Management] Agenda for tommorow meeting at 2000 UTC

Hi all, The [state-management] project team holds a weekly meeting in #openstack-meeting on thursdays, 2000 UTC. The next meeting is tommorow, 2014-01-16!!! As usual, everyone is welcome :-) Link: https://wiki.openstack.org/wiki/Meetings/StateManagement Taskflow: https://wiki.openstack.org

Re: [openstack-dev] [oslo] need input on new config option for logging translations

On Wed, Jan 15, 2014 at 6:07 PM, Luis A. Garcia wrote: > On 1/15/2014 12:39 PM, Doug Hellmann wrote: > >> Based on the discussion with the other PTLs at the release meeting >> yesterday, I'm going to recommend that we create an example logging.conf >> file and documentation to go with it, and not

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

What about a configuration option on the volume for delete type? I can see some possible options: * None - Don't clear on delete. Its junk data for testing and I don't want to wait. * Zero - Return zero's from subsequent reads either by zeroing on delete, or by faking zero reads initially. * Ra

Re: [openstack-dev] a "common" client library

On Jan 15, 2014, at 4:55 PM, "Renat Akhmerov" mailto:rakhme...@mirantis.com>> wrote: Great idea, fully support it. We’re interested in that too. One specific thing that was mentioned is the ability to mock auth service seems to be very useful for some test scenarios, we came across that recen

Re: [openstack-dev] [oslo] need input on new config option for logging translations

On 1/15/2014 12:39 PM, Doug Hellmann wrote: Based on the discussion with the other PTLs at the release meeting yesterday, I'm going to recommend that we create an example logging.conf file and documentation to go with it, and not add the new option. I am seeing that neutron does not even ship

[openstack-dev] Announcement of System Compass Golden Image and Code Base

Dear Stackers, We gave a talk during last OpenStack summit held in HongKong about our System Compass, a tool we initially developed to facilitate our internal OpenStack deployment, an MVP for ourselves (btw, we believe we are a group of practitioners of Eric Ries' "Lean Startup"), which later o

[openstack-dev] [nova] instance migration strangeness in devstack

I think this qualifies as a development question but please let me know if I am wrong. I have been trying to test instance migration in devstack by setting up a multi-node devstack following directions at http://devstack.org/guides/multinode-lab.html. I tested that indeed there were multiple

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

Chris Friesen [mailto:chris.frie...@windriver.com] wrote: >I read a proposal about using thinly-provisioned logical volumes as a >way around the cost of wiping the disks, since they zero-fill on demand >rather than incur the cost at deletion time. I think it make a difference where the requirem

Re: [openstack-dev] [neutron] [third-party-testing] Sharing information

FYI, here [1] are the meeting logs from today’s meeting. A couple of things have become apparent here: 1. No one has a working Neutron 3rd party testing rig yet which is voting consistently. If I’ve missed something, please, someone correct me. 2. People are still hung on issues around Jenkin

Re: [openstack-dev] a "common" client library

Great idea, fully support it. We’re interested in that too. One specific thing that was mentioned is the ability to mock auth service seems to be very useful for some test scenarios, we came across that recently. Renat Akhmerov @ Mirantis Inc. On 15 Jan 2014, at 14:07, Sylvain Bauza wrote: >

[openstack-dev] [nova] [neutron] PCI pass-through network support

Hi Folks, In light of today's IRC meeting, and for the purpose of moving this forward, I'm fine to go with the following if that's what everyone wants to go with: https://docs.google.com/document/d/1vadqmurlnlvZ5bv3BlUbFeXRS_wh-dsgi5plSjimWjU/edit But with some concerns and reservatio

[openstack-dev] instance migration strangeness in devstack

I think this qualifies as a development question but please let me know if I am wrong. I have been trying to test instance migration in devstack by setting up a multi-node devstack following directions at http://devstack.org/guides/multinode-lab.html. I tested that indeed there were multiple

Re: [openstack-dev] a "common" client library

On Wed, Jan 15, 2014 at 1:37 PM, Doug Hellmann wrote: > Several people have mentioned to me that they are interested in, or > actively working on, code related to a "common" client library -- something > meant to be reused directly as a basis for creating a common library for > all of the openstac

Re: [openstack-dev] Proposal for dd disk i/o performance blueprint of cinder.

On 12/26/2013 01:56 AM, cosmos cosmos wrote: Hello. My name is Rucia for Samsung SDS. I had in truouble in volume deleting. I am developing for supporting big data storage such as hadoop in lvm. it use as a full disk io for deleting of cinder lvm volume because of dd the high disk I/O affec

Re: [openstack-dev] [Nova] why don't we deal with "claims" when live migrating an instance?

Hi Chris. Your thread may have gone unnoticed as it lacked the Nova tag. I've added it to the subject of this reply... that might attract them. :) Excerpts from Chris Friesen's message of 2014-01-15 12:32:36 -0800: > When we create a new instance via _build_instance() or > _build_and_run_instanc

[openstack-dev] [OpenStack-Dev] Third party testing

Hey Everyone, A while back I started talking about this idea of requiring Cinder driver contributors to run a super simple cert script (some info here: [1]). Since then I've been playing with introduction of a third party gate check here in my own lab. My proposal was to have a non-voting check

Re: [openstack-dev] [TripleO][Tuskar] Editing Nodes

Excerpts from James Slagle's message of 2014-01-15 05:07:08 -0800: > I'll start by laying out how I see editing or updating nodes working > in TripleO without Tuskar: > > To do my initial deployment: > 1. I build a set of images for my deployment for different roles. The > images are different ba

Re: [openstack-dev] [rally] Naming of a deployment

On Wed, 2014-01-15 at 21:46 +, Hugh Saunders wrote: > On 15 January 2014 21:14, Ilya Kharin wrote: > > Hi, guys, > > In Rally there is an entity that represents installed instance > of OpenStack. > What you think about a proper name for the entity? (a

Re: [openstack-dev] [qa][python-bindings] Reries on HTTP error in python bindings

Thanks Joe, Good point, gating the clients with monkey-patched clients could become nasty. I'll pursue the "changing the clients" option only then. andrea From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: 15 January 2014 18:01 To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] a "common" client library

Hi Doug, Count me in. Climate is currently working on delivering its first python-climateclient but it would be great if we could leverage any olso lib for this. -Sylvain 2014/1/15 Doug Hellmann > Several people have mentioned to me that they are interested in, or > actively working on, code

Re: [openstack-dev] a "common" client library

On Wed, Jan 15, 2014 at 4:45 PM, Jay Pipes wrote: > On Wed, 2014-01-15 at 14:37 -0500, Doug Hellmann wrote: > > Several people have mentioned to me that they are interested in, or > > actively working on, code related to a "common" client library -- > > something meant to be reused directly as a

Re: [openstack-dev] [rally] Naming of a deployment

On 15 January 2014 21:14, Ilya Kharin wrote: > Hi, guys, > > In Rally there is an entity that represents installed instance of > OpenStack. > What you think about a proper name for the entity? (a Deployment, a > Cluster, an Installation, an Instance or something else) > I vote for Deployment. In

Re: [openstack-dev] a "common" client library

On Wed, 2014-01-15 at 14:37 -0500, Doug Hellmann wrote: > Several people have mentioned to me that they are interested in, or > actively working on, code related to a "common" client library -- > something meant to be reused directly as a basis for creating a common > library for all of the opensta

Re: [openstack-dev] a "common" client library

On Jan 15, 2014, at 1:37 PM, Doug Hellmann wrote: > Several people have mentioned to me that they are interested in, or actively > working on, code related to a "common" client library -- something meant to > be reused directly as a basis for creating a common library for all of the > opensta

Re: [openstack-dev] [TripleO][Tuskar] Editing Nodes

Thanks for the feedback, really good stuff in here :) On 01/15/2014 08:07 AM, James Slagle wrote: I'll start by laying out how I see editing or updating nodes working in TripleO without Tuskar: To do my initial deployment: 1. I build a set of images for my deployment for different roles. The i

[openstack-dev] [rally] Naming of a deployment

Hi, guys, In Rally there is an entity that represents installed instance of OpenStack. There is a set of abstractions in the code such as a database model, an engine which performs an installation and clean up, etc. Currently, the entity called as a Deployment, it has a configuration and a set

Re: [openstack-dev] [neutron] [third-party-testing] Sharing information

On 01/15/2014 05:49 AM, Mathieu Rohon wrote: > Hi, > > does anyone knows if the multi-node environnement is targeted by the > openstack-infra team? The last time multi-node testing was discussed at an -infra meeting was November 26, 2013. [0] The timestamp for the agenda item is 19:47:55 The unde

[openstack-dev] why don't we deal with "claims" when live migrating an instance?

When we create a new instance via _build_instance() or _build_and_run_instance(), in both cases we call instance_claim() to reserve and test for resources. During a cold migration I see us calling prep_resize() which calls resize_claim(). How come we don't need to do something like this when

Re: [openstack-dev] [neutron] [third-party-testing] Sharing information

Hi, Resending on this thread Below are the set of steps we are using for Jenkins setup and would like some clarifications reg some of the steps. Under Jenkins/Configure 1. Source Code Management: to be git and point to the devstack URL 2. Build Triggers: Gerrit Event 3. Build/Execu

[openstack-dev] [savanna] team meeting Jan 16 1800 UTC

Hi folks, We'll be having the Savanna team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Agenda_for_January.2C_16 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Savanna+Meeting&iso=20140116T18 P.S. Alex Ignatov (irc:

Re: [openstack-dev] [savanna] client release 0.4.1

0.4.1 python-savannaclient released. pypi: https://pypi.python.org/pypi/python-savannaclient/0.4.1 tarball: http://tarballs.openstack.org/python-savannaclient/python-savannaclient-0.4.1.tar.gz On Tue, Jan 14, 2014 at 9:41 PM, Sergey Lukjanov wrote: > Ok, looks like everything is ready now for p

Re: [openstack-dev] [devstack] libvirt default log level

On 01/15/2014 02:45 PM, Daniel P. Berrange wrote: > On Wed, Jan 15, 2014 at 01:42:34PM -0500, Sean Dague wrote: >> On 01/15/2014 01:00 PM, Steven Dake wrote: >>> On 01/15/2014 10:28 AM, Daniel P. Berrange wrote: On Wed, Jan 15, 2014 at 09:56:58AM -0700, Steven Dake wrote: > Hi, > >

Re: [openstack-dev] [Ceilometer][Nova] basic setting for notification_driver

On Wed, Jan 15, 2014 at 1:32 PM, ZhiQiang Fan wrote: > Hi, > > When read Ceilometer install guide[1], the multi valued option > notification_driver is set to two drivers, My question is that is the first > one, which means nova.openstack.common.notifier.rpc_notifier, necessary? > what will happen

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

On Wed, Jan 15, 2014 at 1:53 PM, Brant Knudson wrote: > > Here's the process I use to review a oslo-incubator merge... since I'm > mostly reviewing keystone I'm going to use that as the project. > > 1) Make sure keystone master is at the latest, and that oslo-incubator is > at the right level (th

Re: [openstack-dev] [devstack] libvirt default log level

On Wed, Jan 15, 2014 at 01:42:34PM -0500, Sean Dague wrote: > On 01/15/2014 01:00 PM, Steven Dake wrote: > > On 01/15/2014 10:28 AM, Daniel P. Berrange wrote: > >> On Wed, Jan 15, 2014 at 09:56:58AM -0700, Steven Dake wrote: > >>> Hi, > >>> > >>> Ken'ichi Omichi submitted a change [1] in devstack t

Re: [openstack-dev] [oslo] need input on new config option for logging translations

Based on the discussion with the other PTLs at the release meeting yesterday, I'm going to recommend that we create an example logging.conf file and documentation to go with it, and not add the new option. Doug On Wed, Jan 15, 2014 at 12:00 PM, Brant Knudson wrote: > > It might help if we knew

[openstack-dev] a "common" client library

Several people have mentioned to me that they are interested in, or actively working on, code related to a "common" client library -- something meant to be reused directly as a basis for creating a common library for all of the openstack clients to use. There's a blueprint [1] in oslo, and I believ

Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

I don't necessarily disagree with this assertion, but what this could lead to is a proliferation of a bunch of very similar images. Templatizing some of the attributes (e.g., this package is enabled, that one isn't) can reduce the potential explosion of images stored in glance. If that's a conce

Re: [openstack-dev] [trove][mistral] scheduled tasks

Greg, Looks like I missed your last email in an email storm after NY holidays but now was able to see it accidentally. So answering your question about Mistral incubation your concern is valid. We’re currently working on moving Mistral into incubation and we’ll keep you (and others) posted on t

Re: [openstack-dev] writing comments as complete sentences

I absolutely agree with that. Honestly, I don’t even understand why it can be different (not compliant with regular grammar rules). Comments are supposed to clarify things so they should be worded very clearly and read as normal English sentences. Additionally it’s one of the small bricks that t

[openstack-dev] [Neutron][3rd Party Testing] Jenkins setup

Hi, Below are the set of steps we are using for Jenkins setup and would like some clarifications reg some of the steps. Under Jenkins/Configure 1. Source Code Management: to be git and point to the devstack URL 2. Build Triggers: Gerrit Event 3. Build/Execute Shell: Sequence of commands

Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

Excerpts from Walls, Jeffrey Joel (Cloud OS R&D)'s message of 2014-01-15 07:04:48 -0800: > > -Original Message- > > From: James Slagle [mailto:james.sla...@gmail.com] > > Sent: Wednesday, January 15, 2014 5:52 AM > > To: OpenStack Development Mailing List (not for usage questions) > > Subj

Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py

Here's the process I use to review a oslo-incubator merge... since I'm mostly reviewing keystone I'm going to use that as the project. 1) Make sure keystone master is at the latest, and that oslo-incubator is at the right level (the commit hash if they mentioned it or latest) 2) run update.py in o

Re: [openstack-dev] [Ironic] [TripleO] [Tuskar] Deployment Management section - Wireframes

Excerpts from Jiří Stránský's message of 2014-01-13 07:45:53 -0800: > On 13.1.2014 11:43, Jaromir Coufal wrote: > > On 2014/10/01 21:17, Jay Dobies wrote: > >> Another question: > >> > >> - A Role (sounds like we're moving away from that so I'll call it > >> Resource Category) can have multiple Nod

Re: [openstack-dev] [TripleO] [Tuskar] Deployment Management section - Wireframes

Excerpts from Jaromir Coufal's message of 2014-01-15 02:05:52 -0800: > > 1) Check for an already deleted server before deleting any. This is > > related to stack convergence: > > > > https://blueprints.launchpad.net/heat/+spec/stack-convergence > > > > This will allow users to just delete a server

Re: [openstack-dev] [devstack] libvirt default log level

On 01/15/2014 01:00 PM, Steven Dake wrote: > On 01/15/2014 10:28 AM, Daniel P. Berrange wrote: >> On Wed, Jan 15, 2014 at 09:56:58AM -0700, Steven Dake wrote: >>> Hi, >>> >>> Ken'ichi Omichi submitted a change [1] in devstack to change the >>> default log level to 1 for libvirt. This results in co

[openstack-dev] [OpenStack-Dev][Cinder] Unable to run cinder_driver_cert.sh

A number of folks have contacted me and stated that they couldn't get the newly added cinder certification script to run. I looked into it this morning, sdague pointed out that tempest/run_tests.sh was modified a little while back and it turns out that was the source of the problem. I've logged a

Re: [openstack-dev] [ironic] Disk Eraser

On Wed, Jan 15, 2014 at 11:25 AM, Alan Kavanagh wrote: > Cheers Guys > > > > So what would you recommend Oleg. Yes its for linux system. > > > > /Alan > > > > From: Oleg Gelbukh [mailto:ogelb...@mirantis.com] > Sent: January-15-14 10:30 AM > To: OpenStack Development Mailing List (not for usage qu

Re: [openstack-dev] [gantt] Sync up patches

My thought was to try and get some parallel effort going, do the resync as a continuing task as suffer a little ongoing pain versus a large amount of pain at the end. Given that the steps for a resync are the same no matter when we do it waiting until the end is acceptable. >From a `just do it

[openstack-dev] [Ceilometer][Nova] basic setting for notification_driver

Hi, When read Ceilometer install guide[1], the multi valued option notification_driver is set to two drivers, My question is that is the first one, which means nova.openstack.common.notifier.rpc_notifier, necessary? what will happen if it is removed? Note, it is not configured even in Nova instal

Re: [openstack-dev] [ironic] Disk Eraser

Cheers Guys So what would you recommend Oleg. Yes its for linux system. /Alan From: Oleg Gelbukh [mailto:ogelb...@mirantis.com] Sent: January-15-14 10:30 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [ironic] Disk Eraser On Wed, Jan 15, 2014 a

Re: [openstack-dev] [devstack] libvirt default log level

On 01/15/2014 10:13 AM, David Kranz wrote: On 01/15/2014 11:56 AM, Steven Dake wrote: Hi, Ken'ichi Omichi submitted a change [1] in devstack to change the default log level to 1 for libvirt. This results in continual spam to /var/log/messages in my development system, even after exiting dev

Re: [openstack-dev] [qa][python-bindings] Reries on HTTP error in python bindings

Frittoli, I don't think that this is a good idea. Because the main role of tempest is to ensure that cloud works. So if it doesn't work we should change something in deployment configuration or code to fix it. Not just hide with monkey patches in tempest. Probably you should try to implement ret

Re: [openstack-dev] Meeting time congestion

On Wed, Jan 15, 2014 at 8:49 AM, Sergey Lukjanov wrote: > Looks like lbaas meeting is still alive: > > from eavesdrop: > > neutron_lbaas - 09-Jan-2014 14:01 > neutron_lbaas_subteam_meeting - 05-Dec-2013 14:00 > nuetron_lbaas - 28-Nov-2013 14:02 > Thanks for the correction, that leaves 3 possibly

Re: [openstack-dev] [devstack] libvirt default log level

On 01/15/2014 10:28 AM, Daniel P. Berrange wrote: On Wed, Jan 15, 2014 at 09:56:58AM -0700, Steven Dake wrote: Hi, Ken'ichi Omichi submitted a change [1] in devstack to change the default log level to 1 for libvirt. This results in continual spam to /var/log/messages in my development system,

Re: [openstack-dev] [devstack] libvirt default log level

On Wed, Jan 15, 2014 at 11:35 AM, Daniel P. Berrange wrote: > > I see that something close to this has already been added to devstack: > > https://review.openstack.org/#/c/65834/2/lib/nova > > which is the right way to tailor logging levels. > > So we should definitely revert https://review.opens

Re: [openstack-dev] [qa][python-bindings] Reries on HTTP error in python bindings

On Wed, Jan 15, 2014 at 5:28 AM, Frittoli, Andrea (Cloud Services) < fritt...@hp.com> wrote: > Hi all, > > > > I’ve been working on a patch to ensure that all tempest tests are able to > handle rate limiting errors with automatic retries [0]. > > API tests already implement retries, however scenar

Re: [openstack-dev] [Neutron] Partially Shared Networks

- Original Message - > From: "PAUL CARVER" > To: OpenStack-dev@lists.openstack.org > Sent: Wednesday, January 15, 2014 6:52:32 AM > Subject: [openstack-dev] [Neutron] Partially Shared Networks > > > > The particular use case I have in mind concerns networks that could > technically be cr

[openstack-dev] [oslo] our notes from the icehouse summit

I've finally posted the notes we took at the icehouse summit for various fixes needed to individual modules in Oslo [1]. It would be a great help if maintainers would take a quick look through the notes and open bugs for the items in your module(s), but I will try to make some time to do that next

Re: [openstack-dev] [oslo] dependency analysis for graduating more oslo libraries

On Wed, Jan 15, 2014 at 11:49 AM, Joshua Harlow wrote: > Very nice write up +1 > > A question, many modules are pulling in oslo.log as seen from the > dependency graph which itself then pulls in oslo.config. Is the plan to > just have all these modules use the regular python logging and have > o

Re: [openstack-dev] [devstack] libvirt default log level

On 2014-01-15 11:13, David Kranz wrote: > On 01/15/2014 11:56 AM, Steven Dake wrote: > >> Hi, >> >> Ken'ichi Omichi submitted a change [1] in devstack to change the default log >> level to 1 for libvirt. This results in continual spam to /var/log/messages >> in my development system, even

Re: [openstack-dev] [devstack] libvirt default log level

On Wed, Jan 15, 2014 at 09:56:58AM -0700, Steven Dake wrote: > Hi, > > Ken'ichi Omichi submitted a change [1] in devstack to change the > default log level to 1 for libvirt. This results in continual spam > to /var/log/messages in my development system, even after exiting > devstack. The spam lo

Re: [openstack-dev] [devstack] libvirt default log level

On Wed, Jan 15, 2014 at 05:28:07PM +, Daniel P. Berrange wrote: > On Wed, Jan 15, 2014 at 09:56:58AM -0700, Steven Dake wrote: > > Agreed, it is complete insanity to set 'log_level=1' on *any* hosts. > The level of debug info that generates is so enourmous that you'd > never wanted to look at

[openstack-dev] [Neturon] firewall_driver and ML2 and vif_security discussion

Hi folks Security group for OVS agent (ovs plugin or ML2) is being broken. so we need vif_security port binding to fix this (https://review.openstack.org/#/c/21946/) We got discussed about the architecture for ML2 on ML2 weekly meetings, and I wanna continue discussion in here. Here is my propos

Re: [openstack-dev] [gantt] Sync up patches

On Wed, Jan 15, 2014 at 8:52 AM, Dugger, Donald D wrote: > The current thought is that I will do the work to backport any change > that are made to the nova tree that overlap the gantt tree. I don’t see > this as an impossible task. Yes it will get harder as we make specific > changes to gantt

Re: [openstack-dev] [devstack] libvirt default log level

+1 for your change. I've been hit by the very same issue today. Simon On 15/01/2014 17:56, Steven Dake wrote: Hi, Ken'ichi Omichi submitted a change [1] in devstack to change the default log level to 1 for libvirt. This results in continual spam to /var/log/messages in my development system,

  1   2   >