Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

So, To try to reach some kind of conclusion here I am wondering if it would be acceptable to folks (would people even adopt such a change?) if we (oslo folks/others) provided a new function in say lockutils.py (in oslo.concurrency) that would let users of oslo.concurrency pick which kind

Re: [openstack-dev] [oslo][glance][all] Removing deprecated functions from oslo_utils.timeutils

Shouldn't be to hard (although it's probably not on each oslo project, but on the consumers projects). The warnings module can turn warnings into raised exceptions with a simple command line switch btw... For example: $ python -Wonce Python 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2]

Re: [openstack-dev] [release][oslo] ImportError: No module named netifaces

As u wish: https://review.openstack.org/#/c/254523/ -Josh Jeremy Stanley wrote: On 2015-12-07 17:37:41 -0800 (-0800), Joshua Harlow wrote: Should be fixed in https://review.openstack.org/#/c/254379/ (once that flushes through all the things); follow ups can tweak that to work in a different

Re: [openstack-dev] [release][oslo] ImportError: No module named netifaces

Should be fixed in https://review.openstack.org/#/c/254379/ (once that flushes through all the things); follow ups can tweak that to work in a different manner. Jeremy Stanley wrote: And there's a bug open at https://launchpad.net/bugs/1523706 for this issue as well.

Re: [openstack-dev] [Performance][Proposal] Moving IRC meeting from 15:00 UTC to 16:00 UTC

+1 from me :) Dina Belova wrote: Dear performance folks, There is a suggestion to move our meeting time from 15:00 UTC (Tuesdays ) to 16:00 UTC (also Tuesdays

Re: [openstack-dev] [all][oslo] On Python 3, request_id must by Unicode, not bytes

Seems ok with me, not ideal but knowing the support of python 3.x in openstack it doesn't seem harmful to fix this while we still are able to; and in general if thats 'req-$uuid' ascii/unicode should be fine (since that's all that is). -Josh Victor Stinner wrote: Hi, The next oslo.context

Re: [openstack-dev] [nova]New Quota Subteam on Nova

So whats needed to build out that 'framework'? Is it just dispatching provision requests to nova, and then seeing when the quota becomes out of sync, and then backtracking through logs and notifications (+- other) to then figure out the root cause? Or is that framework some kind of local

Re: [Openstack] [openstack-dev] [nova]New Quota Subteam on Nova

