Re: [openstack-dev] [Heat] core team changes

+1 Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com On Wed, Jan 28, 2015 at 8:26 AM, Thomas Herve wrote: > > > Hi all > > > > After having a look at the stats: > > http://stackalytics.com/report/contribution/heat-group/90 > > http://stackalytics.com/?module=heat-group&metric

Re: [openstack-dev] [Fuel] Getting rid of kickstart/preseed for all NEW releases

Gentlemen, I have one small question about IBP, and I'm not sure if this is the right place to ask, but still: how do you plan to build the images for the image-based provisioning? Will you leverage diskimage-builder or some other tool? Thanks, -

Re: [openstack-dev] [nova] The constraints from flavor and image metadata

Hi, Travis Thanks for your reply. I think I'm more talking about the resource constraints instead of behavior constraints. My example like serial_port_count, memory_pagesize, hw_numa_nodes etc are all requires resources. Sorry for the confusion. If image property requires resource that

Re: [openstack-dev] [nova] The constraints from flavor and image metadata

Sorry for slow response, this mail is lost in the mail flood. For the pre-datastructure code, I think there have been some discussion on it, like https://wiki.openstack.org/wiki/VirtDriverImageProperties or https://bugs.launchpad.net/nova/+bug/1275875 . But I do agree that we should enhance it

Re: [openstack-dev] [Heat] core team changes

> Hi all > > After having a look at the stats: > http://stackalytics.com/report/contribution/heat-group/90 > http://stackalytics.com/?module=heat-group&metric=person-day > > I'd like to propose the following changes to the Heat core team: > > Add: > Qiming Teng > Huang Tianhua > > Remove: > Ba

Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

+1 From: Michael Still [mi...@stillhq.com] Sent: Tuesday, January 27, 2015 5:41 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core Greetings, I would like to nominate Melanie W

Re: [openstack-dev] [devstack] Installation problem

Hi Rajdeep, This may be because of some configuration mismatch. I had same ImportError while uploading my Cinder Driver during devstack installation, so to deal with that I have rechecked my logs again and found that the mistake was in my cinder.conf file, so I think that might be the same case wi

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

On 1/15/2015 5:41 PM, Sean Dague wrote: On 01/15/2015 06:25 PM, Joe Gordon wrote: We can side step the dependency graphing and ordering issue by looking at the list of curently installed packages via pip freeze and not installing dependencies (pip install --no-deps) After looking into this fu

Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

