Re: [openstack-dev] [TC][Keystone] Rehashing the Pecan/Falcon/other WSGI debate

Hi all, To be clear, both Pecan and Falcon are actively maintained and have healthy communities. In any case, I tend to point OpenStack projects toward Pecan as the default choice, since that lets you take advantage of all the benefits standardization has to offer. Of course, you need to quantify

[openstack-dev] [horizon] [zaqar] Need some help designing push notifications

Hi everyone, In the past we’ve discussed how Zaqar could be leveraged by Horizon to get status notifications and such without having to poll backend APIs. In this way, the user experience could be improved while also removing some load from those APIs. During Kilo the team is finally going to ge

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

Great question. So, some use cases, like guest agent, would like to see something around ~20ms if the agent is needing to respond to requests from a control surface/panel while a user clicks around. I spoke with a social media company who was also interested in low latency just because they have

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 3)

their careful coding and reviews! On 9/16/14, 2:43 PM, "Kurt Griffiths" wrote: >Results are now posted for all workloads for 2x web heads and 1x Redis >proc (Configuration 2). Stats are also available for the write-heavy >workload with 2x webheads and 2x redis procs (Configura

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 3)

higher load. Multiple load generator boxes would need to be used (noted on the etherpad). On 9/16/14, 10:23 AM, "Kurt Griffiths" wrote: >Hi crew, as promised I’ve continued to work through the performance test >plan. I’ve started a wiki page for the next batch of tests and r

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 3)

