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 (an

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

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

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

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

#x27;s see if we can do better 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 Dev

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

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 profile

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 folk

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 library

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 also to review patches

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

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 and

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 but as on

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 on

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

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

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

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 periodically

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 Daguemailto:s...@dague.net>> 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 lock would m

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 func

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 r

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

[openstack-dev] [oslo][all] oslo.log `verbose` and $your project

Hi all, I just wanted to ensure folks are aware that the oslo group has removed the 'verbose' option and the hence-forth the 'debug' option should just be used (having to options that did very similar things was very confusing to folks). This deprecation for this was merged on aug 1, 2015 in

Re: [openstack-dev] [mistral][oslo.messaging] stable/mitaka is broken by oslo.messaging 5.0.0

Doug Hellmann wrote: Excerpts from Renat Akhmerov's message of 2016-05-17 19:10:55 +0700: Team, Our stable/mitaka branch is now broken by oslo.messaging 5.0.0. Global requirements for stable/mitaka has oslo.messaging>=4.0.0 so it can fetch 5.0.0. Just reminding that it breaks us because we in

Re: [openstack-dev] [mistral][oslo.messaging] stable/mitaka is broken by oslo.messaging 5.0.0

Roman Dobosz wrote: On Tue, 17 May 2016 21:41:11 -0700 Joshua Harlow wrote: Options I see: Constrain oslo.messaging in global-requirements.txt for stable/mitaka with 4.6.1. Hard to do since it requires wide cross-project coordination. Remove that hack in stable/mitaka as we did with master

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

Morgan Fainberg wrote: On Thu, May 19, 2016 at 6:19 AM, Thierry Carrez mailto:thie...@openstack.org>> wrote: Hi everyone, The discussion on the addition of golang focuses on estimating community costs vs. technical benefits, so that the TC can make the right call for "OpenStac

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

John Dickinson wrote: summary: * Defining the scope of OpenStack projects DOES NOT define the languages needed to implement them. The considerations are orthogonal. * We've already defined OpenStack--it's whatever it takes to fulfill its mission statement. On 19 May 2016, at 6:19

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

Sean Dague wrote: On 05/23/2016 03:34 PM, Gregory Haynes wrote: On Mon, May 23, 2016, at 11:48 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-05-23 17:07:36 +0100: On Mon, 23 May 2016, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-05-20 14:16:15 +0100:

Re: [openstack-dev] [oslo.service] Lifecycle Hooks

Doug Hellmann wrote: Excerpts from Kanagaraj Manickam's message of 2016-05-18 19:48:13 +0530: DIms, Use case could be anything, which would needed by either operator/community, who wants to perform an required task before and after service is started. This requirement is very generic by natur

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

Ok, probably should be chopped out of the oslo lib list then ;) I'll do that, since it seems to be really not the right name for what it is :) Ian Cordasco wrote: -Original Message- From: Joshua Harlow Reply: OpenStack Development Mailing List (not for usage questions) Date: M

[openstack-dev] [nova][neutron][cloud-init] Questions around 'network_data.json'

Hi there all, I am working through code/refactoring in cloud-init to enable translation of the network_data.json file[1] provided by openstack (via nova via neutron?) into the equivalent sysconfig files (ubuntu files should already *mostly* work and systemd files are underway as well). Code

Re: [openstack-dev] [TaskFlow] TaskFlow persistence: Job failure retry

Seems like u could just use http://docs.openstack.org/developer/taskflow/jobs.html (it appears that you may not be?); the job itself would when failed be then worked on by a different job consumer. Have u looked at those? It almost appears that u are using celery as a job distribution system

Re: [openstack-dev] [higgins] Continued discussion from the last team meeting

I get this idea, I just want to bring up the option that if u only start off with a basic vision, then u basically get that as a result, vs IMHO where u start off with a bigger/greater vision and work on getting there. I'd personally rather work on a project that has a advanced vision vs one t

[openstack-dev] [oslo] No meeting monday