On 1/27/2015 4:41 PM, Michael Still wrote: Greetings, I would like to nominate Melanie Witt for the python-novaclient-core team. (What is python-novaclient-core? Its a new group which will contain all of nova-core as well as anyone else we think should have core reviewer powers on just the py

Re: [openstack-dev] [Manila]Questions about using not handle share-servers drivers with "Flat network"

On 01/27/2015 06:39 PM, Li, Chen wrote: Hi list, I have some questions. Hope can get help from you guys. Manila has two driver modes. For handle share server drivers, the share-network is easy to understand. For not handle share-servers drivers, manila request admin to do everything before

Re: [openstack-dev] oslo.messaging 1.6.0 released

On 1/27/2015 8:17 PM, Armando M. wrote: Is there any chance that this release might have caused bug [1]? I am still root-causing what's going on...any input highly appreciated. Thanks, Armando [1] https://bugs.launchpad.net/grenade/+bug/1415284 On 27 January 2015 at 14:23, Doug Hellmann mail

Re: [openstack-dev] [Heat] core team changes

+1 On 28/01/15 14:36, Angus Salkeld wrote: Hi all After having a look at the stats: http://stackalytics.com/report/contribution/heat-group/90 http://stackalytics.com/?module=heat-group&metric=person-day I'd like to propose the following changes to the Heat core team: Add: Qiming Teng Huang Ti

Re: [openstack-dev] [OpenStack Foundation] [tc] Take back the naming process

Lauren Sell writes: > Hey Monty, > > I’d like to weigh in here, because I think there have been some > misunderstandings around Lemming-gate. I’m glad you raised your > concerns; it’s a good test of release naming for us all to discuss and > learn from. > > To provide a little context for those n

[openstack-dev] [neutron] Question about VPNaas

Hi Stacker: I am a novice, I want use Neutron VPNaas, through my preliminary understanding on this it, I have two questions about it: (1) why a 'vpnservices' can just has one subnet? (2) why the subnet of 'vpnservices' can't be changed? As I know, the OpenSwan does not

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

Hi Sean, Thanks for the heads up, and for adding the stable-compat-jobs to the client. [1] This is an interesting problem, since the proposal bot keeps the python-barbicanclient requirements in sync with global-requirements. I’m not sure what the correct fix for this is? - Doug [1] https://

Re: [openstack-dev] oslo.messaging 1.6.0 released

Is there any chance that this release might have caused bug [1]? I am still root-causing what's going on...any input highly appreciated. Thanks, Armando [1] https://bugs.launchpad.net/grenade/+bug/1415284 On 27 January 2015 at 14:23, Doug Hellmann wrote: > There were some issues with the build

Re: [openstack-dev] [OpenStack Foundation] [tc] Take back the naming process

Hey Monty, I’d like to weigh in here, because I think there have been some misunderstandings around Lemming-gate. I’m glad you raised your concerns; it’s a good test of release naming for us all to discuss and learn from. To provide a little context for those new to the discussion, historicall

Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

> -Original Message- > From: Michael Still [mailto:mi...@stillhq.com] > Sent: Wednesday, January 28, 2015 7:41 AM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [nova] Nominating Melanie Witt for > python-novaclient-core > > Greetings, > > I would like to nominate Me

[openstack-dev] [Heat] core team changes

Hi all After having a look at the stats: http://stackalytics.com/report/contribution/heat-group/90 http://stackalytics.com/?module=heat-group&metric=person-day I'd like to propose the following changes to the Heat core team: Add: Qiming Teng Huang Tianhua Remove: Bartosz Górski (Bartosz has ind

Re: [openstack-dev] [nova] Requesting FFE for opencontrail-nova-vif-driver-plugin

Hi John Thank you so much. My apologies for bp isn't lined for review, I have used wrong git format. It's fixed now. Best Nachi 2015-01-28 2:39 GMT+09:00 John Garbutt : > Hi, > > Apologies, we can re-approve that because your code was up before the > deadline. > > I was unable to do that yester

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

On 01/27/2015 05:21 PM, Sean Dague wrote: > On 01/27/2015 03:55 PM, Douglas Mendizabal wrote: >> Hi openstack-dev, >> >> The barbican team would like to announce the release of >> python-barbicanclient 3.0.2. This is a minor release that fixes a bug >> in the pbr versioning that was preventing the

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

On 01/27/2015 03:55 PM, Douglas Mendizabal wrote: > Hi openstack-dev, > > The barbican team would like to announce the release of > python-barbicanclient 3.0.2. This is a minor release that fixes a bug > in the pbr versioning that was preventing the client from working correctly. > > The release

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

Btw try this on 'pip<6' (for those that want to); Pip 6+ moved some of the code around that this uses; for feel to update it though and adjust it to find where the new stuff is :-P Joshua Harlow wrote: Here is one that is more complete: https://gist.github.com/harlowja/e22e8c0771b336ca392f U

Re: [openstack-dev] [tc] Take back the naming process

On 01/27/2015 06:05 PM, Jonathan Bryce wrote: > >> On Jan 27, 2015, at 3:50 PM, Monty Taylor wrote: >> >> I do not like how we are selecting names for our releases right now. >> The current process is autocratic and opaque and not fun - which is the >> exact opposite of what a community selected

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

Here is one that is more complete: https://gist.github.com/harlowja/e22e8c0771b336ca392f Using a really simple requirement set that will not work: $ cat test.txt taskflow networkx<1.5 Running the above gist on that (and waiting for a while; since it does do a lot of backtracking and trying of

[openstack-dev] [Manila]Questions about using not handle share-servers drivers with "Flat network"

Hi list, I have some questions. Hope can get help from you guys. Manila has two driver modes. For handle share server drivers, the share-network is easy to understand. For not handle share-servers drivers, manila request admin to do everything before manila-share service start, and when the serv

Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

On Tue, Jan 27, 2015 at 3:52 PM, Sean Dague wrote: > On 01/27/2015 02:41 PM, Michael Still wrote: > > Greetings, > > > > I would like to nominate Melanie Witt for the python-novaclient-core > team. > > > > (What is python-novaclient-core? Its a new group which will contain > > all of nova-core as

Re: [openstack-dev] [nova] novaclient support for V2.1 micro versions

As I understand it, novaclient would by default not pass the microversion HTTP header (X-OpenStack-Compute-API-Version) so it would get the server's MIN_VERSION, ie 2.1 for the foreseeable future. It would be straightforward to add something like a --api-version=xx command line argument, or it mig

[openstack-dev] [barbican] python-barbicanclient 3.0.2 released

Hi openstack-dev, The barbican team would like to announce the release of python-barbicanclient 3.0.2. This is a minor release that fixes a bug in the pbr versioning that was preventing the client from working correctly. The release is available on PyPI https://pypi.python.org/pypi/python-bar

Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

On 01/27/2015 02:41 PM, Michael Still wrote: > Greetings, > > I would like to nominate Melanie Witt for the python-novaclient-core team. > > (What is python-novaclient-core? Its a new group which will contain > all of nova-core as well as anyone else we think should have core > reviewer powers on

Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

+1 -Original Message- From: Dan Smith [mailto:d...@danplanet.com] Sent: Tuesday, January 27, 2015 3:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core > Please respond with +1s or

Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

> Please respond with +1s or any concerns. +1 --Dan signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.or

Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

On Wed, Jan 28, 2015 at 9:11 AM, Michael Still wrote: > Greetings, > > I would like to nominate Melanie Witt for the python-novaclient-core team. > > (What is python-novaclient-core? Its a new group which will contain > all of nova-core as well as anyone else we think should have core > reviewer

Re: [openstack-dev] [tc] Take back the naming process

> On Jan 27, 2015, at 3:50 PM, Monty Taylor wrote: > > I do not like how we are selecting names for our releases right now. > The current process is autocratic and opaque and not fun - which is the > exact opposite of what a community selected name should be. Autocratic? Could you elaborate?

Re: [openstack-dev] [Fuel] Cluster replaced deployment of provisioning information

On Tue, Jan 27, 2015 at 10:47 AM, Vladimir Kuklin wrote: > This is an interesting topic. As per our discussions earlier, I suggest > that in the future we move to different serializers for each granule of our > deployment, so that we do not need to drag a lot of senseless data into > particular t

Re: [openstack-dev] [Fuel] Cluster replaced deployment of provisioning information

On Thu, Jan 22, 2015 at 7:59 PM, Evgeniy L wrote: > The problem with merging is usually it's not clear how system performs > merging. > For example you have the next hash {'list': [{'k': 1}, {'k': 2}, {'k': > 3}]}, and I want > {'list': [{'k': 4}]} to be merged, what system should do? Replace the

Re: [openstack-dev] [tc] Take back the naming process

Monty Taylor writes: > I do not like how we are selecting names for our releases right now. > The current process is autocratic and opaque and not fun - which is the > exact opposite of what a community selected name should be. > > I propose: > > * As soon as development starts on release X, we o

[openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

Greetings, I would like to nominate Melanie Witt for the python-novaclient-core team. (What is python-novaclient-core? Its a new group which will contain all of nova-core as well as anyone else we think should have core reviewer powers on just the python-novaclient code). Melanie has been involv

[openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

Hello all, You may know that for deployment configuration we are serializing additional prefix for controller role (primary), with the goal of deployment order control (primary-controller always should be deployed before secondaries) and some condiions in fuel-library code. However, we cannot gua

Re: [openstack-dev] [nova] [api] Get servers with limit and IP address filter

The network info for an instance is cached as a blob of data (neutron has the canonical version in most installs), so it isn’t particularly easy to do at the database layer. You would likely need a pretty complex stored procedure to do it accurately. Vish On Jan 27, 2015, at 2:00 PM, Steven Ka

Re: [openstack-dev] [tc] Take back the naming process

On 01/27/2015 05:19 PM, Jim Meyer wrote: +1 all the way down. More fun double-plus-good. —j On Jan 27, 2015, at 1:50 PM, Monty Taylor wrote: I do not like how we are selecting names for our releases right now. The current process is autocratic and opaque and not fun - which is the exact opp

Re: [openstack-dev] [tc] Take back the naming process

++ absolutely! Sent via mobile > On Jan 27, 2015, at 14:19, Jim Meyer wrote: > > +1 all the way down. > > More fun double-plus-good. > > —j > >> On Jan 27, 2015, at 1:50 PM, Monty Taylor wrote: >> >> I do not like how we are selecting names for our releases right now. >> The current proce

Re: [openstack-dev] oslo.messaging 1.6.0 released

There were some issues with the build job, so this release has just gone live. I apologize for the delay. Doug On Tue, Jan 27, 2015, at 02:05 PM, Doug Hellmann wrote: > The Oslo team is pleased to announce the release of: > > oslo.messaging 1.6.0: Oslo Messaging API > > The primary reason for t

Re: [openstack-dev] [tc] Take back the naming process

+1 all the way down. More fun double-plus-good. —j > On Jan 27, 2015, at 1:50 PM, Monty Taylor wrote: > > I do not like how we are selecting names for our releases right now. > The current process is autocratic and opaque and not fun - which is the > exact opposite of what a community selected

Re: [openstack-dev] [Fuel] removing single mode

> not to prolong single mode, I'd like to see it die. However we will > need to be able to add, change, remove, or noop portions of the tasks > graph in the future. Many of the plugins that cant currently be built > would rely on being able to sub out parts of the graph. How is that > going to fact

Re: [openstack-dev] [tc] Take back the naming process

On Tue, Jan 27, 2015 at 1:50 PM, Monty Taylor wrote: > I do not like how we are selecting names for our releases right now. > The current process is autocratic and opaque and not fun - which is the > exact opposite of what a community selected name should be. > > ++ > I propose: > > * As soon a

[openstack-dev] [nova] [api] Get servers with limit and IP address filter

Hello, When applying an IP address filter to a paginated servers query (eg, supplying servers/detail?ip=192.168&limit=100), the IP address filtering is only being applied against the non-filtered page of servers that were retrieved from the DB; see [1]. I believe that the IP address filtering s

[openstack-dev] [tc] Take back the naming process

I do not like how we are selecting names for our releases right now. The current process is autocratic and opaque and not fun - which is the exact opposite of what a community selected name should be. I propose: * As soon as development starts on release X, we open the voting for the name of rele

Re: [openstack-dev] [Openstack-operators] [openstack-operators] [Keystone] flush expired tokens and moves deleted instance

The problem with running in memcached is now you have to keep _EVERY_ token in RAM. This is not any cheaper than cleaning out a giant on-disk table. Also worth noting is that memcached can produce frustrating results unless you run it with -M. That is because without -M, your tokens may be removed

Re: [openstack-dev] [Swift] Swift GUI (free or open source)?

https://github.com/cschwede/django-swiftbrowser is done by a swift core dev You should browse: http://docs.openstack.org/developer/swift/associated_projects.html#associated-projects On Mon, Jan 26, 2015 at 11:50 AM, Adam Lawson wrote: > I'm researching for a web-based visualization that simply

Re: [openstack-dev] required libvirtd/qemu versions for numa support?

On 01/26/2015 05:37 PM, Jay Pipes wrote: On 01/26/2015 07:33 AM, Chris Friesen wrote: Hi, I'm interested in the recent work around NUMA support for guest instances (https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement), but I'm having some difficulty figuring out what versions

Re: [openstack-dev] [oslo.messaging] Performance testing. Initial steps.

On 01/27/2015 06:31 PM, Doug Hellmann wrote: On Tue, Jan 27, 2015, at 12:28 PM, Denis Makogon wrote: I'd like to build tool that would be able to profile messaging over various deployments. This "tool" would give me an ability to compare results of performance testing produced by native tools an

[openstack-dev] [Telco][NFV] Meeting reminder - Wednesday 28th @ 1400 UTC in #openstack-meeting-alt

Hi all, Just a friendly reminder that this week's OpenStack Telco Working Group meeting is tomorrow, Wednesday the 28th, at 1400 UTC in #openstack-meeting-alt. Please add any items you wish to discuss to the agenda at: https://etherpad.openstack.org/p/nfv-meeting-agenda Marc Koderer has ki

Re: [openstack-dev] [cinder] [nova] [scheduler] Nova node name passed to Cinder

On Jan 26, 2015, at 10:16 PM, Philipp Marek wrote: > Hello Vish, > >> Nova passes ip, iqn, and hostname into initialize_connection. That should >> give you the info you need. > thank you, but that is on the _Nova_ side. > > I need to know that on the Cinder node already: > >>> For that the c

Re: [openstack-dev] [Fuel] Getting rid of kickstart/preseed for all NEW releases

I don't see this as crazy, it's not a feature of the cloud, its a mechanism to get us there. It's not even something that most of the time anyone sees. Continuing to waste time supporting something we are ready to replace, and have been testing for a release already is crazy. It adds to the technic

Re: [openstack-dev] [Fuel] removing single mode

not to prolong single mode, I'd like to see it die. However we will need to be able to add, change, remove, or noop portions of the tasks graph in the future. Many of the plugins that cant currently be built would rely on being able to sub out parts of the graph. How is that going to factor into gr

Re: [openstack-dev] [keystone] Flush expired tokens automatically ?

Thanks Adam, Thierry! Dani On Tue, Jan 27, 2015 at 1:43 PM, Adam Young wrote: > Short term answers: > > The amount of infrastructure we would have to build to replicate CRON is > not worth it. > > Figuring out a CRON strategy for nontrivial deployment is part of a larger > data management schem

[openstack-dev] oslo.messaging 1.6.0 released

The Oslo team is pleased to announce the release of: oslo.messaging 1.6.0: Oslo Messaging API The primary reason for this release is to move the code out of the oslo namespace package as part of https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages This release also inclu

Re: [openstack-dev] [Policy][Group-based-policy] Policy violations investigation

Hi Ariel, This is indeed one of the use cases that is very relevant to, and can be supported, with the GBP model. The GBP policy actions provide a way to “redirect” to a service-instance/chain on matching a traffic classifier. If you are able to represent the “honeypot” functionality as a Neutron

Re: [openstack-dev] [keystone] Flush expired tokens automatically ?

Short term answers: The amount of infrastructure we would have to build to replicate CRON is not worth it. Figuring out a CRON strategy for nontrivial deployment is part of a larger data management scheme. Long term answers: Tokens should not be persisted. We have been working toward eph

Re: [openstack-dev] [Openstack-operators] [openstack-operators] [Keystone] flush expired tokens and moves deleted instance

This is one reason to use the memcached backend. Why replicate these tokens in the first place. On Tuesday, January 27, 2015 at 10:21 AM, Clint Byrum wrote: > > Excerpts from Tim Bell's message of 2015-01-25 22:10:10 -0800: > > This is often mentioned as one of those items which catches every

Re: [openstack-dev] [oslo.messaging] Performance testing. Initial steps.

On Tue, Jan 27, 2015, at 12:28 PM, Denis Makogon wrote: > On Tue, Jan 27, 2015 at 7:15 PM, Doug Hellmann > wrote: > > > > > > > On Tue, Jan 27, 2015, at 10:56 AM, Denis Makogon wrote: > > > On Thu, Jan 15, 2015 at 8:56 PM, Doug Hellmann > > > wrote: > > > > > > > > > > > > On Jan 15, 2015, at

Re: [openstack-dev] [Openstack-operators] [openstack-operators] [Keystone] flush expired tokens and moves deleted instance

Excerpts from Tim Bell's message of 2015-01-25 22:10:10 -0800: > This is often mentioned as one of those items which catches every OpenStack > cloud operator at some time. It's not clear to me that there could not be a > scheduled job built into the system with a default frequency (configurable,

Re: [openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

On Tue, Jan 27, 2015, at 12:44 PM, Julien Danjou wrote: > On Tue, Jan 27 2015, Clark Boylan wrote: > > > So the issue is that the garbage collector segfaults on null objects in > > the to be garbage collected list. Which means that by the time garbage > > collection breaks you don't have the inf

Re: [openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

On Tue, Jan 27, 2015, at 12:06 PM, victor stinner wrote: > Hi, > > What is the Python bug? Do you have a reference to the bug report and the > patch? http://bugs.python.org/issue21435 > > Python 3.4.3 release schedule: > "3.4.3rc1 will be tagged Saturday February 7 and released Sunday Februar

Re: [openstack-dev] [Telco][NFV] Meeting facilitator for January 28th

- Original Message - > From: "Marc Koderer" > To: "OpenStack Development Mailing List (not for usage questions)" > > > Hi Steve, > > I can host it. > > Regards > Marc Thanks Marc! __ OpenStack Development Mailin

Re: [openstack-dev] [tc] do we really need project tags in the governance repository?

Excerpts from Thierry Carrez's message of 2015-01-27 02:46:03 -0800: > Doug Hellmann wrote: > > On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote: > > [...] > >> I'm open to alternative suggestions on where the list of tags, their > >> definition and the list projects they apply to should liv

[openstack-dev] [neutron][lbaas] meeting canceled next week (2/3)

Since most of us will be at the lbaas mid-cycle, next week’s meeting is canceled. Thanks, Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un

Re: [openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

On Tue, Jan 27 2015, Clark Boylan wrote: > So the issue is that the garbage collector segfaults on null objects in > the to be garbage collected list. Which means that by the time garbage > collection breaks you don't have the info you need to know what > references lead to the segfault. I spent a

Re: [openstack-dev] [nova] Requesting FFE for opencontrail-nova-vif-driver-plugin

Hi, Apologies, we can re-approve that because your code was up before the deadline. I was unable to do that yesterday as the code was not linked in the blueprint whiteboard at that time, so it looked like there was no code up for review. Apologies, its a gap in the tooling. Please try to make sur

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

On 01/27/2015 08:14 AM, Daniel P. Berrange wrote: > On Tue, Jan 27, 2015 at 07:12:29AM -0800, Sean Dague wrote: >> On 01/27/2015 12:18 AM, Silvan Kaiser wrote: >>> Hello! >>> Do dependencies required only in some contexts belong into requirements.txt? >>> >>> Yesterday we had a short discussion on

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

On 01/27/2015 09:13 AM, Silvan Kaiser wrote: Am 27.01.2015 um 16:51 schrieb Jay Pipes : b) The Glance API image cache can use xattr if SQLite is not desired [1], and Glance does *not* list xattr as a dependency in requirements.txt. Swift also has a dependency on python-xattr [2]. So, this particu

Re: [openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

On Tue, Jan 27, 2015, at 09:13 AM, Julien Danjou wrote: > On Tue, Jan 27 2015, Doug Hellmann wrote: > > > The infra team has been working hard to update our Python 3 testing for all > > projects to run on 3.4 instead of 3.3. Two of the last projects to be able > > to > > shift are oslo.messagin

Re: [openstack-dev] [oslo.messaging] Performance testing. Initial steps.

On Tue, Jan 27, 2015 at 7:15 PM, Doug Hellmann wrote: > > > On Tue, Jan 27, 2015, at 10:56 AM, Denis Makogon wrote: > > On Thu, Jan 15, 2015 at 8:56 PM, Doug Hellmann > > wrote: > > > > > > > > > On Jan 15, 2015, at 1:30 PM, Denis Makogon > > > wrote: > > > > > > > > Good day to All, > > > > >

Re: [openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

On Tue, Jan 27, 2015, at 09:06 AM, victor stinner wrote: > Hi, > > What is the Python bug? Do you have a reference to the bug report and the > patch? > https://bugs.launchpad.net/ubuntu/trusty/+source/python3.4/+bug/1367907 Is the bug I filed with the ubuntu package and it has links back to the

Re: [openstack-dev] [Openstack-operators] [openstack-operators]flush expired tokens and moves deleted instance

On 01/28/2015 01:13 AM, Fischer, Matt wrote: > Our keystone database is clustered across regions, so we have this job > running on node1 in each site on alternating hours. I don’t think you’d > want a bunch of cron jobs firing off all at once to cleanup tokens on > multiple clustered nodes. That’

Re: [openstack-dev] [oslo.messaging] Performance testing. Initial steps.

On Tue, Jan 27, 2015, at 10:56 AM, Denis Makogon wrote: > On Thu, Jan 15, 2015 at 8:56 PM, Doug Hellmann > wrote: > > > > > > On Jan 15, 2015, at 1:30 PM, Denis Makogon > > wrote: > > > > > > Good day to All, > > > > > > The question that i’d like to raise here is not simple one, so i’d like >

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

> Am 27.01.2015 um 16:51 schrieb Jay Pipes : > […snip...] > a) I agree with Sean and Matt here that this is an optional dependency and > belongs in the deployment documentation and configuration management manifests > > b) The Glance API image cache can use xattr if SQLite is not desired [1],

Re: [openstack-dev] [tc] do we really need project tags in the governance repository?

On Tue, Jan 27, 2015, at 05:46 AM, Thierry Carrez wrote: > Doug Hellmann wrote: > > On Mon, Jan 26, 2015, at 12:02 PM, Thierry Carrez wrote: > > [...] > >> I'm open to alternative suggestions on where the list of tags, their > >> definition and the list projects they apply to should live. If you

Re: [openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

On Tue, Jan 27 2015, Doug Hellmann wrote: > The infra team has been working hard to update our Python 3 testing for all > projects to run on 3.4 instead of 3.3. Two of the last projects to be able to > shift are oslo.messaging and oslo.rootwrap. The test suites for both projects > trigger a segfau

Re: [openstack-dev] [nova] Mumble server for the mid-cycle meetup

Today's hangout: https://plus.google.com/hangouts/_/gwjbog3l3omtk2f4tt5s5v4hn4a Michael On Tue, Jan 27, 2015 at 9:11 AM, Michael Still wrote: > For reference, that's because we were having lunch. It seems to be > working well again. > > Michael > > On Tue, Jan 27, 2015 at 7:24 AM, Robert Collin

Re: [openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

Hi, What is the Python bug? Do you have a reference to the bug report and the patch? Python 3.4.3 release schedule: "3.4.3rc1 will be tagged Saturday February 7 and released Sunday February 8. 3.4.3 final will follow two weeks later, tagged Saturday February 21 and released Sunday February 22.

Re: [openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

Doug Hellmann wrote: > The infra team has been working hard to update our Python 3 testing for all > projects to run on 3.4 instead of 3.3. Two of the last projects to be able to > shift are oslo.messaging and oslo.rootwrap. The test suites for both projects > trigger a segfault bug in the 3

Re: [openstack-dev] [oslo][heat] potentially breaking release of oslo.messaging Tuesday 27th

On Mon, Jan 26, 2015, at 06:57 PM, Angus Salkeld wrote: > On Tue, Jan 27, 2015 at 8:05 AM, Doug Hellmann > wrote: > > > We’ve held up the oslo.messaging release with the namespace package work > > for a while now while we work with the nova, designate, and heat teams to > > fix things up so the

[openstack-dev] [oslo] temporarily disabling python 3.x testing for oslo.messaging and oslo.rootwrap

The infra team has been working hard to update our Python 3 testing for all projects to run on 3.4 instead of 3.3. Two of the last projects to be able to shift are oslo.messaging and oslo.rootwrap. The test suites for both projects trigger a segfault bug in the 3.4 interpreter as it is shipped o

Re: [openstack-dev] [Fuel] removing single mode

+1, long awaited > On 27 Jan 2015, at 14:05, Aleksandr Didenko wrote: > > Hi, > > After starting implementing granular deployment we've faced a bunch of issues > that would make further development of this feature much more complicated if > we have to support both Simple and HA deployment mo

Re: [openstack-dev] Running tox on Centos 6.5 with Python26

On 1/15/2015 7:49 PM, Joe Gordon wrote: On Fri, Jan 16, 2015 at 12:13 PM, John Warren mailto:jswar...@linux.vnet.ibm.com>> wrote: Can someone tell me or point me to documentation about what the required yum and pip packages are to be able to run tox for glance, keystone, neutron

[openstack-dev] [Policy][Group-based-policy] Policy violations investigation

Hi, I want to propose an idea of investigation of policy violations (for white-list policies defined by GBP) by, for instance, redirecting the violating sessions to a HoneyPot. Meaning, that if the only communication between Group A and Group B is by port 80 (as described in the GPB) then an access

Re: [openstack-dev] [Neutron] Bulk network operations

Saksham, The Neutron bulk operations are by definition atomic [1]: "Bulk operations are always performed atomically, meaning that either all or none of the objects in the request body are created." Best, Mohammad [1] https://wiki.openstack.org/wiki/Neutron/APIv2-specification From: "Saksham

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

On Tue, Jan 27, 2015 at 07:12:29AM -0800, Sean Dague wrote: > On 01/27/2015 12:18 AM, Silvan Kaiser wrote: > > Hello! > > Do dependencies required only in some contexts belong into requirements.txt? > > > > Yesterday we had a short discussion on #openstack-nova regarding how to > > handle optional

Re: [openstack-dev] required libvirtd/qemu versions for numa support?

On Mon, Jan 26, 2015 at 03:37:48PM -0800, Jay Pipes wrote: > On 01/26/2015 07:33 AM, Chris Friesen wrote: > >Hi, > > > >I'm interested in the recent work around NUMA support for guest > >instances > >(https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement), but > >I'm having some di

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

On 01/27/2015 02:18 AM, Silvan Kaiser wrote: > Hello! > Do dependencies required only in some contexts belong into requirements.txt? > > Yesterday we had a short discussion on #openstack-nova regarding how to > handle optional requirements. This was triggered by our quobyte nova driver > (https://

Re: [openstack-dev] [oslo.messaging] Performance testing. Initial steps.

On Thu, Jan 15, 2015 at 8:56 PM, Doug Hellmann wrote: > > > On Jan 15, 2015, at 1:30 PM, Denis Makogon > wrote: > > > > Good day to All, > > > > The question that i’d like to raise here is not simple one, so i’d like > to involve as much readers as i can. I’d like to speak about oslo.messaging >

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

On 01/27/2015 07:14 AM, Matt Riedemann wrote: On 1/27/2015 2:18 AM, Silvan Kaiser wrote: Hello! Do dependencies required only in some contexts belong into requirements.txt? Yesterday we had a short discussion on #openstack-nova regarding how to handle optional requirements. This was triggered b

Re: [openstack-dev] [Openstack][infra] Zuul-Merger Error in CI

FYI, it wasn’t a change to my repo, but to openstack upstream that solved the 12.04 --> 14.04 issue: https://review.openstack.org/#/c/141518/ So this will help anyone using the Openstack-Infra zuul puppet modules! Ramy From: Punith S [mailto:punit...@cloudbyte.com] Sent: Tuesday, January 27, 2015

Re: [openstack-dev] [Openstack][dev][Zuul] Merge Failed Error in CI - GitPython Error

Punith, I think it’s because when you installed fresh again on 14.04, the zuul GitPython dependency was updated to the latest. I proposed this zuul patch to fix it: https://review.openstack.org/#/c/149336/ Ramy From: Punith S [mailto:punit...@cloudbyte.com] Sent: Tuesday, January 27, 2015 4:33

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

On 1/27/2015 2:18 AM, Silvan Kaiser wrote: Hello! Do dependencies required only in some contexts belong into requirements.txt? Yesterday we had a short discussion on #openstack-nova regarding how to handle optional requirements. This was triggered by our quobyte nova driver (https://review.ope

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

On 01/27/2015 12:18 AM, Silvan Kaiser wrote: > Hello! > Do dependencies required only in some contexts belong into requirements.txt? > > Yesterday we had a short discussion on #openstack-nova regarding how to > handle optional requirements. This was triggered by our quobyte nova > driver (https://

Re: [openstack-dev] [nova][NFV][qa] Testing NUMA, CPU pinning and large pages

- Original Message - > From: "Vladik Romanovsky" > To: openstack-dev@lists.openstack.org > > Hi everyone, > > Following Steve Gordon's email [1], regarding CI for NUMA, SR-IOV, and other > features, I'd like to start a discussion about the NUMA testing in > particular. > > Recently we h

Re: [openstack-dev] [Fuel] removing single mode

+1 to simple mode removal On Tue, Jan 27, 2015 at 4:44 PM, Stanislaw Bogatkin wrote: > +1 > > On Tue, Jan 27, 2015 at 4:05 PM, Aleksandr Didenko > wrote: > >> Hi, >> >> After starting implementing granular deployment we've faced a bunch of >> issues that would make further development of this f

  1   2   >