("keepalive_timeout 65;”). FWIW, I started an etherpad to track a shortlist of ideas: https://etherpad.openstack.org/p/zaqar-performance-testing On 9/16/14, 11:58 AM, "Jay Pipes" wrote: >On 09/16/2014 11:23 AM, Kurt Griffiths wrote: >> Hi crew, as promised I’ve conti

[openstack-dev] [zaqar] Juno Performance Testing (Round 3)

Hi crew, as promised I’ve continued to work through the performance test plan. I’ve started a wiki page for the next batch of tests and results: https://wiki.openstack.org/wiki/Zaqar/Performance/PubSub/Redis I am currently running the same tests again with 2x web heads, and will update the wiki p

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

Right, graphing those sorts of variables has always been part of our test plan. What I’ve done so far was just some pilot tests, and I realize now that I wasn’t very clear on that point. I wanted to get a rough idea of where the Redis driver sat in case there were any obvious bug fixes that need

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

On 9/11/14, 2:11 PM, "Devananda van der Veen" wrote: >OK - those resource usages sound better. At least you generated enough >load to saturate the uWSGI process CPU, which is a good point to look >at performance of the system. > >At that peak, what was the: >- average msgs/sec >- min/max/avg/stde

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

On 9/10/14, 3:58 PM, "Devananda van der Veen" wrote: >I'm going to assume that, for these benchmarks, you configured all the >services optimally. Sorry for any confusion; I am not trying to hide anything about the setup. I thought I was pretty transparent about the way uWSGI, MongoDB, and Redis

Re: [openstack-dev] [zaqar] Juno Performance Testing (Round 2)

Thanks! Looks good. Only thing I noticed was that footnotes were still referenced, but did not appear at the bottom of the page. On 9/10/14, 6:16 AM, "Flavio Percoco" wrote: >I've collected the information from both performance tests and put it in >the project's wiki[0] Please, double check :D

[openstack-dev] [zaqar] Juno Performance Testing (Round 2)

Hi folks, In this second round of performance testing, I benchmarked the new Redis driver. I used the same setup and tests as in Round 1 to make it easier to compare the two drivers. I did not test Redis in master-slave mode, but that likely would not make a significant difference in the results s

Re: [openstack-dev] [Zaqar] Comments on the concerns arose during the TC meeting

Thanks for your comments Gordon. I appreciate where you are coming from and I think we are actually in agreement on a lot of things. I just want to make it clear that from the very beginning of the project the team has tried to communicate (but perhaps could have done a better job at it) that we a

Re: [openstack-dev] [Zaqar] FFE request for API v1.1 Response Document Changes

Sounds OK to me, assuming we can get this done in the next week so the team still has time for comprehensive testing (and we commit thereto) before the RC. On 9/4/14, 1:39 PM, "Flavio Percoco" wrote: >On 09/04/2014 06:01 PM, Victoria Martínez de la Cruz wrote: >> Hi all, >> >> I would like to r

Re: [openstack-dev] [Zaqar] Early proposals for design summit sessions

Thanks Flavio, I added a few thoughts. On 8/28/14, 3:27 AM, "Flavio Percoco" wrote: >Greetings, > >I'd like to join the early coordination effort for design sessions. I've >shamelessly copied Doug's template for Oslo into a new etherpad so we >can start proposing sessions there. > >https://ether

Re: [openstack-dev] [zaqar] [marconi] Juno Performance Testing (Round 1)

Sure thing, I’ll add that to my list of things to try in “Round 2” (coming later this week). On 8/28/14, 9:05 AM, "Jay Pipes" wrote: >On 08/26/2014 05:41 PM, Kurt Griffiths wrote: >> * uWSGI + gevent >> * config: http://paste.

Re: [openstack-dev] [zaqar] [marconi] Removing GET message by ID in v1.1 (Redux)

Thanks everyone for your feedback. I think we have a consensus that this sort of change would be best left to v2 of the API. We can start planning v2 of the API at the Paris summit, and target some kind of “community preview” of it to be released as part of Kilo. On 8/29/14, 11:02 AM, "Everett Toe

Re: [openstack-dev] [Keystone][Marconi][Heat] Creating accounts in Keystone

On 8/25/14, 9:50 AM, "Ryan Brown" wrote: >I'm actually quite partial to roles because, in my experience, service >accounts rarely have their credentials rotated more than once per eon. >Having the ability to let instances grab tokens would certainly help >Heat, especially if we start using Zaqar

[openstack-dev] [zaqar] [marconi] Removing GET message by ID in v1.1 (Redux)

Crew, as we continue implementing v1.1 in anticipation for a “public preview” at the summit, I’ve started to wonder again about removing the ability to GET a message by ID from the API. Previously, I was concerned that it may be too disruptive a change and should wait for 2.0. But consider this:

Re: [openstack-dev] [zaqar] [marconi] Juno Performance Testing (Round 1)

Correction: there were 25 workers per producer process, not 10. On 8/26/14, 4:41 PM, "Kurt Griffiths" wrote: >### Event Broadcasting (Balanced) ### > >This test uses the same number of producers and consumers, but note that >the observers are still listing (up to) 5 mes

[openstack-dev] [zaqar] [marconi] Juno Performance Testing (Round 1)

Hi folks, I ran some rough benchmarks to get an idea of where Zaqar currently stands re latency and throughput for Juno. These results are by no means conclusive, but I wanted to publish what I had so far for the sake of discussion. Note that these tests do not include results for our new Redis d

Re: [openstack-dev] [Marconi] All-hands documentation day

I’m game for thursday. Love to help out. On 8/1/14, 2:26 AM, "Flavio Percoco" wrote: >On 07/31/2014 09:57 PM, Victoria Martínez de la Cruz wrote: >> Hi everyone, >> >> Earlier today I went through the documentation requirements for >> graduation [0] and it looks like there is some work do to. >

Re: [openstack-dev] [marconi] Proposal to add Victoria Martínez de la Cruz as a core reviewer

ct: Re: [openstack-dev] [marconi] Proposal to add Victoria Martínez de la Cruz as a core reviewer There is another thread going on for the same http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg30897.html We sure need vkmc in the core :) From: Kurt Griffiths mailto:kurt.griff

[openstack-dev] [marconi] Proposal to add Victoria Martínez de la Cruz as a core reviewer

Hi crew, I’d like to propose Vicky (vkmc) be added to Marconi’s core reviewer team. She is a regular contributor in terms of both code and reviews, is an insightful and regular participant in team discussions, and leads by example in terms of quality of work, treating others as friends and famil

[openstack-dev] [marconi] Juno / Graduation Planning Session Today