Hi all, Since it is memorial day in the US it's probably appropriate to postpone this weeks meeting; my brother (and wife and niece) will be visiting from NY and I will probably be doing touristy things with them (oh joy!) so let's meet in the normal channel (#openstack-oslo) and either just

Re: [openstack-dev] Fwd: [oslo][pylockfile] update documentation

I'll work on getting that fixed this week, Either me or one of the other owners of pylockfile (doug hellmann) should be able to get that resolved, Thanks for bringing it up! The code repository btw is at https://git.openstack.org/cgit/openstack/pylockfile (mirrored at https://github.com/ope

Re: [openstack-dev] [higgins] Docker-compose support

Cool good to know, I see https://github.com/docker/compose/pull/3535/files#diff-1d1516ea1e61cd8b44d000c578bbd0beR66 Would that be the primary API? Hard to tell what is the API there actually, haha. Is it the run() method? I was thinking more along the line that higgins could be a 'interpret

Re: [openstack-dev] [higgins] Docker-compose support

Denis Makogon wrote: Hello. It is hard to tell if given API will be final version, but i tried to make it similar to CLI and its capabilities. So, why not? 2016-05-31 22:02 GMT+03:00 Joshua Harlow mailto:harlo...@fastmail.com>>: Cool good to know, I see https://github.com/

Re: [openstack-dev] [Nova] State machines in Nova

Timofei Durakov wrote: Hi team, there is blueprint[1] that was approved during Liberty and resubmitted to Newton(with spec[2]). The idea is to define state machines for operations as live-migration, resize, etc. and to deal with them operation states. The spec PoC patches are overall good. At th

Re: [openstack-dev] [Nova] State machines in Nova

Andrew Laski wrote: On Tue, May 31, 2016, at 04:26 PM, Joshua Harlow wrote: Timofei Durakov wrote: Hi team, there is blueprint[1] that was approved during Liberty and resubmitted to Newton(with spec[2]). The idea is to define state machines for operations as live-migration, resize, etc. and

Re: [openstack-dev] [kolla] Ansible 2.0.0 functional

Out of curiosity, what keeps on changing (breaking?) in ansible that makes it so that something working in 2.0 doesn't work in 2.1? Isn't the point of minor version numbers like that so that things in the same major version number still actually work... Steven Dake (stdake) wrote: Hey folks,

Re: [openstack-dev] [Nova] State machines in Nova

Sounds similar to https://review.openstack.org/#/c/224022/ (which is the ironic version of expose state machine transitions over the REST API); probably useful to read over the review commentary there and/or talk to the ironic folks about that before doing much here (to learn some of the pros/c

Re: [openstack-dev] [Nova] State machines in Nova

Miles Gould wrote: On 31/05/16 21:03, Timofei Durakov wrote: there is blueprint[1] that was approved during Liberty and resubmitted to Newton(with spec[2]). The idea is to define state machines for operations as live-migration, resize, etc. and to deal with them operation states. +1 to introdu

Re: [openstack-dev] [TaskFlow] TaskFlow persistence: Job failure retry

his along with late_acks makes the application highly fault tolerant. http://docs.celeryproject.org/en/latest/faq.html#faq-acks-late-vs-retry Regards, Kanthi On Sat, May 28, 2016 at 1:51 AM, Joshua Harlow mailto:harlo...@fastmail.com>> wrote: Seems like u could just use http://d

Re: [openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...

Deja, Dawid wrote: On Thu, 2016-05-05 at 11:08 +0700, Renat Akhmerov wrote: On 05 May 2016, at 01:49, Mehdi Abaakouk mailto:sil...@sileht.net>> wrote: Le 2016-05-04 10:04, Renat Akhmerov a écrit : No problem. Let’s not call it RPC (btw, I completely agree with that). But it’s one of the mes

Re: [openstack-dev] [TaskFlow] TaskFlow persistence: Job failure retry

Cool, we'll feel free to find the taskflow (and others) either in #openstack-oslo or #openstack-state-management if you have any questions. -Josh pnkk wrote: I am working on NFV orchestrator based on MANO Regards, Kanthi On Thu, Jun 2, 2016 at 3:00 AM, Joshua Harlow mailto:

Re: [openstack-dev] [ironic] using ironic as a replacement for existing datacenter baremetal provisioning

Clint Byrum wrote: Excerpts from Kris G. Lindgren's message of 2016-06-06 20:44:26 +: Hi ironic folks, As I'm trying to explore how GoDaddy can use ironic I've created the following in an attempt to document some of my concerns, and I'm wondering if you folks could help myself identity ong

Re: [openstack-dev] [ironic] using ironic as a replacement for existing datacenter baremetal provisioning

Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2016-06-07 08:46:28 -0700: Clint Byrum wrote: Excerpts from Kris G. Lindgren's message of 2016-06-06 20:44:26 +: Hi ironic folks, As I'm trying to explore how GoDaddy can use ironic I've created the following in an attempt to doc

Re: [openstack-dev] [ironic] using ironic as a replacement for existing datacenter baremetal provisioning

Joshua Harlow wrote: Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2016-06-07 08:46:28 -0700: Clint Byrum wrote: Excerpts from Kris G. Lindgren's message of 2016-06-06 20:44:26 +: Hi ironic folks, As I'm trying to explore how GoDaddy can use ironic I

Re: [openstack-dev] [ironic] using ironic as a replacement for existing datacenter baremetal provisioning

Devananda van der Veen wrote: On 06/07/2016 09:55 AM, Joshua Harlow wrote: Joshua Harlow wrote: Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2016-06-07 08:46:28 -0700: Clint Byrum wrote: Excerpts from Kris G. Lindgren's message of 2016-06-06 20:44:26 +: Hi ir

Re: [openstack-dev] [ironic] using ironic as a replacement for existing datacenter baremetal provisioning

Jay Pipes wrote: On 06/07/2016 02:34 PM, Joshua Harlow wrote: I'll work on this list, as some folks that are trying start to try to connect ironic (IMHO without nova, because well kubernetes is enough like nova that there isn't a need for 2-layers of nova-like-systems at that p

Re: [openstack-dev] [ironic] using ironic as a replacement for existing datacenter baremetal provisioning

Jim Rollenhagen wrote: 1.)Nova<-> ironic interactions are generally seem terrible? I don't know if I'd call it terrible, but there's friction. Things that are unchangable on hardware are just software configs in vms (like mac addresses, overlays, etc), and things that make no sense in VMs are p

Re: [openstack-dev] [all] what do you work on upstream of OpenStack?

Just to clarify, upstream of openstack would be say in a library that interacts with openstack (jclouds for example); or docs that jclouds has about openstack or something like that? Or do u mean upstream of openstack to mean anything not openstack but openstack related (for example there are

[openstack-dev] The oslo-incubator and you

Hi all, I just wanted to let everyone know that the oslo-incubator[1, 2] repository is now officially closed for business (it has been deprecated for a long time now) and that it would be much appreciated that any projects with code (or open reviews to remove that code) to merge those sooner

Re: [openstack-dev] There is no Jenkins, only Zuul

James E. Blair wrote: Since its inception, the OpenStack project has used Jenkins to perform its testing and artifact building. When OpenStack was two git repos, we had one Jenkins master, a few slaves, and we configured all of our jobs manually in the web interface. It was easy for a new proje

[openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

Hi folks, I was noticing that its possible to do something like: $ nova meta josh-testr3 set "e=f" Then inside the VM I can do the following to eventually see that this changes shows up in the instance metadata exposed at the following: $ curl -s http://169.254.169.254/openstack/latest/meta_

Re: [openstack-dev] [all] Proposal: Architecture Working Group

Thanks for getting this started Clint, I'm happy and excited to be involved in helping try to guide the whole ecosystem together (it's also why I like being in oslo) to a architecture that is more cohesive (and is more of something that we can say to our current or future children that we were

Re: [openstack-dev] [nova] ability to set metadata on instances (but config drive is not updated)

Agreed, it appears supported right-now (whether intentional or not), So the question at that point is what can we do to make it better... I think we all agree that the config-drive probably shouldn't have the equivalent of the metadata service in it; because if the metadata service can change

Re: [openstack-dev] [all] Proposal: Architecture Working Group

Mike Perez wrote: On 11:31 Jun 20, Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2016-06-17 15:33:25 -0700: Thanks for getting this started Clint, I'm happy and excited to be involved in helping try to guide the whole ecosystem together (it's also why I like being in oslo) to a a

[openstack-dev] [nova] Rabbit-mq 3.4 crashing (anyone else seen this?)

Hi ops and dev-folks, We over at godaddy (running rabbitmq with openstack) have been hitting a issue that has been causing the `rabbit_mgmt_db` consuming nearly all the processes memory (after a given amount of time), We've been thinking that this bug (or bugs?) may have existed for a while

Re: [openstack-dev] [Openstack-operators] [nova] Rabbit-mq 3.4 crashing (anyone else seen this?)

ng and rabbit and hope it goes away. I'll also probably tweak the settings on retention of events then too. Also for the record the GC doesn't seem to help at all. On Jul 5, 2016 11:05 AM, "Joshua Harlow" mailto:harlo...@fastmail.com>> wrote: Hi ops and dev-folks,

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

That's sad, how can we fix the fact that users/deployments have gone off into their own silos and may be running their own forks; what went wrong (besides some of the obvious stuff that I think I know about, that others probably don't) that resulted in this happening? Seems like something we c

Re: [openstack-dev] [nova][nova-docker] Retiring nova-docker project

Edward Leafe wrote: On Jul 7, 2016, at 8:33 PM, Joshua Harlow wrote: That's sad, how can we fix the fact that users/deployments have gone off into their own silos and may be running their own forks; what went wrong (besides some of the obvious stuff that I think I know about, that o

Re: [openstack-dev] [nova] Minimal secure identification of a new VM

Adam Young wrote: We have a use case where we want to register a newly spawned Virtual machine with an identity provider. Heat also has a need to provide some form of Identity for a new VM. Looking at the set of utilities right now, there does not seem to be a secure way to do this. Injecting

Re: [openstack-dev] [all][stackalytics] Gaming the Stackalytics stats

+1 from me also, I also use +0 for question asking and the like, because IMHO that's not what -1 are for. As for myself losing stackalytics stats when *I* do this (ie using +0 instead of -1), meh, I got better things in my life to think/care about :-P -Josh Nikhil Komawar wrote: Thanks Amr

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Flavio Percoco wrote: On 11/04/16 18:05 +, Amrith Kumar wrote: Adrian, thx for your detailed mail. Yes, I was hopeful of a silver bullet and as we’ve discussed before (I think it was Vancouver), there’s likely no silver bullet in this area. After that conversation, and some further experi

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

h the special case that trove creates such a format on-behalf of some other consumer, aka the trove user). As for the app-catalog use case, the app-catalog project (http://apps.openstack.org) is working on some of that. Thanks, Kevin ____ From: Joshua Harlo

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

maybe I am dreaming to much right now :-P If you ignore the non container use case, I think it might be fairly easily mappable to all three COE's though. Thanks, Kevin ________ From: Joshua Harlow [harlo...@fastmail.com] Sent: Tuesday, April 12, 2016 2:2

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Steve Baker wrote: On 13/04/16 11:07, Joshua Harlow wrote: Fox, Kevin M wrote: I think my head just exploded. :) That idea's similar to neutron sfc stuff, where you just say what needs to connect to what, and it figures out the plumbing. Ideally, it would map somehow to heat& d

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

