Re: [openstack-dev] [ci-cd] Jenkinsfile support (or repo/s for them?)

Monty Taylor wrote: On 08/15/2016 02:47 PM, Joshua Harlow wrote: With nodepool and Zuul, there's simply no purpose to Jenkins any more for me. Fair point, and no disagreement on that effort being good and all; though I can't quite say what companies that do use jenkins (the majority

Re: [openstack-dev] [ci-cd] Jenkinsfile support (or repo/s for them?)

Sure, I get your point. Disagree that it's not a worthy effort to want to rid the world of impossible-to-reason-about CI configurations, but I get your point. I'm more of in disagreement that running two systems that are sorta similar is worthy (2 things to maintain, support, operate...),

Re: [openstack-dev] [ci-cd] Jenkinsfile support (or repo/s for them?)

I've been experimenting/investigating/playing around with the 'new' jenkins pipeline support (see https://jenkins.io/doc/pipeline/ for those who don't know what this is) and it got me thinking that there are probably X other people/groups/companies that are doing the same thing and that to me

Re: [openstack-dev] [infra] Jenkinsfile support (or repo/s for them?)

Much appreciated! -Josh Anita Kuno wrote: I suggest using the [infra] tag in the subject line if you are looking for input from the infra team. I have changed it for my reply. Thanks, Anita. __ OpenStack Development

[openstack-dev] [ci-cd] Jenkinsfile support (or repo/s for them?)

Hi folks, I've been experimenting/investigating/playing around with the 'new' jenkins pipeline support (see https://jenkins.io/doc/pipeline/ for those who don't know what this is) and it got me thinking that there are probably X other people/groups/companies that are doing the same thing and

Re: [openstack-dev] [cinder] [nova] locking concern with os-brick

Sean Dague wrote: On 08/14/2016 06:23 PM, Patrick East wrote: We were talking through some of the implications of this change in #openstack-nova, and the following further concerns came out. 1) Unix permissions for services in distros Both Ubuntu and RHEL have a dedicated service user per

Re: [openstack-dev] [cinder] [nova] locking concern with os-brick

Clint Byrum wrote: Excerpts from Joshua Harlow's message of 2016-08-13 20:04:13 -0700: The larger issue here IMHO is that there is now a API around locking that might be better suited targeting an actual lock management system (say redis or zookeeper or etcd or ...). The more I look at this,

Re: [openstack-dev] [cinder] [nova] locking concern with os-brick

Sean McGinnis wrote: On Fri, Aug 12, 2016 at 05:55:47AM -0400, Sean Dague wrote: A devstack patch was pushed earlier this cycle around os-brick - https://review.openstack.org/341744 Apparently there are some os-brick operations that are only safe if the nova and cinder lock paths are set to be

Re: [openstack-dev] pydotplus (taskflow) vs pydot-ng (fuel)

If wha'ts most alive is pydot-ng that's fine with me. One of the reasons taskflow went with pydotplus is that it's used in the larger networkx graph library (which taskflow happens to use for its internal workflow graph):

Re: [openstack-dev] Retirement of openstack/cloud-init repository

Right this is step #1 there, although slightly different because this project isn't really retired, its just moved to a different place; but good enough :-P Andreas Jaeger wrote: On 07/30/2016 03:20 AM, Morgan Fainberg wrote: [...] As I recall we no longer "move" the git repositories. We

[openstack-dev] Retirement of openstack/cloud-init repository

Hi all, I'd like to start the retirement (well actually it's more of shifting) of the openstack/cloud-init repository to its new location that *finally* removes the old bzr version of itself. The long story is that the cloud-init folks (myself included) moved the bzr repository to

Re: [openstack-dev] Switch 'all?' openstack bots to errbot plugins?

Jul 29, 2016 at 1:49 AM, Joshua Harlow<harlo...@fastmail.com> wrote: Hi folks, I was thinking it might be useful to see what other folks think about switching (or migrating all the current bots we have in openstack) to be based on errbot plugins. Errbot @ http://errbot.io/en/latest/ take