Hi everyone, sorry for the short notice, but we are going to hold a special roadmap planning meeting today. Everyone is welcome to attend, but I esp. need core reviewers to attend: When: 2100 UTC Where: #openstack-marconi Agenda: https://etherpad.openstack.org/p/marconi-scratch Hope to see you

[openstack-dev] [marconi] New name for the project

Hi everyone, we have discussed a few new names for the project to avoid trademark issues. Previously, we had chosen “Naav” but several people weren’t feeling great about that name. So, we discussed this today in #openstack-marconi and got consensus to rename Marconi to Zaqar. If anyone has any

Re: [openstack-dev] [marconi] Meeting time change

Oops, sorry folks, one correction. We will be meeting on Mondays starting next week, rather than Tuesdays as we have been. This week we will not hold our regular meeting, but may do a special j-3 planning session (stay tuned for details). On 7/28/14, 10:43 AM, "Kurt Griffiths" wrote:

Re: [openstack-dev] [marconi] Meeting time change

AM, "Kurt Griffiths" wrote: >OK, I just checked and 1400 and 1500 are already taken, unless we want to >move our meetings to #openstack-meeting-3. If we want to stick with >#openstack-meeting-alt, it will have to be 1300 UTC. > >On 7/22/14, 5:28 PM, "Flavio Percoco

Re: [openstack-dev] [marconi] Meeting time change

OK, I just checked and 1400 and 1500 are already taken, unless we want to move our meetings to #openstack-meeting-3. If we want to stick with #openstack-meeting-alt, it will have to be 1300 UTC. On 7/22/14, 5:28 PM, "Flavio Percoco" wrote: >On 07/22/2014 06:08 PM, Kurt Griffiths

Re: [openstack-dev] [marconi] Meeting time change

FYI, we chatted about this in #openstack-marconi today and decided to try 2100 UTC for tomorrow. If we would like to alternate at an earlier time every other week, is 1900 UTC good, or shall we do something more like 1400 UTC? On 7/21/14, 11:21 AM, "Kurt Griffiths" wrote: >I th

Re: [openstack-dev] [marconi] Meeting time change

alambal wrote: >> >> On 7/16/14 4:43 AM, "Flavio Percoco" wrote: >> >>> On 07/15/2014 06:20 PM, Kurt Griffiths wrote: >>>> Hi folks, we¹ve been talking about this in IRC, but I wanted to bring >>>>it >>>> to the ML to get broa

[openstack-dev] [marconi] Meeting time change

Hi folks, we’ve been talking about this in IRC, but I wanted to bring it to the ML to get broader feedback and make sure everyone is aware. We’d like to change our meeting time to better accommodate folks that live around the globe. Proposals: Tuesdays, 1900 UTC Wednessdays, 2000 UTC Wednessday

[openstack-dev] [marconi] Async I/O for Message Store Drivers