es to interface and upper systems, much smaller image and much better developer workflow. Peng - Hyper_ Secure Container Cloud On Wed, Apr 13, 2016 5:23 AM, Joshua Harlow harlo...@fastmail.com <mailto:harlo...@fastmail.com> wrote: _

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

Thierry Carrez wrote: Fox, Kevin M wrote: I think my head just exploded. :) That idea's similar to neutron sfc stuff, where you just say what needs to connect to what, and it figures out the plumbing. Ideally, it would map somehow to heat & docker COE & neutron sfc to produce a final set of de

Re: [openstack-dev] [release][oslo] pbr 1.9.0 release

I think we need the following fixes first? https://review.openstack.org/#/c/305080/ If so let's work on merging that (if not let me know), I also see the following: https://review.openstack.org/#/c/305604/ Does that include a fix for your issue? -Josh Takashi Yamamoto wrote: hi, this vers

Re: [openstack-dev] [oslo] Removing Nova specifics from oslo.log

Victor Stinner wrote: Le 13/04/2016 22:54, Julien Danjou a écrit : There's a bunch of projects that have no intention of using oslo.context, so depending and referring to it by default is something I'd love to fade away. It looks like Oslo has an identity crisis :-) Well not entirely IMHO. I

[openstack-dev] [oslo] Newton Design Summit Session Schedule