Re: [openstack-dev] [infra] Switch 'all?' openstack bots to errbot plugins?

' since I don't like a bunch of repos (seems like a premature optimization ~at this time~), but I could see either way on this one. Jeremy Stanley wrote: On 2016-07-29 09:41:40 -0700 (-0700), Joshua Harlow wrote: [...] What shall we name it??? [...] Also, one bucket repo for OpenStack community

Re: [openstack-dev] [infra] Switch 'all?' openstack bots to errbot plugins?

I prefer 'one bucket repo for OpenStack community Errbot plug-ins' since I don't like a bunch of repos (seems like a premature optimization ~at this time~), but I could see either way on this one. Jeremy Stanley wrote: On 2016-07-29 09:41:40 -0700 (-0700), Joshua Harlow wrote: [...] What

Re: [openstack-dev] [infra] Switch 'all?' openstack bots to errbot plugins?

Doug Hellmann wrote: Excerpts from Joshua Harlow's message of 2016-07-29 08:47:32 -0700: Jeremy Stanley wrote: On 2016-07-28 23:17:52 -0700 (-0700), Morgan Fainberg wrote: As I recall this has been on a long list of "we want to do it". It really just comes down to someone putting effort into

Re: [openstack-dev] [infra] Switch 'all?' openstack bots to errbot plugins?

Jeremy Stanley wrote: On 2016-07-28 23:17:52 -0700 (-0700), Morgan Fainberg wrote: As I recall this has been on a long list of "we want to do it". It really just comes down to someone putting effort into making it happen. Yes, it's come up semi-often (also Joshua mentioned this to me over IRC

[openstack-dev] Switch 'all?' openstack bots to errbot plugins?

Hi folks, I was thinking it might be useful to see what other folks think about switching (or migrating all the current bots we have in openstack) to be based on errbot plugins. Errbot @ http://errbot.io/en/latest/ takes a slightly different approach to bots and treats each bot 'feature' as

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Michael Still wrote: On Tue, Jul 26, 2016 at 4:44 PM, Fox, Kevin M > wrote: [snip] The issue is, as I see it, a parallel activity to one of the that is currently accepted into the Big Tent, aka Containerized Deployment [snip] This seems

Re: [openstack-dev] [neutron] [tooz] DLM benchmark results

Hi John, Thanks for gathering this info, Do you have the versions of the backend that were used here (particularly relevant for etcd which has a new release pretty frequently). It'd be useful to capture that info also :) John Schwarz wrote: Hi everyone, Following [1], a few of us sat down

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

Duncan Thomas wrote: On 20 July 2016 at 19:57, James Bottomley > wrote: OK, I accept your analogy, even though I would view currency as the will to create and push patches. The problem you

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