/marconi/+spec/async-backend-drivers I’d love to get your thoughts on this; it would be great if we could get some of this work done during Juno, although I suspect we may not have enough bandwidth to get everything where we want it to be until the K cycle. -- Kurt Griffiths (kgriffs

[openstack-dev] [marconi] Python 3.3 Gate is Passing!

Hi everyone, I just wanted to to congratulate Nataliia on making Marconi one of the first OS project to pass the py33 gate! https://pbs.twimg.com/media/BrEQrZiCMAAbfEX.png:large Now, let’s make that gate voting. :D --- Kurt Griffiths (kgriffs

[openstack-dev] [marconi] Decoupling backend drivers

alternative to MongoDB. Instead, we can look into some other backends that offer a good mix of durability and performance. What does everything think about this strategy? -- Kurt Griffiths (kgriffs) ___ OpenStack-dev mailing list OpenStack-dev

[openstack-dev] [marconi] Juno-1 development milestone available

that will allow us to deliver version 1.1 for the Juno-2 milestone release. You can download the juno-1 release and review the changes here: https://launchpad.net/marconi/+milestone/juno-1 Thanks to everyone who contributed to this first milestone! It’s great to see all the new contributors. --

[openstack-dev] [marconi] ATL summit easel pad pix

Hey crew, as promised, I digitized the pages from the easel pad at our program pod in Atlanta. They are now available on the wiki along with a few notes to help everyone remember what all the scribbling is supposed to mean. :D https://wiki.openstack.org/wiki/Juno/Notes/Marconi Thanks everyone f

[openstack-dev] [marconi] Python Client 0.0.2 released

This is a minor bug-fix release. Deleting claimed messages now works as expected. You can get the latest client from PyPI, and a tarball is also available: https://pypi.python.org/pypi/python-marconiclient/ http://tarballs.openstack.org/python-marconiclient/ NOTE: Yes, the installation instructio

Re: [openstack-dev] [marconi] Reconsidering the unified API model

> Will Marconi only support HTTP as a transport, or will it add other >protocols as well? We are focusing on HTTP for Juno, but are considering adding a lower-level, persistent transport (perhaps based on WebSocket) in the K cycle. > Can anyone describe what is unique about the Marconi design wit

Re: [openstack-dev] [marconi] Reconsidering the unified API model

ouldn’t stray if need be; I am describing the API as it stands today). To my knowledge, this API can’t be mapped directly to AMQP. Perhaps thereare other types of brokers that can do it? On 6/10/14, 7:17 AM, "Gordon Sim" wrote: >On 06/09/2014 08:31 PM, Kurt Griffiths wrote: &g

[openstack-dev] [marconi] Reconsidering the unified API model

Folks, this may be a bit of a bombshell, but I think we have been dancing around the issue for a while now and we need to address it head on. Let me start with some background. Back when we started designing the Marconi API, we knew that we wanted to support several messaging patterns. We could

Re: [openstack-dev] [Marconi] Adopt Spec

: Kurt Griffiths mailto:kurt.griffi...@rackspace.com>> Date: Tuesday, June 3, 2014 at 9:34 AM To: OpenStack Dev mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Marconi] Adopt Spec I think it becomes more useful the larger your team. With a smaller team it is ea

Re: [openstack-dev] [Marconi] Adopt Spec

peration?) Maybe spec is the place for these? We should leave it to the implementor to decide, if the bp warrants a spec or not & what should be in the spec. From: Kurt Griffiths mailto:kurt.griffi...@rackspace.com>> Reply-To: "OpenStack Development Mailing List (not

Re: [openstack-dev] [Marconi] Adopt Spec

I’ve been in roles where enormous amounts of time were spent on writing specs, and in roles where specs where non-existent. Like most things, I’ve become convinced that success lies in moderation between the two extremes. I think it would make sense for big specs, but I want to be careful we use

[openstack-dev] [marconi] Removing Get and Delete Messages by ID

Crew, as discussed in the last team meeting, I have updated the API v1.1 spec to remove the ability to get one or more messages by ID. This was done to remove unnecessary complexity from the API, and to make it easier to support different t

Re: [openstack-dev] Spec repo names

> +1 to code names. Technically, if a program contains multiple projects, it would be more correct to use the program name, but at this point I think it is pretty ingrained in our culture (including IRC, mailing list and summits) to refer to things by their code/project names, so IMO using those n

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

f change goes smoothly. But this is absolutely on the list of things we would like to address. Cheers, Morgan Sent via mobile On Wednesday, May 21, 2014, Kurt Griffiths mailto:kurt.griffi...@rackspace.com>> wrote: > adding another ~10kB to each request, just to save a once-a-day call t

Re: [openstack-dev] Concerns about the ballooning size of keystone tokens

> adding another ~10kB to each request, just to save a once-a-day call to >Keystone (ie uuid tokens) seems to be a really high price to pay for not >much benefit. I have the same concern with respect to Marconi. I feel like KPI tokens are fine for control plane APIs, but don’t work so well for hig

[openstack-dev] [marconi] Juno Roadmap

Hi folks, I took the major work items we discussed at the summit and placed them into the three Juno milestones: https://wiki.openstack.org/wiki/Roadmap_(Marconi) Let me know what you think over the next few days. We will address any remaining questions and concerns at our next team meeting (ne