Howdy (oslo and other) folks, I put up the timings/titles[1] and etherpads[2] for the oslo summit sessions (workroom(s) and fishbowl(s)) which should be in a good state (but may be edited a little), feel free to suggest better titles, or better descriptions or even fill out an etherpad or two

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

Andreas Jaeger wrote: On 04/17/2016 09:15 PM, Davanum Srinivas wrote: Hi Oslo folks, Andreas and others, Over the weekend oslo.log 3.4.0 was released. This broke keystone CI jobs [2], even though the 3.4.0 was not specified in upper-constraints as keystone jobs were not honoring the upper-const

[openstack-dev] [nova] Question on removal of 'arbitrary' pluggable interfaces

Hi nova folks, I was reading over the following: http://lists.openstack.org/pipermail/openstack-operators/2016-April/010186.html And I am wondering if there is a list of all the plugin points and there schedule for being deprecated and then removed (or am I misreading that mail/thread?). I

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

compatible changes, and this doesn't seem to be one. Doug Thanks, Dims On Mon, Apr 18, 2016 at 1:42 PM, Joshua Harlow wrote: Andreas Jaeger wrote: On 04/17/2016 09:15 PM, Davanum Srinivas wrote: Hi Oslo folks, Andreas and others, Over the weekend oslo.log 3.4.0 was released. This broke k

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