Matt Riedemann wrote: On 12/1/2015 2:07 PM, Joshua Harlow wrote: So whats needed to build out that 'framework'? Is it just dispatching provision requests to nova, and then seeing when the quota becomes out of sync, and then backtracking through logs and notifications (+- other

Re: [Openstack] [openstack-dev] [nova]New Quota Subteam on Nova

So whats needed to build out that 'framework'? Is it just dispatching provision requests to nova, and then seeing when the quota becomes out of sync, and then backtracking through logs and notifications (+- other) to then figure out the root cause? Or is that framework some kind of local

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Sean Dague wrote: On 12/01/2015 08:08 AM, Duncan Thomas wrote: On 1 December 2015 at 13:40, Sean Dague> wrote: The current approach means locks block on their own, are processed in the order they come in, but deletes aren't possible. The busy

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

So my takeaway is we need each project to have something like: https://gist.github.com/harlowja/b4f0ddadbda1f92cc1e2 That could possibly exist in oslo (I just threw it together) but the idea is that a thread/greenthread would run that 'run_forever' method in that code and it would

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Ben Nemec wrote: On 11/30/2015 02:15 PM, Sean Dague wrote: On 11/30/2015 03:01 PM, Robert Collins wrote: On 1 December 2015 at 08:37, Ben Nemec<openst...@nemebean.com> wrote: On 11/30/2015 12:42 PM, Joshua Harlow wrote: Hi all, I just wanted to bring up an issue, possible solution a

[openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Hi all, I just wanted to bring up an issue, possible solution and get feedback on it from folks because it seems to be an on-going problem that shows up not when an application is initially deployed but as on-going operation and running of that application proceeds (ie after running for a

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Ben Nemec wrote: On 11/30/2015 12:42 PM, Joshua Harlow wrote: Hi all, I just wanted to bring up an issue, possible solution and get feedback on it from folks because it seems to be an on-going problem that shows up not when an application is initially deployed but as on-going operation

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Joshua Harlow wrote: Ben Nemec wrote: On 11/30/2015 12:42 PM, Joshua Harlow wrote: Hi all, I just wanted to bring up an issue, possible solution and get feedback on it from folks because it seems to be an on-going problem that shows up not when an application is initially deployed

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2015-11-30 10:42:53 -0800: Hi all, I just wanted to bring up an issue, possible solution and get feedback on it from folks because it seems to be an on-going problem that shows up not when an application is initially deployed but as

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Sean Dague wrote: On 11/30/2015 03:01 PM, Robert Collins wrote: On 1 December 2015 at 08:37, Ben Nemec<openst...@nemebean.com> wrote: On 11/30/2015 12:42 PM, Joshua Harlow wrote: Hi all, I just wanted to bring up an issue, possible solution and get feedback on it from folks because it

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

Sean Dague wrote: On 11/30/2015 03:01 PM, Robert Collins wrote: On 1 December 2015 at 08:37, Ben Nemec<openst...@nemebean.com> wrote: On 11/30/2015 12:42 PM, Joshua Harlow wrote: Hi all, I just wanted to bring up an issue, possible solution and get feedback on it from folks because it

Re: [openstack-dev] [oslo] Proposal for new core reviewer: ChangBo Guo

+1 welcome to the team :) Davanum Srinivas wrote: +1 from me! would be great to have you on board gcb -- Dims On Fri, Nov 27, 2015 at 11:23 AM, Victor Stinner wrote: Hi, I noticed that ChangBo Guo (aka gcb) is very active in various Oslo projects, to write patches but

Re: [openstack-dev] [all] Thoughts on python-future?

Julien Danjou wrote: On Tue, Nov 24 2015, Eric Kao wrote: I¹ve been using the python-future library for Python 3 porting and want to see what people think of it. http://python-future.org/overview.html#features The end result is standard Python3 code made compatible with Python2 through

Re: [openstack-dev] [oslo] A special thank you to Davanum (Dims)

Dims is my hero ;) Lol, this thread is interesting :-P -Josh Amrith Kumar wrote: Yes, let’s talk about dims while he isn’t here. I’ll second what Michael and Steve have to say. Dims has been a great guy to work with and he’s been a great resource. On one occasion, I needed some openstack

Re: [openstack-dev] [nova] [Openstack-operators] Profiling nova-conductor and eventlet

Kris and I also experimented with: https://gist.github.com/harlowja/d2b5fc5282c76f10bc3f (which is like the entrypoint to cProfile but instead using the eventlet profiler module instead), that didn't appear to go so well... So any thoughts would be great here (especially around how to

[openstack-dev] [Oslo] Virtual sprint! End of this week!! (get'm while they are hot)

this time! See you then, Joshua Harlow [1]: https://etherpad.openstack.org/p/oslo-mitaka-1-virtual-doc-sprint [2]: https://etherpad.openstack.org/p/oslo-liberty-virtual-doc-sprint __ OpenStack Development Mailing List

[openstack-dev] [Oslo] taskflow 2.0 and its changes

Since I am hoping to get taskflow 2.0 out in mitaka I wanted to share with folks some of the debt collected items that have been/are scheduled for removal. Most of these have been removed in 6+ months (some have been around from 2014) and with the 2.0 release it seems like the best time to

Re: [openstack-dev] [Oslo][TaskFlow] Proposal for new core reviewer (greg hill)

Julien Danjou wrote: On Wed, Nov 11 2015, Joshua Harlow wrote: Greetings all stackers, I propose that we add Greg Hill[1] to the taskflow-core[2] team. Greg (aka jimbo) has been actively contributing to taskflow for a while now, both in helping make taskflow better via code contribution(s

Re: [Openstack-operators] [nova] FYI, local conductor mode is deprecated, pending removal in N

Ok, so the following is starting to form: https://etherpad.openstack.org/p/remote-conductor-performance Hopefully we can get to the bottom of this (especially for clouds that run a large amount of computes in a single cell/only one cell). Andrew Laski wrote: On 11/12/15 at 10:53am, Clint

[openstack-dev] [Oslo][TaskFlow] Proposal for new core reviewer (greg hill)

/-1. Thanks much! - Joshua Harlow [1] https://launchpad.net/~greg-hill [2] https://launchpad.net/taskflow [3] http://www.rackspace.com/cloud/big-data __ OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [oslo.messaging] State wrapping in the MessageHandlingServer

Matthew Booth wrote: On Tue, Nov 10, 2015 at 6:46 PM, Joshua Harlow <harlo...@fastmail.com <mailto:harlo...@fastmail.com>> wrote: Matthew Booth wrote: My patch to MessageHandlingServer is currently being reverted because it broke Nova tests:

Re: [openstack-dev] [oslo.messaging] State wrapping in the MessageHandlingServer

Matthew Booth wrote: My patch to MessageHandlingServer is currently being reverted because it broke Nova tests: https://review.openstack.org/#/c/235347/ Specifically it causes a number of tests to take a very long time to execute, which ultimately results in the total build time limit being

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Sean Dague wrote: On 11/10/2015 05:12 AM, Thierry Carrez wrote: Kevin Carter wrote: I believe Clint already linked to https://aphyr.com/posts/309-knossos-redis-and-linearizability or similar - but 'known for general ease of use and reliability' is uhm, a bold claim. Its worth comparing that

Re: [openstack-dev] [Openstack-operators] [tc][all][osprofiler] OSprofiler is dead, long live OSprofiler

+1 from me (although I've already contributed to osprofiler so my vote might not count, ha). Anyway, people can poke me as well if they have any questions about osprofiler and boris isn't around. I'm happy to answer any questions as well... Thanks boris for getting this rolling again... Another

Re: [Openstack-operators] [openstack-dev][tc][all][osprofiler] OSprofiler is dead, long live OSprofiler

+1 from me (although I've already contributed to osprofiler so my vote might not count, ha). Anyway, people can poke me as well if they have any questions about osprofiler and boris isn't around. I'm happy to answer any questions as well... Thanks boris for getting this rolling again... Another

Re: [openstack-dev] [all] [dlm] Zookeeper and openjdk, mythbusted

Adam Young wrote: On 11/09/2015 09:46 AM, Thierry Carrez wrote: Sean Dague wrote: I do wonder what the cause of varying quality is in the distros. I do understand that some distros aren't licensing the test suite. But they are all building from the same upstream. Except that they all use

Re: [openstack-dev] [all] [dlm] Zookeeper and openjdk, mythbusted

Sean Dague wrote: On 11/09/2015 06:05 AM, Thierry Carrez wrote: So that is an important point. While there is "the Oracle JVM", there is nothing like "OpenJDK". There are a number of OpenJDK builds by various distros and they are all different (and of varying quality). The beast is brittle, as

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

On Mon, Nov 9, 2015, at 10:24 PM, Kevin Carter wrote: > Hello all, > > The rational behind using a solution like zookeeper makes sense however > in reviewing the thread I found myself asking if there was a better way > to address the problem without the addition of a Java based solution as > the

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

On Mon, Nov 9, 2015, at 10:24 PM, Kevin Carter wrote: > Hello all, > > The rational behind using a solution like zookeeper makes sense however > in reviewing the thread I found myself asking if there was a better way > to address the problem without the addition of a Java based solution as > the

[openstack-dev] [all] [dlm] Zookeeper and openjdk, mythbusted

I just wanted to bring this up in its own thread as I know it was a concern of (some) folks at the DLM session in tokyo[0] and I'd like to try to bust this myth using hopefully objective people/users of zookeeper (besides myself and yahoo, the company I work for) so that this myth can be put

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

Clint Byrum wrote: Excerpts from Doug Hellmann's message of 2015-11-06 10:28:41 -0800: Excerpts from Clint Byrum's message of 2015-11-06 10:12:21 -0800: Excerpts from Dan Smith's message of 2015-11-06 09:37:44 -0800: Worth mentioning that OpenStack releases that come out at the same time as

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Sean Dague wrote: On 11/05/2015 06:00 AM, Thierry Carrez wrote: Hayes, Graham wrote: On 04/11/15 20:04, Ed Leafe wrote: On Nov 3, 2015, at 6:45 AM, Davanum Srinivas wrote: Here's a Devstack review for zookeeper in support of this initiative:

Re: [openstack-dev] [Spam] Re: [all] Outcome of distributed lock manager discussion @ the summit

Clint Byrum wrote: Excerpts from Chris Dent's message of 2015-11-05 00:08:16 -0800: On Thu, 5 Nov 2015, Robert Collins wrote: In the session we were told that zookeeper is already used in CI jobs for ceilometer (was this wrong?) and thats why we figured it made a sane default for devstack.

Re: [openstack-dev] [oslo][oslo.config][oslo.service] Dynamic Reconfiguration of OpenStack Services

(discovery) case. yeah, that would be a useful thing to be able to tweak live. I haven't needed that feature yet, but could see how that flexibility could come in handy. Thanks, Kevin From: Joshua Harlow [harlo...@fastmail.com] Sent: Wednesday, November 04

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Ed Leafe wrote: On Nov 3, 2015, at 6:45 AM, Davanum Srinivas wrote: Here's a Devstack review for zookeeper in support of this initiative: https://review.openstack.org/241040 Thanks, Dims I thought that the operators at that session made it very clear that they would

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

Shraddha Pandhe wrote: On Wed, Nov 4, 2015 at 3:12 PM, Kevin Benton > wrote: >If we add our own database for internal stuff, we go back to the same problem of allowing bad design. I'm not sure I understand what you are saying here. A

Re: [openstack-dev] [oslo][oslo.config][oslo.service] Dynamic Reconfiguration of OpenStack Services

' (rabbit_hosts, glance/api_servers, keystone/api_servers) but fixing this is likely a longer term goal (see conversations in keystone). Joshua Harlow wrote: gord chung wrote: we actually had a solution implemented in Ceilometer to handle this[1]. that said, based on the results of our survey[2], we found

Re: [openstack-dev] [oslo][oslo.config][oslo.service] Dynamic Reconfiguration of OpenStack Services

gord chung wrote: we actually had a solution implemented in Ceilometer to handle this[1]. that said, based on the results of our survey[2], we found that most operators *never* update configuration files after the initial setup and if they did it was very rarely (monthly updates). the question

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Thanks robert, I've started to tweak https://review.openstack.org/#/c/209661/ with regard to the outcome of that (at least to cover the basics)... Should be finished up soon (I hope). Robert Collins wrote: Hi, at the summit we had a big session on distributed lock managers (DLMs). I'd just

Re: [openstack-dev] [Nova] Migration state machine proposal.

Nikola Đipanov wrote: On 10/21/2015 10:17 PM, Joshua Harlow wrote: Question on some things seen in the below paste. What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'? Why does it jump over 'reverting' or 'confirming'? Should it? The other question is the diff

Re: [openstack-dev] [Nova] Migration state machine proposal.

Question on some things seen in the below paste. What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'? Why does it jump over 'reverting' or 'confirming'? Should it? The other question is the difference between 'failed' and 'error' in the first diagram, any idea on why/how these

Re: [openstack-dev] [oslo] Require documenting changes with versionadded and versionchanged

Victor Stinner wrote: Le 15/10/2015 17:54, Joshua Harlow a écrit : I had this problem with deprecation versioning (the debtcollector library functions take a version="XYZ", removal_version="ABC" params, see http://docs.openstack.org/developer/debtcollector/examples.html

Re: [openstack-dev] Scheduler proposal

Clint Byrum wrote: Excerpts from Ed Leafe's message of 2015-10-15 11:56:24 -0700: Wow, I seem to have unleashed a bunch of pent-up frustration in the community! It's great to see everyone coming forward with their ideas and insights for improving the way Nova (and, by extension, all of

Re: [openstack-dev] [oslo] Require documenting changes with versionadded and versionchanged

Brant Knudson wrote: On Thu, Oct 15, 2015 at 5:52 AM, Victor Stinner > wrote: Hi, I propose that changes must now be documented in Oslo libraries. If a change is not documented, it must *not* be approved. IMHO it's very

Re: [openstack-dev] Scheduler proposal

Ed Leafe wrote: Wow, I seem to have unleashed a bunch of pent-up frustration in the community! It's great to see everyone coming forward with their ideas and insights for improving the way Nova (and, by extension, all of OpenStack) can potentially scale. I do have a few comments on the

Re: [openstack-dev] Scheduler proposal

Jeremy Stanley wrote: On 2015-10-12 20:49:44 -0700 (-0700), Joshua Harlow wrote: Does the openstack foundation have access to a scaling area that can be used by the community for this kind of experimental work? The OpenStack Foundation has a staff of fewer than 20 full-time employees

Re: [openstack-dev] Scheduler proposal

Well great! When is that going to be accessible :-P Dulko, Michal wrote: On Mon, 2015-10-12 at 10:58 -0700, Joshua Harlow wrote: Just a related thought/question. It really seems we (as a community) need some kind of scale testing ground. Internally at yahoo we were/are going to use a 200

Re: [openstack-dev] Scheduler proposal

Clint Byrum wrote: Excerpts from Ian Wells's message of 2015-10-13 09:24:42 -0700: On 12 October 2015 at 21:18, Clint Byrum wrote: We _would_ keep a local cache of the information in the schedulers. The centralized copy of it is to free the schedulers from the complexity of

Re: [openstack-dev] Requests + urllib3 + distro packages

Thomas Goirand wrote: On 10/13/2015 12:44 AM, Joshua Harlow wrote: Anvil gets somewhat far on this, although its not supporting DEBs it does build its best attempt at RPMs building them automatically and turning git repos of projects into RPMs. http://anvil.readthedocs.org/en/latest/topics

Re: [openstack-dev] Scheduler proposal

Clint Byrum wrote: Excerpts from Jeremy Stanley's message of 2015-10-13 06:13:32 -0700: On 2015-10-12 20:49:44 -0700 (-0700), Joshua Harlow wrote: Does the openstack foundation have access to a scaling area that can be used by the community for this kind of experimental work? The OpenStack

Re: [openstack-dev] Scheduler proposal

Thierry Carrez wrote: Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2015-10-10 17:43:40 -0700: I'm curious is there any more detail about #1 below anywhere online? Does cassandra use some features of the JVM that the openJDK version doesn't support? Something else? This about

Re: [openstack-dev] Scheduler proposal

Clint Byrum wrote: Excerpts from Boris Pavlovic's message of 2015-10-11 01:14:08 -0700: Clint, There are many PROS and CONS in both of approaches. Reinventing wheel (in this case it's quite simple task) and it gives more flexibility and doesn't require usage of ZK/Consul (which will simplify

Re: [openstack-dev] Scheduler proposal

Alec Hothan (ahothan) wrote: On 10/10/15, 11:35 PM, "Clint Byrum" wrote: Excerpts from Alec Hothan (ahothan)'s message of 2015-10-09 21:19:14 -0700: On 10/9/15, 6:29 PM, "Clint Byrum" wrote: Excerpts from Chris Friesen's message of 2015-10-09

Re: [openstack-dev] Scheduler proposal

Alec Hothan (ahothan) wrote: On 10/12/15, 11:45 AM, "Joshua Harlow"<harlo...@fastmail.com> wrote: Alec Hothan (ahothan) wrote: On 10/10/15, 11:35 PM, "Clint Byrum"<cl...@fewbar.com> wrote: Excerpts from Alec Hothan (ahothan)'s message of 2015-10-0

Re: [openstack-dev] Requests + urllib3 + distro packages

Jeremy Stanley wrote: On 2015-10-12 15:40:48 +0200 (+0200), Thomas Goirand wrote: [...] Has the infra team ever thought about doing that for (at least) all of the 3rd party libs we use? I'd love to work closer with the infra team to provide them with missing packages they would need, and I'm

[openstack-dev] Oslo survey

Hi OpenStack devs, The Oslo team would like to collect feedback and information from its user base in order to help us plan and strategize around Mitaka deliverables and to help improve itself and the projects it maintains. To do so, we have developed a survey that we think will be helpful in

Re: [openstack-dev] Scheduler proposal

Ian Wells wrote: On 10 October 2015 at 23:47, Clint Byrum > wrote: > Per before, my suggestion was that every scheduler tries to maintain a copy > of the cloud's state in memory (in much the same way, per the previous > example, as

Re: [openstack-dev] Scheduler proposal

Clint Byrum wrote: Excerpts from Boris Pavlovic's message of 2015-10-11 00:02:39 -0700: 2Everybody, Just curios why we need such complexity. Let's take a look from other side: 1) Information about all hosts (even in case of 100k hosts) will be less then 1 GB 2) Usually servers that runs

Re: [openstack-dev] Scheduler proposal

I'm curious is there any more detail about #1 below anywhere online? Does cassandra use some features of the JVM that the openJDK version doesn't support? Something else? -Josh Thomas Goirand wrote: On 10/07/2015 07:36 PM, Ed Leafe wrote: Several months ago I proposed an experiment [0] to

Re: [openstack-dev] Scheduler proposal

Gregory Haynes wrote: Excerpts from Joshua Harlow's message of 2015-10-08 15:24:18 +: On this point, and just thinking out loud. If we consider saving compute_node information into say a node in said DLM backend (for example a znode in zookeeper[1]); this information would be updated

Re: [openstack-dev] Scheduler proposal

from example run of 'creator process' http://paste.openstack.org/show/475942/ Output from example run of 'watcher process' http://paste.openstack.org/show/475943/ Enjoy! -josh Joshua Harlow wrote: Further example stuff, Get kazoo installed (http://kazoo.readthedocs.org/) Output from my local

Re: [openstack-dev] Scheduler proposal

wn resources: - h1.hypervisor.yahoo.com => {} Idling (ran for 5.00s). Kazoo client has changed to state: LOST Traceback (most recent call last): File "test.py", line 72, in time.sleep(1.0) KeyboardInterrupt Joshua Harlow wrote: Gregory Haynes wrote: Excerpts from Joshua Harlow's

Re: [openstack-dev] Scheduler proposal

And also we should probably deprecate/not recommend: http://docs.openstack.org/developer/nova/api/nova.scheduler.filters.json_filter.html#nova.scheduler.filters.json_filter.JsonFilter That filter IMHO basically disallows optimizations like forming SQL statements for each filter (and then

Re: [openstack-dev] Requests + urllib3 + distro packages

For those who are interested in more of the historical aspect around this, https://github.com/kennethreitz/requests/issues/1811 https://github.com/kennethreitz/requests/pull/1812 My own thoughts are varied here, I get the angle of vendoring, but I don't get the resistance to unvendoring it

Re: [openstack-dev] Scheduler proposal

On Thu, 8 Oct 2015 10:43:01 -0400 Monty Taylor wrote: > On 10/08/2015 09:01 AM, Thierry Carrez wrote: > > Maish Saidel-Keesing wrote: > >> Operational overhead has a cost - maintaining 3 different database > >> tools, backing them up, providing HA, etc. has operational

Re: [openstack-dev] Scheduler proposal

Joshua Harlow wrote: On Thu, 8 Oct 2015 10:43:01 -0400 Monty Taylor<mord...@inaugust.com> wrote: On 10/08/2015 09:01 AM, Thierry Carrez wrote: Maish Saidel-Keesing wrote: Operational overhead has a cost - maintaining 3 different database tools, backing them up, providing HA, et

Re: [openstack-dev] Scheduler proposal

Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2015-10-08 08:38:57 -0700: Joshua Harlow wrote: On Thu, 8 Oct 2015 10:43:01 -0400 Monty Taylor<mord...@inaugust.com> wrote: On 10/08/2015 09:01 AM, Thierry Carrez wrote: Maish Saidel-Keesing wrote: Operational overhe

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

Isn't #2 the right approach? Even if it might be more 'work' I personally would prefer #2 and do it right (and make it easier to do the right thing in the future via scripts, automation, other) vs. the other mentioned approaches. If we were consuming, say a 3rd party library and that 3rd

Re: [openstack-dev] Scheduler proposal

Just a question, Why cassandra? I'm curious what drew u to using that for an experiment? /me not saying its a bad choice, just curious... Ed Leafe wrote: Several months ago I proposed an experiment [0] to see if switching the data model for the Nova scheduler to use Cassandra as the backend

Re: [openstack-dev] [cinder] should we use fsync when writing iscsi config file?

jul...@danjou.info> wrote: > On Tue, Sep 22 2015, Chris Friesen wrote: > > > On 09/22/2015 05:48 PM, Joshua Harlow wrote: > >> A present: > >> > >> >>> import contextlib > >> >>> import os > >> >>> > >>

Re: [openstack-dev] [magnum]swarm + compose = k8s?

+1 Pretty please don't make it a deployment project; because really some other project that just specializes in deployment (ansible, chef, puppet...) can do that better. I do get how public clouds can find a deployment project useful (it allows customers to try out these new ~fancy~ COE things),

Re: [openstack-dev] [magnum]swarm + compose = k8s?

l.XX tenants. I am not convinced that having an uber-tenant makes sense. Adrian On Sep 30, 2015, at 1:13 PM, Joshua Harlow <harlo...@outlook.com <mailto:harlo...@outlook.com>> wrote: Adrian Otto wrote: Thanks everyone who has provided feedback on this thread. The good news is that

[openstack-dev] [election][TC] TC Candidacy

sustainability of OpenStack (at small and megascale); using my own experiences to help in this process // Thanks for considering me, Joshua Harlow -- Yahoo! http://stackalytics.com/report/users/harlowja Official submission @ https://review.openstack.org/229591

Re: [openstack-dev] [magnum]swarm + compose = k8s?

Adrian Otto wrote: Thanks everyone who has provided feedback on this thread. The good news is that most of what has been asked for from Magnum is actually in scope already, and some of it has already been implemented. We never aimed to be a COE deployment service. That happens to be a necessity

Re: [openstack-dev] [magnum]swarm + compose = k8s?

l that pain is worth the gain. > > Regards, > -steve > > > On 9/30/15, 2:18 PM, "Joshua Harlow"<harlo...@outlook.com> wrote: > >> Wouldn't that limit the ability to share/optimize resources then and >> increase the number of operators ne

Re: [openstack-dev] [heat] Convergence: Detecting and handling worker failures

Clint Byrum wrote: Excerpts from Anant Patil's message of 2015-09-30 00:10:52 -0700: Hi, One of remaining items in convergence is detecting and handling engine (the engine worker) failures, and here are my thoughts. Background: Since the work is distributed among heat engines, by some means

Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

mhorban wrote: > Excerpts from Josh's message: >> So a few 'event' like constructs/libraries that I know about: >> >> http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier >> >> >> I'd be happy to extract that and move to somewhere else if needed, it

Re: [Openstack-operators] Live snapshots on the raw disks never ends

Ours was local-disk, I believe https://review.openstack.org/#/c/208078/ (and/or its followup bug/fix) will hopefully help address this. It might not be the same issue though (but maybe it is). -Josh Kris G. Lindgren wrote: I believe I was talking to Josh Harlow (he's harlowja in

Re: [openstack-dev] [oslo.messaging][devstack] Pika RabbitMQ driver implementation

Dmitriy Ukhlov wrote: Hello stackers, I'm working on new olso.messaging RabbitMQ driver implementation which uses pika client library instead of kombu. It related to https://blueprints.launchpad.net/oslo.messaging/+spec/rabbit-pika. In this letter I want to share current results and probably

Re: [openstack-dev] [oslo.messaging][devstack] Pika RabbitMQ driver implementation

Also a side question, that someone might know, Whatever happened to the folks from rabbitmq (incorporated? pivotal?) who were going to get involved in oslo.messaging, did that ever happen; if anyone knows? They might be a good bunch of people to review such a pika driver (since I think they

Re: [openstack-dev] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

+1 from me, although I thought heat was supposed to be this thing? Maybe there should be a 'warm' project or something ;) Or we can call it 'bbs' for 'building block service' (obviously not bulletin board system); ask said service to build a set of blocks into well defined structures and let

Re: [openstack-dev] [oslo] nominating Brant Knudson for Oslo core

+1 from me, welcome aboard. Please tar the deck and clean up the rigging, thanks :-P ozamiatin wrote: +1 from me 9/24/15 20:12, Doug Hellmann пишет: Oslo team, I am nominating Brant Knudson for Oslo core. As liaison from the Keystone team Brant has participated in meetings, summit

Re: [openstack-dev] [cinder] should we use fsync when writing iscsi config file?

Chris Friesen wrote: On 09/22/2015 05:48 PM, Joshua Harlow wrote: A present: >>> import contextlib >>> import os >>> >>> @contextlib.contextmanager ... def synced_file(path, mode='wb'): ... with open(path, mode) as fh: ... yield fh ... os.fdatasync(fh.file

Re: [openstack-dev] [cinder] should we use fsync when writing iscsi config file?

A present: >>> import contextlib >>> import os >>> >>> @contextlib.contextmanager ... def synced_file(path, mode='wb'): ... with open(path, mode) as fh: ... yield fh ... os.fdatasync(fh.fileno()) ... >>> with synced_file("/tmp/b.txt") as fh: ...fh.write("b") ... Have fun :-P

Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

Agreed, +1 :) Gotta start somewhere to get to somewhere else ;) mhorban wrote: Hi Josh, > Sounds like a useful idea if projects can plug-in themselves into the > reloading process. I definitely think there needs to be a way for > services to plug-in to this, although I'm not quite sure it

Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

So a few 'event' like constructs/libraries that I know about: http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier I'd be happy to extract that and move to somewhere else if needed, it provides basic event/pub/sub kind of activities for taskflow

Re: [openstack-dev] Pycharm License for OpenStack developers

Anyone know about the impact of: - https://mmilinkov.wordpress.com/2015/09/04/jetbrains-lockin-we-told-you-so/ - http://blog.jetbrains.com/blog/2015/09/03/introducing-jetbrains-toolbox/ I'm pretty sure a lot of openstack-devs are using pycharms, and wonder what this change will mean for

Re: [openstack-dev] [oslo][oslo.config] Reloading configuration of service

Sounds like a useful idea if projects can plug-in themselves into the reloading process. I definitely think there needs to be a way for services to plug-in to this, although I'm not quite sure it will be sufficient at the current time though. An example of why: -

Re: [openstack-dev] [all][TC] 'team:danger-not-diverse tag' and my concerns

Thierry Carrez wrote: Joshua Harlow wrote: I believe it is the TC job (in part) to help make the community better, and not via tags like this that IMHO actually make it worse; I think it's important to see the intent of the tag, rather than only judge on its current proposed name. The big

[openstack-dev] [oslo] PTL candidacy

); the python community is a big world and it'd be great to make sure we do our part there as well. - Asking the hard questions. - Being jolly. Thanks for considering me, Any questions/comments/feedback, please let me know and I'll do my best to answer them :-) -Joshua Harlow

[openstack-dev] [oslo] mitaka summit planning/ideas

Hi all oslo-fans (and others), Just thought I'd let everyone interested know about: https://etherpad.openstack.org/p/mitaka-oslo-summit-planning Please feel free to add any thoughts/ideas for sessions on there! :-) -Josh

[openstack-dev] [all][TC] 'team:danger-not-diverse tag' and my concerns

Hi all, I was reading over the TC IRC logs for this week (my weekly reading) and I just wanted to let my thoughts and comments be known on: http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309 I feel it's very important to send a positive note for new/upcoming

Re: [openstack-dev] [rootwrap] rootwrap and libraries - RFC

Just out of curiosity, not 100% related to this thread, but other applications also bundle configuration files (for example heat templates @ https://github.com/openstack/magnum/tree/master/magnum/templates) Should there be some guidelines on how these config files are packaged and distributed

<    1   2   3   4   5   6   7   8   9   10   >