[openstack-dev] [marconi] State of the Union

As we look forward to the OpenStack Summit in Atlanta, I wanted to take a moment to review the state of the program. With the close of the Icehouse cycle, the team has achieved a number of exciting milestones: * Marconi's first official, production-ready "1.0" release is now available for d

[openstack-dev] [marconi] Python client library 0.0.1 released

Hi folks, I’m pleased to announce you can now pip install python-marconiclient and get support for the entire v1.0 API. Although the package will remain classified as “beta” while we polish off any rough edges, please take it for a spin and let us know what you think. Kudos goes to Flavio Per

[openstack-dev] [marconi] ATL Summit Pads - Please Review

you are interested) * Tues 17:30 - Scaling an Individual Queue<https://etherpad.openstack.org/p/juno-marconi-scale-single-queue> — Kurt Griffiths Also, I’ve set up some pads for the unconference sessions (@ the Marconi table) I know about: * Signed messages<https://etherpad.o

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

> It appears the current version of oslo.cache is going to bring in quite >a few oslo libraries that we would not want keystone client to depend on >[1]. Moving the middleware to a separate library would solve that. I think it makes a lot of sense to separate out the middleware. Would this be a ne

[openstack-dev] Marconi PTL Candidacy

e team, continue on-boarding new contributors and interns, and see several more large deployments of Marconi in production. --- Kurt Griffiths | @kgriffs ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

Hi folks, has there been any discussion on using oslo.cache within the auth_token middleware to allow for using other cache backends besides memcached? I didn’t find a Keystone blueprint for it, and was considering registering one for Juno if the team thinks this feature makes sense. I’d be hap

Re: [openstack-dev] [marconi] sample config files should be ignored in git...

Ah, that is good to know. Is this documented somewhere? On 3/26/14, 11:48 PM, "Sergey Lukjanov" wrote: >FWIW It's working on OS X, but gnu-getopt should be installed. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openst

Re: [openstack-dev] [marconi] sample config files should be ignored in git...

P.S. - Any particular reason this script wasn’t written in Python? Seems like that would avoid a lot of cross-platform gotchyas. On 3/26/14, 11:48 PM, "Sergey Lukjanov" wrote: >FWIW It's working on OS X, but gnu-getopt should be installed. ___ OpenSta

[openstack-dev] [Marconi] Backend options [was Re: Why is marconi a queue implementation vs a provisioning API?]

Matt Asay wrote: > We want people using the world's most popular NoSQL database with the >world's most popular open source cloud (OpenStack). I think our track >record on this is 100% in the affirmative. So, I think it is pretty clear that there are lots of people who would like to use MongoDB and

[openstack-dev] [marconi] sample config files should be ignored in git...

Team, what do you think about doing this for Marconi? It looks like we indeed have a sample checked in: https://review.openstack.org/#/c/83006/1/etc/marconi.conf.sample Personally, I think we should keep the sample until generate_sample.sh works on OS X (we could even volunteer to fix it); other

Re: [openstack-dev] [Swift] Swift storage policies in Icehouse

> As a quick review, storage policies allow objects to be stored across a >particular subset of hardware...and with a particular storage algorithm Having worked on backup software in the past, this sounds interesting. :D What is the scope of these policies? Are they per-object, per-container, and

Re: [openstack-dev] [Marconi] Proposal to add Malini Kamalambal to the marconi-core team

+1 million. I’ve been super impressed by Malini’s work and thoughtful comments on multiple occasions. On 3/21/14, 10:35 AM, "Amit Gandhi" wrote: >+1 > >On 3/21/14, 11:17 AM, "Flavio Percoco" wrote: > >>Greetings, >> >>I'd like to propose adding Malini Kamalambal to Marconi's core. Malini >>has

Re: [openstack-dev] [Marconi][TC] Withdraw graduation request

> I'd also like to thank the team and the overall community. The team > for its hard work during the last cycle and the community for being there > and providing such important feedback in this process. +1, thanks again everyone for participating in the discussions and driving towards a constructi