Davanum Srinivas wrote: On Mon, Apr 18, 2016 at 4:28 PM, Joshua Harlow wrote: Okie, the following reviews are up: https://review.openstack.org/307461 (oslo.concurrency) https://review.openstack.org/307463 (oslo.cache) https://review.openstack.org/307464 (oslo.privsep) https

Re: [openstack-dev] [oslo][keystone][documentation][gate] Babel dependency for oslo.log

Your wish has been delivered ;) https://review.openstack.org/#/c/307983/ -Josh Andreas Jaeger wrote: On 2016-04-18 19:42, Joshua Harlow wrote: Andreas Jaeger wrote: On 04/17/2016 09:15 PM, Davanum Srinivas wrote: Hi Oslo folks, Andreas and others, Over the weekend oslo.log 3.4.0 was

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Feel free to take the following (if its similar to what u are thinking) https://github.com/openstack/anvil/blob/master/anvil/utils.py#L90 IMHO though if its a decorator, the retrying library can already perform this: https://pypi.python.org/pypi/retrying And a couple of the oslo-cores (jd, m

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Thierry Carrez wrote: Adrian Otto wrote: This pursuit is a trap. Magnum should focus on making native container APIs available. We should not wrap APIs with leaky abstractions. The lowest common denominator of all COEs is an remarkably low value API that adds considerable complexity to Magnum th

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Salvatore Orlando wrote: On 21 April 2016 at 16:54, Boden Russell mailto:boden...@gmail.com>> wrote: On 4/20/16 3:29 PM, Doug Hellmann wrote: > Yes, please, let's try to make that work and contribute upstream if we > need minor modifications, before we create something new. W

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Boden Russell wrote: On 4/20/16 3:29 PM, Doug Hellmann wrote: Yes, please, let's try to make that work and contribute upstream if we need minor modifications, before we create something new. We can leverage the 'retrying' module (already in global requirements). It lacks a few things we need,

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

Boden Russell wrote: I haven't spent much time on this, so the answers below are a first approximation based on a quick visual inspection (e.g. subject to change when I get a chance to hack on some code). On 4/21/16 12:10 PM, Salvatore Orlando wrote: Can you share more details on the "few thing

Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