Julien Danjou wrote: On Mon, Jul 18 2016, Joshua Harlow wrote: Thus why I think the starting of the architecture working group is a good thing; because I have a believe that people are forgetting among all of this that such a group holds a lot of the keys to the kingdom (whether u, the reader

Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

Hayes, Graham wrote: On 18/07/16 22:27, Ronald Bradford wrote: Hi All, For Oslo libraries we ensure that API's are backward compatible for 1+ releases. When an Oslo API adds a new class attribute (as in this example of is_admin_project and 4 other attributes) added to Oslo Context in 2.6.0,

Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

I applaud this (since I know this kind of question and work is really really hard). So thanks for starting and keeping 'hard' questions going because without someone pushing the limit here (and/or raising the questions) I too fear what u fear and that we may be obsoleting ourselves by

Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

Also to go further into a little mini-retrospective we did during our meeting. This got released and passed through the periodic jobs we run before releasing in oslo due to primarily a timing glitch. When the patch[0] was proposed to the release repo the nova periodic jobs were fine and

Re: [openstack-dev] [ironic] [oslo] Stevedore 1.16 breaks IPA gate

I assume this is connected into: https://review.openstack.org/#/c/334014/ Which was proposed a few weeks ago, I'd be nice to identify the causing review and see if we can find the authors to learn about why, If its needed, proposing a requirements block is fine with me (until we can get to

Re: [openstack-dev] [kolla] New specs process - a dicussion

Something for consideration to make the specs process not to painful and one that I think (?) glance pioneered is to have a 'bigger spec' and a 'smaller spec' template. https://github.com/openstack/glance-specs/blob/master/specs/lite-specs.rst (smaller)

Re: [openstack-dev] Mascot/logo for your project

Woot, we in oslo talked about it during today's meeting and from what I can tell we'd like to have the moose that we currently have adjusted as needed and continue forward with that (we've been using this logo for a while already in stickers...):

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

Edward Leafe wrote: On Jul 7, 2016, at 8:33 PM, Joshua Harlow<harlo...@fastmail.com> 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

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

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

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" <harlo...@fastmail.com <mailto:harlo...@fastmail.com>> wrote: Hi ops and dev-folks, We over at godaddy (running rabbitmq wit

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

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

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

[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

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

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

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

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 point

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

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've created

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

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

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 <harlo...@fastmail.

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

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

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 <harlo...@fastmail.com <mailto:harlo...@fastmail.com>> wrote: Seems like u 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

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

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

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

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

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 <harlo...@fastmail.com <mailto:harlo...@fastmail.com>>: Cool good to know

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

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

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

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

[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] [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<harlo...@fastmail.com> Reply: OpenStack Development Mailing List (not for

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

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

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

Morgan Fainberg wrote: On Thu, May 19, 2016 at 6:19 AM, Thierry Carrez > 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

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<harlo...@fastmail.com> 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/

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

[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

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

So it was under my belief that at its current stage that this library would start off on its own, and not initially start of (just yet) in oslo (as I think the oslo group wants to not be the blocker/requirement for a library being a successful thing + the cost of it being in oslo may not be

Re: [openstack-dev] Wiki

Thierry Carrez wrote: Sean Dague wrote: On 05/09/2016 06:53 PM, Monty Taylor wrote: On 05/09/2016 05:45 PM, Robert Collins wrote: IIRC mediawiki provides RSS of changes... maybe just using the wiki more would be a good start, and have zero infra costs? We'd actually like to start using the

Re: [openstack-dev] Team blogs

Jeremy Stanley wrote: On 2016-05-09 19:46:14 -0400 (-0400), Sean Dague wrote: Honestly, I'm really liking that more of them are hitting the mailing list proper this time around. Discoverability is key. The mailing list is a shared medium, archived forever. I feel the same (says the guy who is

[openstack-dev] Team blogs

After seeing the amount of summit recaps and the scattered nature of these (some on the ML, some on etherpads, some on personal blogs); I am starting to wonder if we should again bring up the question of having infra (and I guess the foundation?) support/provide a place for team blogs...

[openstack-dev] [nova][ironic] Specs matcher and its journey through time

Hi all, Recently jroll proposed the following into oslo.utils https://review.openstack.org/#/c/308398/ This moves the spec matching (if that's what u can call it) to oslo.utils so that it can be shared by nova and ironic (which I think is a fair thing to do, although personally I don't like

Re: [openstack-dev] [tc] supporting Go

Clint Byrum wrote: Excerpts from Edward Leafe's message of 2016-05-09 12:17:40 -0700: On May 9, 2016, at 1:58 PM, Hayes, Graham wrote: This is not a "Go seems cool - lets go try that" decision from us - we know we have a performance problem with one of our components,

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

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

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

[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

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

[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)!

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 -

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

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

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

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

Salvatore Orlando wrote: On 21 April 2016 at 16:54, 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

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

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,

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

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<harlo...@fastmail.com> 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.p

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

changes, and this doesn't seem to be one. Doug Thanks, Dims On Mon, Apr 18, 2016 at 1:42 PM, Joshua Harlow<harlo...@fastmail.com> 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] [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

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

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

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

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

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