Re: [openstack-dev] [legal-discuss] [Marconi] Why is marconi a queue implementation vs a provisioning API?

> The incorporation of AGPLv3 code Into OpenStack Project is a >significant decision To be clear, Marconi does not incorporate any AGPL code itself; pymongo is Apache2 licensed. Concerns over AGPL were raised when Marconi was incubated, and I totally respect that some folks are not comfortable w

Re: [openstack-dev] Pecan Evaluation for Marconi

> Only one project is using swob, and it is unlikely that will change. That begs the question, *why* is that unlikely to change? Is it because there are fundamental needs that are not met by Pecan? If I understand the original charter for Oslo, it was to consolidate code already in use by projects

Re: [openstack-dev] Pecan Evaluation for Marconi

Thierry Carrez wrote: > There was historically a lot of deviation, but as we add more projects >that deviation is becoming more costly. I totally understand the benefits of reducing the variance between projects, and to be sure, I am not suggesting we have 10 different libraries to do X. However

Re: [openstack-dev] Pecan Evaluation for Marconi

After reviewing the report below, I would recommend that Marconi continue using Falcon for the v1.1 API and then re-evaluate Pecan for v2.0 or possibly look at using swob. I wanted to post my recommendation to the general list, because my request to continue using Falcon speaks to a broader iss

Re: [openstack-dev] [Marconi] Why is marconi a queue implementation vs a provisioning API?

I think we can agree that a data-plane API only makes sense if it is useful to a large number of web and mobile developers deploying their apps on OpenStack. Also, it only makes sense if it is cost-effective and scalable for operators who wish to deploy such a service. Marconi was born of practica

Re: [openstack-dev] [Marconi] Pecan Evaluation for Marconi

Kudos to Balaji for working so hard on this. I really appreciate his candid feedback on both frameworks. After reviewing his report, I would recommend that Marconi continue using Falcon for the v1.1 API and then re-evaluate Pecan for v2.0. Pecan will continue to improve over time. We should als

Re: [openstack-dev] [Solum] Proposed Core Reviewer Changes

+1 On 3/18/14, 12:13 AM, "Adrian Otto" wrote: >Solum Cores, > >I propose the following changes to the Solum core reviewer team: > >+gokrokve >+julienvey >+devdatta-kulkarni >-kgriffs (inactivity) >-russelb (inactivity) > >Please reply with your +1 votes to proceed with this change, or any >remar

[openstack-dev] Constructive Conversations

Folks, I’m sure that I’m not the first person to bring this up, but I’d like to get everyone’s thoughts on what concrete actions we, as a community, can take to improve the status quo. There have been a variety of instances where community members have expressed their ideas and concerns via em

Re: [openstack-dev] Proposal to move from Freenode to OFTC

> The fact is though that Freenode has had significant service degradation >due to DDoS attacks for quite some time Rather than jumping ship, is there anything we as a community can do to help Freenode? This would obviously require a commitment of time/money, but it could be worth it for something

[openstack-dev] [marconi] graduation review meeting

Team, we will be discussing Marconi graduation from incubation in a couple weeks at the TC meeting, March 18th at 20:00 UTC. It would be great to have as many people there as possible to help answer questions, etc. T

Re: [openstack-dev] [marconi] Proposal to add Fei Long Wang (flwang) as a core reviewer

The poll has closed. flwang has been promoted to Marconi core. @kgriffs ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [marconi] integration with logstash

Here’s an interesting hack. People are getting creative in the way they use Marconi (this patch uses Rackspace’s deployment of Marconi). https://github.com/paulczar/logstash-contrib/commit/8bfe93caf1c66d94690e9d9c2ecf9ee6b458b1d9 @kgriffs ___ OpenStack

[openstack-dev] [marconi] Proposal to add Fei Long Wang (flwang) as a core reviewer

Hi folks, I’d like to propose adding Fei Long Wang (flwang) as a core reviewer on the Marconi team. He has been contributing regularly over the past couple of months, and has proven to be a careful reviewer with good judgment. All Marconi ATC’s, please respond with a +1 or –1. Cheers, Kurt G. |