I thought this was also what the goal of https://cncf.io/ was starting to be? Maybe to early to tell if that standardization will be an real outcome vs just an imagined outcome :-P -Josh Fox, Kevin M wrote: The COE's have a pressure not to standardize their api's between competing COE's. If

Re: [openstack-dev] More on the topic of DELIMITER, the Quota Management Library proposal

Since people will be on a plane soon, I threw this together as a example of a quota engine (the zookeeper code does even work, and yes it provides transactional semantics due to the nice abilities of zookeeper znode versions[1] and its inherent consistency model, yippe). https://gist.github.

[openstack-dev] [oslo] No weekly meeting next week

Howday folks, Since there is a summit next week it is highly likely that we will not have a weekly meeting next week (since there just won't be enough people online) so I just wanted to make sure people don't show up (although folks that aren't going to the summit are welcome to still show up

Re: [openstack-dev] [neutron] Discussing DLMs in the Unplugged Track

I'll try to be there as well, since I know a little bit about tooz ;) -Josh Gary Kotton wrote: Hi, I suggest that you speak with Kobi Samoray - he implemented this for the vmware_nsx repository using tooz. Its pretty cool. Thanks Gary On 4/23/16, 5:16 PM, "John Schwarz" wrote: Hi guys,

Re: [openstack-dev] [oslo.config] Encrypt the sensitive options

Daniel P. Berrange wrote: On Tue, Apr 26, 2016 at 08:19:23AM -0500, Doug Hellmann wrote: Excerpts from Guangyu Suo's message of 2016-04-26 07:28:42 -0500: Hello, oslo team For now, some sensitive options like password or token are configured as plaintext, anyone who has the priviledge to read

Re: [openstack-dev] [magnum] Proposed Revision to Magnum's Mission

Cool, abandoning mine as it seems the team is working on one anyway. (I just didn't want a mission statement change to wait until some unknown project comes along, someday in the future...) -Josh Davanum Srinivas wrote: Adrian, fyi, there's one more already filed by Josh - https://review.op

[openstack-dev] [oslo] Reminder, no IRC meeting this week

Just a reminder to folk, I'll send out the summit notes today and get releases going but as we just had a summit last week, a meeting today on IRC doesn't seem needed (and most people may not be back yet from the summit anyway), Have a great week folks (and it was great seeing everyone)! -Jo

[openstack-dev] [oslo] A bunch of releases

Just wanted to let people know about the new proposed releases (since there wasn't a IRC meeting today): If folks think these need updates or version number changes please comment on the review (or here). https://review.openstack.org/#/c/311812/ (the release proposals) https://review.opensta

[openstack-dev] [oslo] Austin summit session recap(s)

Howday all, Since I know not everyone from the oslo community was able to attend the austin summit I just wanted to send out *my* version of the oslo sessions notes and next steps (others are free/encouraged to respond with there own) so that those folks can catch up and/or get up to speed.

[openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...

Howdy folks, So I meet up with *some* of the mistral folks during friday last week at the summit and I was wondering if we as a group can find a path to help that project move forward in their desire to have some kind of process than ack (vs the existing ack then process) in there usage of the

Re: [openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...

So then let's all get onboard https://review.openstack.org/#/c/260246/? I've yet to see what all these things called 'process-than-ack' not seemingly fit into that API in that review. IMHO most of what people are trying to fit into oslo.messaging here isn't really messages but are jobs to be c

Re: [openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...

Dmitry Tantsur wrote: On 05/03/2016 11:24 PM, Joshua Harlow wrote: Howdy folks, So I meet up with *some* of the mistral folks during friday last week at the summit and I was wondering if we as a group can find a path to help that project move forward in their desire to have some kind of

Re: [openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...

Dmitry Tantsur wrote: On 05/07/2016 01:00 AM, Joshua Harlow wrote: Dmitry Tantsur wrote: On 05/03/2016 11:24 PM, Joshua Harlow wrote: Howdy folks, So I meet up with *some* of the mistral folks during friday last week at the summit and I was wondering if we as a group can find a path to help

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