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

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.openstack.org/#/c/110722/18), who requires xattr,

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

Dmitry 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 task being executed. Say, we have a fencing task, which has

Re: [openstack-dev] [heat][hot]

I have another question, is it possible to get the stack name in the hot script? E.g. params: $stack_name: {get_global_variable: $stack.name} On Tue, Jan 27, 2015 at 3:53 AM, Qiming Teng wrote: > On Mon, Jan 26, 2015 at 07:44:25PM +0200, Dmitry wrote: > > thanks, exactly what I was look

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

Guys, I'm now here and I don't agree that we need to remove "changes" attribute. On the opposite, I think this is the only attribute which should be looked at on UI and backend, and all these "pending_addition" and "pending_someotherstuff" are obsolete and needless. Just assume, that we'll soon h

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

Updating subject line to attract keystone devs Daniel Comnea wrote: > +100 > > Dani > > On Mon, Jan 26, 2015 at 1:10 AM, Tim Bell > wrote: > > This is often mentioned as one of those items which catches every > OpenStack cloud operator at some time. It’s not cl

Re: [openstack-dev] [Fuel][Agent] Moving Fuel Agent to a separate repo

Mike, You are absolutely right about our current priorities for 6.1 and this thread is not about immediate action. But just to be fair, moving Fuel Client to a separate repo was a priori much more complicated procedure because it is tested together with nailgun. For Fuel Agent we just need to cre

[openstack-dev] Cross-Project meeting, Tue January 27th, 21:00 UTC

Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting today at 21:00 UTC, with the following agenda: * Cross-project DevRef akin to Nova's ([1]) [2] (@sigmavirus24) * Avoiding private symbols in Oslo libraries [3] (dhellmann) * Discuss the importance of

Re: [openstack-dev] [Murano] SQLite support - drop or not?

On 26.01.2015 18:34, Ruslan Kamaldinov wrote: > On Mon, Jan 26, 2015 at 6:12 PM, Andrew Pashkin wrote: >> On 26.01.2015 18:05, Ruslan Kamaldinov wrote: >> >> I think it's still important to perform migration specific checks. We want >> to make sure that DB is in expected state after each specific

Re: [openstack-dev] [Fuel] fuel master monitoring

The proposed monitoring options make sense, since the Fuel master has nothing yet, but I would like to ressurect this thread to see if we can discuss some strategies in order to avoid the /var/log fillup with consequent docker containers corruption. Now, a customer facing this corruption can re

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

Guys, First, we are not talking about deliberate disabling preseed based approach just because we so crazy. The question is "What is the best way to achieve our 6.1 goals?" We definitely need to be able to install two versions of Ubuntu 12.04 and 14.04. Those versions have different sets of packag

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

Andrew is right about our ability to upgrade packages on a system using "yum update" or "apt-get upgrade" because IBP installs standalone OS (unlike cloud case). Even more, we'll build Ubuntu images on a master node by 6.1 and of course we'll be able to use actual repo for that. Vladimir Kozhukalo

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

Hi Steve, I can host it. Regards Marc Am 27.01.2015 um 08:40 schrieb Steve Gordon : > Hi all, > > As mentioned in the notes from last week's meeting I am going to be in > transit during our 1400 UTC meeting this Wednesday (28th) [1]. Is anyone else > willing and able to facilitate in my abse

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

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 don't >> like that being in the governance repository, what would hav

Re: [openstack-dev] [Fuel] Proposal for nominating people to python-fuelclient-core

I think the consensus was found and the resolution is positive. > 26 січ. 2015 о 14:37 Tomasz Napierala написав(ла): > > +1 > > >> On 26 Jan 2015, at 11:33, Roman Prykhodchenko wrote: >> >> Hi Guys, >> >> According to our previous thread [1] and the decision made there I’d like to >> initi

Re: [openstack-dev] [heat][hot]

On Tue, Jan 27, 2015 at 7:00 PM, Dmitry wrote: > I have another question, is it possible to get the stack name in the hot > script? > E.g. > params: > $stack_name: {get_global_variable: $stack.name} > See: http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#pseudo-para

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

Hi the merge fail error that we reported in ubuntu 12.04 has been solved in the new ubuntu 14.04 CI master setup. many thanks to ramy on the update of the repo :) https://github.com/rasselin/os-ext-testing cheers! On Thu, Jan 8, 2015 at 7:16 PM, Punith S wrote: > hi, > > i'm running CI for ope

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

Hi the merge fail error that we reported in ubuntu 12.04 has been solved in the new ubuntu 14.04 CI master setup. many thanks to ramy on the update of the repo :) https://github.com/rasselin/os-ext-testing cheers! On Fri, Jan 16, 2015 at 4:58 PM, Punith S wrote: > > Hi stackers, > > i'm runnin

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

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 modes. For example: simple mode does not require cluster (corosync, pacemaker, vips, etc),

Re: [openstack-dev] [Fuel][Neutron ML2][VMWare]NetworkNotFoundForBridge: Network could not be found for bridge br-int

Hi Xarses, Actually it is multi-hypervisor environment. The error in the nova.log is: NetworkNotFoundForBridge: Network could not be found for bridge br-int the above error disappears changing the mech driver order in /etc/neutron/plugins/ml2/ml2_conf.ini file from mechanism_drivers = openvswi

[openstack-dev] oslo.i18n 1.3.1 released

The Oslo team is pleased to announce the release of: oslo.i18n 1.3.1: oslo.i18n library The primary reason for this release is a packaging issue reported and fixed by Dan Smith. For more details, please see the git log history below and: http://launchpad.net/oslo.i18n/+milestone/1.3.1 Please r

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

+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 feature much more > complicated if we have to support both Simple and HA deployment modes. For > exam

Re: [openstack-dev] [heat][hot]

Thank you very much On Tue, Jan 27, 2015 at 1:06 PM, Angus Salkeld wrote: > On Tue, Jan 27, 2015 at 7:00 PM, Dmitry wrote: > >> I have another question, is it possible to get the stack name in the hot >> script? >> E.g. >> params: >> $stack_name: {get_global_variable: $stack.name}

Re: [openstack-dev] [all] need help with my first commit: The branch 'master' does not exist on the given remote 'gerrit'

Hello. I think there might be something wrong with git-review in your env. You might want try in another env, preferably linux if its handy. I noticed your origin is from github? you should clone from here instead: http://git.openstack.org/cgit/stackforge/congress Here's what you should get wh

[openstack-dev] Hyper-V meeting

Hi All, Due to weather conditions and others traveling we will need to postpone the Hyper-V meeting until next week. For issues or questions please email directly or contact one of us on the IRC channel. We will resume next week at the usual time. p Peter J. Pouliot CISSP Microsoft Cloud+Enter

[openstack-dev] How to pass through devstack config

Hi, I have seen Sean Dague's patch [1], if I understood correctly, by this patch we can reduce the number of DEVSTACK_GATE variables that we need. Trying to follow this patch to configure my gate job "DEVSTACK_GATE_GLUSTERFS" [2]. I am not able to figure out the way to use this patch [1]. Ple

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

+1 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jan 27, 2015 at 2: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 tha

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

[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

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

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

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

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

[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

[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

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

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

+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

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

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

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

  1   2   >