Re: [openstack-dev] [Solum] Proposed changes to solum-core

+1 On 1/27/14, 11:54 AM, "Monty Taylor" wrote: >On 01/24/2014 05:32 PM, Adrian Otto wrote: >> Solum Core Reviewers, >> >> I propose the following changes to solum-core: >> >> +asalkeld >> +noorul >> -mordred >> >> Thanks very much to mordred for helping me to bootstrap the reviewer >>team. Pleas

Re: [openstack-dev] [wsme] Undefined attributes in WSME

FWIW, I believe Nova is looking at using JSON Schema as well, since they need to handle API extensions. This came up during a design session at the HK summit. On 1/12/14, 5:33 PM, "Jamie Lennox" wrote: >I would prefer not to have keystone using yet another framework from the >rest of openstack

[openstack-dev] [marconi] Ichouse roadmap and Graduation tracking

Hi folks, I put together a tracking blueprint for us to refer to in our team meetings: https://blueprints.launchpad.net/marconi/+spec/graduation Also, here is an outline of what I want to a accomplish for Icehouse: https://wiki.openstack.org/wiki/Marconi/roadmaps/icehouse Feedback is w

Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy

ller call. Here is an example how we added a hook for keystone information collection: https://review.openstack.org/#/c/64458/4/solum/api/auth.py What do you think, will this approach with Pecan hooks work? Thanks Georgy On Tue, Jan 7, 2014 at 2:25 PM, Kurt Griffiths mailto:kurt.griffi...@rac

Re: [openstack-dev] [Solum][Pecan][Security] Pecan SecureController vs. Nova policy

You might also consider doing this in WSGI middleware: Pros: * Consolidates policy code in once place, making it easier to audit and maintain * Simple to turn policy on/off – just don’t insert the middleware when off! * Does not preclude the use of oslo.policy for rule checking *

[openstack-dev] [marconi] Meeting agenda for tomorrow at 1500 UTC

The Marconi project team holds a weekly meeting in #openstack-meeting-alt on Tuesdays, 1500 UTC. The next meeting is Tomorrow, Dec. 10. Everyone is welcome, but please take a minute to review the wiki before attending for

Re: [openstack-dev] Unified Guest Agent proposal

FWIW, Marconi can easily deliver sub-second latency even with lots of clients fast-polling. We are also considering a long-polling feature that will reduce latency further for HTTP clients. On 12/13/13, 2:41 PM, "Fox, Kevin M" wrote: >A second or two of latency perhaps shaved off by using someth

Re: [openstack-dev] How to best make User Experience a priority in every project

I love the idea of treating usability as a first-class citizen; to do that, we definitely need a core set of people who are passionate about the topic in order to keep it alive in the OpenStack gestalt. Contributors tend to prioritize work on new, concrete features over “non-functional” requirem

Re: [openstack-dev] Unified Guest Agent proposal

This list of features makes me very nervous from a security standpoint. Are we talking about giving an agent an arbitrary shell command or file to install, and it goes and does that, or are we simply triggering a preconfigured action (at the time the agent itself was installed)? From: Steven Da

[openstack-dev] [marconi] Team meeting agenda for tomorrow @ 1500 UTC

The Marconi project team holds a weekly meeting in #openstack-meeting-alt on Tuesdays, 1500 UTC. The next meeting is Tomorrow, Dec. 10. Everyone is welcome, but please take a minute to review the wiki before attending for t

Re: [openstack-dev] [ceilometer] [marconi] Notifications brainstorming session tomorrow @ 1500 UTC

cessarily design notifications for the latter cases, because it introduces potentially quite a lot of user-demanded load on the Openstack components, I'm just asking for a statement of intent. -- Ian. On 4 December 2013 16:09, Kurt Griffiths mailto:kurt.griffi...@rackspace.com>> wro

Re: [openstack-dev] [marconi] New meeting time

Sorry to change things up again, but it’s been requested that we move our meeting to Tuesday at 1500 UTC instead of Monday, since a lot of people’s Mondays are crazy busy as it is. Unless anyone objects, let’s plan on doing that starting with our next meeting (Dec 10). On 11/25/13, 6:22 PM, "

Re: [openstack-dev] [ceilometer] [marconi] Notifications brainstorming session tomorrow @ 1500 UTC

Thanks! We touched on this briefly during the chat yesterday, and I will make sure it gets further attention. On 12/3/13, 3:54 AM, "Julien Danjou" wrote: >On Mon, Dec 02 2013, Kurt Griffiths wrote: > >> Following up on some conversations we had at the summit, I¹d like to

[openstack-dev] [ceilometer] [marconi] Notifications brainstorming session tomorrow @ 1500 UTC

Folks, Want to surface events to end users? Following up on some conversations we had at the summit, I’d like to get folks together on IRC tomorrow to crystalize the design for a notifications project under the Marconi program. The project’s goal is to create a service for surfacing events to

Re: [openstack-dev] [marconi] New meeting time

OK, I¹ve changed the time. Starting next Monday (2 Dec.) we will be meeting at 1500 UTC in #openstack-meeting-alt. See also: https://wiki.openstack.org/wiki/Meetings/Marconi On 11/25/13, 11:33 AM, "Flavio Percoco" wrote: >On 25/11/13 17:05 +, Amit Gandhi wrote: >>Works for me. > >Works for

[openstack-dev] [marconi] New meeting time

@kgriffs Kurt Griffiths ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [marconi] Websocket transport

Hi folks, We have been discussing doing at least a basic/poc TCP transport as a way to keep ourselves honest wrt the API abstraction work that was recently started. I would like to propose using websockets for this work, for a few reasons: 1. It saves us

Re: [openstack-dev] [RFC] Straw man to start the incubation / graduation requirements discussion

> Also does it place a requirement that all projects wanting to request >incubation to be placed in stackforge ? That sounds like a harsh >requirement if we were to reject them. I think that anything that encourages projects to get used to the OpenStack development process sooner, rather than late

[openstack-dev] [marconi] No team meeting on Monday

No meeting on Monday due to the summit. Cheers, --- @kgriffs Kurt Griffiths ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [marconi] Agenda for Monday's meeting

The Marconi project team holds a weekly meeting in #openstack-meeting- alt on Mondays, 1600 UTC. http://goo.gl/Li9V4o The next meeting is Monday, Oct 28. Everyone is welcome, but please take a minute to review the wiki before attending for the first time: http://wiki.openstack.org/marconi P

[openstack-dev] [marconi] Sharding feature design

design finalized. See also: https://blueprints.launchpad.net/marconi/+spec/storage-sharding Thanks! --- @kgriffs Kurt Griffiths ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo

[openstack-dev] [marconi] Minutes from today's meeting

d have the nice side-effect of opening up Marconi to vendors for customization. Summary: http://goo.gl/2jxevN Log: http://goo.gl/QQYrPx Please join the conversation in #openstack-marconi, and help define the future of the OpenStack Queue Service. --- @kgriffs Kurt

[openstack-dev] [marconi] Agenda for next team meeting on Monday at 1600 UTC

The Marconi project team holds a weekly meeting in #openstack-meeting- alt on Mondays, 1600 UTC. The next meeting is Monday, Oct 21. Everyone is welcome, but please take a minute to review the wiki before attending for the first time: http://wiki.openstack.org/marconi Proposed Agenda: * Rev

[openstack-dev] [marconi] API finalized, graduation progress, and other notes from today's team meeting

Hi folks, Today we finalized the v1 API, and voted to freeze it. This day has been a LONG time coming, and I want to personally thank the many people who have provided feedback and suggestions over the past 10 months on the many drafts the API has gone through. I understand that several client

[openstack-dev] [marconi] API Finalization starting in 10 minutes

Hi folks, Sorry for the late notice. During today's regular team meeting we will be reviewing and freezing the v1 API. I hope to see you there! 1600 UTC @ #openstack-meeting-alt Cheers, Kurt G. (kgriffs) ___ OpenStack-dev mailing list OpenStack-dev@li

  1   2   >