Re: [openstack-dev] [User-committee] Boston Forum - Formal Submission Now Open!

2017-03-22 Thread Eoghan Glynn
Thanks for putting this together! But one feature gap is some means to tag topic submissions, e.g. tagging the project-specific topics by individual project relevance. That could be a basis for grouping topics, to allow folks to better manage their time during the Forum. (e.g. if someone was

Re: [openstack-dev] [nova] [placement] experimenting with extracting placement

2017-03-13 Thread Eoghan Glynn
> > We are close to the first milestone in Pike, right ? We also have > > priorities for Placement that we discussed at the PTG and we never > > discussed about how to cut placement during the PTG. > > > > Also, we haven't discussed yet with operators about how they would like > > to see Placement

Re: [openstack-dev] [nova] Order of n-api (placement) and n-sch upgrades for Ocata

2017-01-20 Thread Eoghan Glynn
> >> What are these issues? My original message was to highlight one > >> particular deployment type which is completely independent of > >> how things get packaged in the traditional sense of the word > >> (rpms/deb/tar.gz). Perhaps it's getting lost in terminology, > >> but packaging the

Re: [openstack-dev] [nova] Order of n-api (placement) and n-sch upgrades for Ocata

2017-01-19 Thread Eoghan Glynn
> >> Sylvain and I were talking about how he's going to work placement > >> microversion requests into his filter scheduler patch [1]. He needs to > >> make > >> requests to the placement API with microversion 1.4 [2] or later for > >> resource provider filtering on specific resource classes like

Re: [openstack-dev] [tripleo] PTG space request

2016-10-14 Thread Eoghan Glynn
- Original Message - > > > > > >>> I would like to request for some space dedicated to TripleO project > > > > >>> for the first OpenStack PTG. > > > > >>> > > > > >>> https://www.openstack.org/ptg/ > > > > >>> > > > > >>> The event will happen in February 2017 during the next PTG in >

Re: [openstack-dev] [tripleo] PTG space request

2016-10-14 Thread Eoghan Glynn
> > > >>> I would like to request for some space dedicated to TripleO project > > > >>> for the first OpenStack PTG. > > > >>> > > > >>> https://www.openstack.org/ptg/ > > > >>> > > > >>> The event will happen in February 2017 during the next PTG in > > > >>> Atlanta. > > > >>> Any feedback is

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

2016-10-14 Thread Eoghan Glynn
> > > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +: > > >> It can be cheap if you are in the US. However, for Asia folks, it is not > > >> that cheap considering it is all overseas travel. In addition, > > >> all-in-one > > >> event like the current summit makes us much easier

Re: [openstack-dev] [tripleo] PTG space request

2016-10-13 Thread Eoghan Glynn
> >>> I would like to request for some space dedicated to TripleO project > >>> for the first OpenStack PTG. > >>> > >>> https://www.openstack.org/ptg/ > >>> > >>> The event will happen in February 2017 during the next PTG in Atlanta. > >>> Any feedback is welcome, > >> > >> Just a quick note:

Re: [openstack-dev] [tripleo] PTG space request

2016-10-12 Thread Eoghan Glynn
> Emilien Macchi wrote: > > I would like to request for some space dedicated to TripleO project > > for the first OpenStack PTG. > > > > https://www.openstack.org/ptg/ > > > > The event will happen in February 2017 during the next PTG in Atlanta. > > Any feedback is welcome, > > Just a quick

Re: [openstack-dev] [Openstack] Naming polls - and some issues

2016-07-15 Thread Eoghan Glynn
; what you mean when you are going to the Quay. > > > > > > On 14 July 2016 at 21:35, Neil Jerram <n...@tigera.io > > <mailto:n...@tigera.io>> wrote: > > > > Not sure what the problem would be with 'Quay' or 'Street' - they >

Re: [openstack-dev] [Openstack] Naming polls - and some issues

2016-07-14 Thread Eoghan Glynn
> >> Hey all! > >> > >> The poll emails for the P and Q naming have started to go out - and > >> we're experiencing some difficulties. Not sure at the moment what's > >> going on ... but we'll keep working on the issues and get ballots to > >> everyone as soon as we can. > > > > You'll need to

Re: [openstack-dev] [all][elections] Results of the TC Election

2016-04-08 Thread Eoghan Glynn
> > Increase the commit requirements, but don't remove the summit pass > > perk. You'll add a barrier for ATCs and see fewer of them at > > summits. > > The commit counts for the latest TC electorate show 27% had only one > merged change in Gerrit during the qualifying one year period. It's >

Re: [openstack-dev] [all][elections] Results of the TC Election

2016-04-08 Thread Eoghan Glynn
> >> However, the turnout continues to slide, dipping below 20% for > >> the first time: > > > >Election | Electorate (delta %) | Votes | Turnout (delta %) > >=== > >Oct '13 | 1106 | 342 | 30.92 > >Apr '14

Re: [openstack-dev] [all][elections] Results of the TC Election

2016-04-08 Thread Eoghan Glynn
> > > > Please join me in congratulating the 7 newly elected members of the TC. > > > > > > > > << REMOVE UNEEDED > > > > > * Davanum Srinivas (dims) > > > > * Flavio Percoco (flaper87) > > > > * John Garbutt (johnthetubaguy) > > > > * Matthew Treinish (mtreinish) > > > > * Mike Perez

Re: [openstack-dev] [all][elections] Results of the TC Election

2016-04-08 Thread Eoghan Glynn
> > Please join me in congratulating the 7 newly elected members of the TC. > > > > << REMOVE UNEEDED > > > * Davanum Srinivas (dims) > > * Flavio Percoco (flaper87) > > * John Garbutt (johnthetubaguy) > > * Matthew Treinish (mtreinish) > > * Mike Perez (thingee) > > * Morgan Fainberg

Re: [openstack-dev] [all][elections] Results of the TC Election

2016-04-08 Thread Eoghan Glynn
> Please join me in congratulating the 7 newly elected members of the TC. > > << REMOVE UNEEDED > > * Davanum Srinivas (dims) > * Flavio Percoco (flaper87) > * John Garbutt (johnthetubaguy) > * Matthew Treinish (mtreinish) > * Mike Perez (thingee) > * Morgan Fainberg

Re: [openstack-dev] [tc] Non-candidacy

2016-03-27 Thread Eoghan Glynn
> Hi all, > > Thanks for all the fish. But it's time for me to move over and let some > new voices contribute to the OpenStack Technical Committee. > > I will continue to be a proponent for the viewpoint that OpenStack > should be considered a toolkit of small, focused services and utilities,

Re: [openstack-dev] [all] A proposal to separate the design summit

2016-03-01 Thread Eoghan Glynn
> > Current thinking would be to give preferential rates to access the main > > summit to people who are present to other events (like this new > > separated contributors-oriented event, or Ops midcycle(s)). That would > > allow for a wider definition of "active community member"

Re: [openstack-dev] [all] A proposal to separate the design summit

2016-02-29 Thread Eoghan Glynn
> >>> Current thinking would be to give preferential rates to access the main > >>> summit to people who are present to other events (like this new > >>> separated contributors-oriented event, or Ops midcycle(s)). That would > >>> allow for a wider definition of "active community member" and

Re: [openstack-dev] [all] A proposal to separate the design summit

2016-02-29 Thread Eoghan Glynn
> > Current thinking would be to give preferential rates to access the main > > summit to people who are present to other events (like this new > > separated contributors-oriented event, or Ops midcycle(s)). That would > > allow for a wider definition of "active community member" and reduce > >

Re: [openstack-dev] [all] A proposal to separate the design summit

2016-02-22 Thread Eoghan Glynn
> Hi everyone, > > TL;DR: Let's split the events, starting after Barcelona. > > Long long version: > > In a global and virtual community, high-bandwidth face-to-face time is > essential. This is why we made the OpenStack Design Summits an integral > part of our processes from day 0. Those

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

2016-02-15 Thread Eoghan Glynn
> > Honestly I don't know of any communication between two cores at a +2 > > party that couldn't have just as easily happened surrounded by other > > contributors. Nor, I hope, does anyone put in the substantial > > reviewing effort required to become a core in order to score a few > > free

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

2016-02-12 Thread Eoghan Glynn
> > [...] > > * much of the problem with the lavish parties is IMO related to the > > *exclusivity* of certain shindigs, as opposed to devs socializing at > > summit being inappropriate per se. In that vein, I think the cores > > party sends the wrong message and has run its

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

2016-02-12 Thread Eoghan Glynn
> Hello all, > > tl;dr > = > > I have long thought that the OpenStack Summits have become too > commercial and provide little value to the software engineers > contributing to OpenStack. > > I propose the following: > > 1) Separate the design summits from the conferences > 2) Hold only a

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

2016-02-12 Thread Eoghan Glynn
> > For the cores party, much as I enjoyed the First Nation cuisine in > > Vancouver > > or the performance art in Tokyo, IMO it's probably time to draw a line > > under > > that excess also, as it too projects a notion of exclusivity that runs > > counter > > to building a community. > > ...

Re: [openstack-dev] [all][tc] Proposal: Separate design summits from OpenStack conferences

2016-02-12 Thread Eoghan Glynn
> > > > [...] > > > > * much of the problem with the lavish parties is IMO related to > > > > the > > > > *exclusivity* of certain shindigs, as opposed to devs > > > > socializing at > > > > summit being inappropriate per se. In that vein, I think the > > > > cores > > > > party

Re: [openstack-dev] [Ceilometer] Meter-list with multiple filters in simple query is not working

2015-10-12 Thread Eoghan Glynn
> Hi > > Can anyone plz help me on how to specify a simple query with multiple values > for a query field in a Ceilometer meter-list request? I need to fetch meters > that belongs to more than one project id. I have tried the following query > format, but only the last query value (in this

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

2015-07-01 Thread Eoghan Glynn
I think removing options from the API requires version bump. So if we plan to do this, that should be introduced in v3 as opposed to v2, which should remain the same and maintained for two cycles (assuming that we still have this policy in OpenStack). It this is achievable by

Re: [openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze

2015-04-02 Thread Eoghan Glynn
Hi all, we have a problem with dependencies for the kilo-rc1 release of Heat - see bug [1]. Root cause is ceilometerclient was not updated for a long time and just got an update recently. We are sure that Heat in Kilo would not work with ceilometerclient =1.0.12 (users would not be able

Re: [openstack-dev] [Heat] [Ceilometer] [depfreeze] bug is unresolved due to requirements freeze

2015-04-02 Thread Eoghan Glynn
Pavlo Shchelokovskyy wrote: unfortunately, in Heat we do not have yet integration tests for all the Heat resources (creating them in real OpenStack), and Ceilometer alarms are in those not covered. In unit tests the real client is of course mocked out. When we stumbled on this issue

[openstack-dev] [ceilometer] Stepping down as PTL

2015-04-02 Thread Eoghan Glynn
Hi Folks, Just a quick note to say that I won't be running again for ceilometer PTL over the liberty cycle. I've taken on a new role internally that won't realistically allow me the time that the PTL role deserves. But y'all haven't seen the last of me, I'll be sticking around as a contributor,

Re: [openstack-dev] [ceilometer] upgrades from juno to kilo

2015-03-31 Thread Eoghan Glynn
I tracked down the cause of the check-grenade-dsvm failure on https://review.openstack.org/#/c/167370 . As I understand it, grenade is taking the previous stable release, deploying it, then upgrading to the current master (plus the proposed changeset) without changing any of the config from

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

2015-01-12 Thread Eoghan Glynn
After some discussion with Sean Dague and a few others it became clear that it would be a good idea to introduce a new tool I've been working on to the list to get a sense of its usefulness generally, work towards getting it into global requirements, and get the documentation fleshed out so

Re: [openstack-dev] Where should Schema files live?

2014-12-08 Thread Eoghan Glynn
From: Sandy Walsh [sandy.wa...@rackspace.com] Monday, December 01, 2014 9:29 AM From: Duncan Thomas [duncan.tho...@gmail.com] Sent: Sunday, November 30, 2014 5:40 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Where should Schema files live? Duncan Thomas On

Re: [openstack-dev] [api] Counting resources

2014-12-01 Thread Eoghan Glynn
Toews everett.to...@rackspace.com wrote: On Nov 20, 2014, at 4:06 PM, Eoghan Glynn egl...@redhat.com wrote: How about allowing the caller to specify what level of detail they require via the Accept header? ▶ GET /prefix/resource_name Accept: application/json; detail

Re: [openstack-dev] Where should Schema files live?

2014-11-25 Thread Eoghan Glynn
I think Doug's suggestion of keeping the schema files in-tree and pushing them to a well-known tarball maker in a build step is best so far. It's still a little clunky, but not as clunky as having to sync two repos. Yes, I tend to agree. So just to confirm that my understanding lines up:

Re: [openstack-dev] [all] A true cross-project weekly meeting

2014-11-21 Thread Eoghan Glynn
Right, agreed. This has always been an open meeting. Yes of course, as I said up-thread. This is a central plank of our 4 Opens principle[1], which should apply across the board to all community meetings related to the OpenStack project. All project meetings are held in public IRC channels

Re: [openstack-dev] Where should Schema files live?

2014-11-21 Thread Eoghan Glynn
Why wouldn’t they live in the repo of the application that generates the notification, like we do with the database schema and APIs defined by those apps? That would mean downstream consumers (potentially in different languages) would need to pull all repos and extract just the

Re: [openstack-dev] Where should Schema files live?

2014-11-21 Thread Eoghan Glynn
Some problems / options: a. Unlike Python, there is no simple pip install for text files. No version control per se. Basically whatever we pull from the repo. The problem with a git clone is we need to tweak config files to point to a directory and that's a pain for gating tests and

Re: [openstack-dev] [all] A true cross-project weekly meeting

2014-11-20 Thread Eoghan Glynn
Hi everyone, TL;DR: I propose we turn the weekly project/release meeting timeslot (Tuesdays at 21:00 UTC) into a weekly cross-project meeting, to discuss cross-project topics with all the project leadership, rather than keep it release-specific. Long version: Since the dawn of

Re: [openstack-dev] Where should Schema files live?

2014-11-20 Thread Eoghan Glynn
Thanks for raising this Sandy, Some questions/observations inline. Hey y'all, To avoid cross-posting, please inform your -infra / -operations buddies about this post. We've just started thinking about where notification schema files should live and how they should be deployed. Kind

Re: [openstack-dev] [api] Counting resources

2014-11-20 Thread Eoghan Glynn
Aloha guardians of the API! I haven recently* reviewed a spec for neutron [1] proposing a distinct URI for returning resource count on list operations. This proposal is for selected neutron resources, but I believe the topic is general enough to require a guideline for the API working

Re: [openstack-dev] TC election by the numbers

2014-11-15 Thread Eoghan Glynn
1. *make a minor concession to proportionality* - while keeping the focus on consensus, e.g. by adopting the proportional Condorcet variant. It would be interesting to see the analysis again, but in the past this proved to not make much difference. For the record, I

Re: [openstack-dev] TC election by the numbers

2014-11-15 Thread Eoghan Glynn
It's certainly not a fun thing to do (trying to guide a community of disjoint folks) and it likely comes with little recognition when successful, but IMHO we surely need more of this active technical leadership vs. blessing of projects; of course the boundary between being a engaging

Re: [openstack-dev] TC election by the numbers

2014-11-11 Thread Eoghan Glynn
I think you missed the most important option I mentioned in the thread - for the TC to engage more with the community and take an active technical leadership role in the design of OpenStack as a whole. +1 I've been in this scene for about half a year now and the only reason I

Re: [openstack-dev] TC election by the numbers

2014-11-10 Thread Eoghan Glynn
So, just to round out this thread, the key questions are: * whether a low declining turnout is a real problem and, if so: * could this have been driven by a weakness in the voting model, and/or the perception of representative balance in the outcomes The options that

Re: [openstack-dev] TC election by the numbers

2014-11-01 Thread Eoghan Glynn
+1 to this, with a term limit. Notable that the Debian TC has been discussing term limits for months now, and since DebConf they seem to have gotten much closer to a concrete proposal[1] in the last week or so. Could be worth watching for ideas on how our community might attempt to

Re: [openstack-dev] TC election by the numbers

2014-11-01 Thread Eoghan Glynn
So, just to round out this thread, the key questions are: * whether a low declining turnout is a real problem I'd like to point out that there 580 'regular' contributors at the moment[1], these are the authors of 95% of the OpenStack code. 506 total number of voters. Thanks Stef,

Re: [openstack-dev] TC election by the numbers

2014-10-30 Thread Eoghan Glynn
IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two

Re: [openstack-dev] TC election by the numbers

2014-10-30 Thread Eoghan Glynn
IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two

Re: [openstack-dev] TC election by the numbers

2014-10-30 Thread Eoghan Glynn
IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two

Re: [openstack-dev] TC election by the numbers

2014-10-30 Thread Eoghan Glynn
IIRC, there is no method for removing foundation members. So there are likely a number of people listed who have moved on to other activities and are no longer involved with OpenStack. I'd actually be quite interested to see the turnout numbers with voters who missed the last two

Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions

2014-10-30 Thread Eoghan Glynn
Hi everyone, Before we start the larger discussion at summit next week about the future of testing in OpenStack - specifically about spinning up functional testing and how it relates to tempest - I would like to share some of my thoughts on how we can get things started and how I think

Re: [openstack-dev] TC election by the numbers

2014-10-30 Thread Eoghan Glynn
If we're serious about improving participation rates, then I think we should consider factors what would tend to drive interest levels and excitement around election time. My own suspicion is that open races where the outcome is in doubt are more likely to garner attention from voters,

Re: [openstack-dev] [QA][All] Prelude to functional testing summit discussions

2014-10-30 Thread Eoghan Glynn
Matthew wrote: This would have the advantage of making tempest slimmer for every project and begin the process of getting projects to take responsibility for their functional testing rather than relying on tempest. [much snipping] Sean wrote: Ok, so part of this remains to be seen about

Re: [openstack-dev] [openstack-tc] Topics for the Board/TC joint meeting in Paris

2014-10-30 Thread Eoghan Glynn
This is already on the agenda proposed by the board (as well as a quick presentation on the need for structural reform in the ways we handle projects in OpenStack). Would it be possible for the slidedeck and a quick summary of that presentation to be posted to the os-dev list after the

Re: [openstack-dev] TC election by the numbers

2014-10-30 Thread Eoghan Glynn
The low (and dropping) level of turnout is worrying, particularly in light of that analysis showing the proportion of drive-by contributors is relatively static, but it is always going to be hard to discern the motives of people who didn't vote from the single bit of data we have on them.

[openstack-dev] TC election by the numbers

2014-10-29 Thread Eoghan Glynn
voters (4.15%) preferred Russell Bryant Eoghan Glynn (RHAT/RHAT) 16 voters (3.16%) preferred Doug Hellmann Sean Dague(HP/HP) Conclusion == The rate of potentially partisan voting didn't diverge significantly from the norms we've seen in previous elections. The continuing decline

Re: [openstack-dev] TC election by the numbers

2014-10-29 Thread Eoghan Glynn
On Oct 29, 2014, at 3:32 PM, Eoghan Glynn egl...@redhat.com wrote: Folks, I haven't seen the customary number-crunching on the recent TC election, so I quickly ran the numbers myself. Voter Turnout = The turnout rate continues to decline, in this case

[openstack-dev] [ceilometer] scheduling Kilo summit topics

2014-10-16 Thread Eoghan Glynn
Folks, Just a quick reminder that we'll be considering the summit design sessions proposals[1] at the weekly meeting today at 1500UTC. We'll start the process of collaborative scheduling of topics with each session proposer giving a short pitch for inclusion. We've got 15 proposals already,

[openstack-dev] TC Candidacy

2014-10-08 Thread Eoghan Glynn
Folks, I would like to throw my hat into the ring for the upcoming Technical Committee election. I've been involved in the OpenStack community for nearly three years, starting off by becoming core on glance, before moving my focus mainly onto the ceilometer project. Along the way I've landed a

Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-06 Thread Eoghan Glynn
So a bit of background here. This began from thinking about functional dependencies, and pondering whether a map of the dependency graph of our projects could inform our gating structure, specifically to encourage (or dare I say, actually force) all of us (the project teams) to become

Re: [openstack-dev] [all][tc] governance changes for big tent model

2014-10-03 Thread Eoghan Glynn
As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and

Re: [openstack-dev] [all][tc] governance changes for big tent model

2014-10-03 Thread Eoghan Glynn
- Original Message - On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote:

Re: [openstack-dev] What's a dependency (was Re: [all][tc] governance changes for big tent...) model

2014-10-03 Thread Eoghan Glynn
So a bit of background here. This began from thinking about functional dependencies, and pondering whether a map of the dependency graph of our projects could inform our gating structure, specifically to encourage (or dare I say, actually force) all of us (the project teams) to become more

[openstack-dev] [Ceilometer] PTL Candidacy

2014-09-23 Thread Eoghan Glynn
Folks, I'd like to continue serving as Telemetry PTL for a second cycle. When I took on the role for Juno, I saw some challenges facing the project that would take multi-cycle efforts to resolve, so I'd like to have the opportunity to see that move closer to completion. Over Juno, our focus as

Re: [openstack-dev] [release] client release deadline - Sept 18th

2014-09-23 Thread Eoghan Glynn
The ceilometer team released python-ceilometerclient vesion 1.0.11 yesterday: https://pypi.python.org/pypi/python-ceilometerclient/1.0.11 Cheers, Eoghan Keystone team has released 0.11.1 of python-keystoneclient. Due to some delays getting things through the gate this took a few extra

Re: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core

2014-09-19 Thread Eoghan Glynn
Hi, Nejc has been doing a great work and has been very helpful during the Juno cycle and his help is very valuable. I'd like to propose that we add Nejc Saje to the ceilometer-core group. Please, dear ceilometer-core members, reply with your votes! With eight yeas and zero nays, I

Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

2014-09-19 Thread Eoghan Glynn
Hi, Dina has been doing a great work and has been very helpful during the Juno cycle and her help is very valuable. She's been doing a lot of reviews and has been very active in our community. I'd like to propose that we add Dina Belova to the ceilometer-core group, as I'm convinced

Re: [openstack-dev] [Zaqar] Zaqar and SQS Properties of Distributed Queues

2014-09-19 Thread Eoghan Glynn
Hi All, My understanding of Zaqar is that it's like SQS. SQS uses distributed queues, which have a few unusual properties [0]: Message Order Amazon SQS makes a best effort to preserve order in messages, but due to the distributed nature of the queue, we cannot guarantee you will

Re: [openstack-dev] [all][TC][Zaqar] Another graduation attempt, new lessons learned

2014-09-17 Thread Eoghan Glynn
Thanks for bring this to the list, Flavio. A few thoughts in line ... Greetings, As probably many of you already know, Zaqar (formerly known as Marconi) has recently been evaluated for integration. This is the second time this project (and team) has gone through this process and just like

Re: [openstack-dev] [all] Design Summit planning

2014-09-12 Thread Eoghan Glynn
I visited the Paris Design Summit space on Monday and confirmed that it should be possible to split it in a way that would allow to have per-program contributors meetups on the Friday. The schedule would go as follows: Tuesday: cross-project workshops Wednesday, Thursday: traditional

Re: [openstack-dev] [Ceilometer] Adding Nejc Saje to ceilometer-core

2014-09-11 Thread Eoghan Glynn
Hi, Nejc has been doing a great work and has been very helpful during the Juno cycle and his help is very valuable. I'd like to propose that we add Nejc Saje to the ceilometer-core group. Please, dear ceilometer-core members, reply with your votes! A hearty +1 for me, Nejc has made a

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-11 Thread Eoghan Glynn
As you all know, there has recently been several very active discussions around how to improve assorted aspects of our development process. One idea that was brought up is to come up with a list of cycle goals/project priorities for Kilo [0]. To that end, I would like to propose an

Re: [openstack-dev] [Ceilometer] Adding Dina Belova to ceilometer-core

2014-09-11 Thread Eoghan Glynn
Hi, Dina has been doing a great work and has been very helpful during the Juno cycle and her help is very valuable. She's been doing a lot of reviews and has been very active in our community. I'd like to propose that we add Dina Belova to the ceilometer-core group, as I'm convinced

Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation

2014-09-04 Thread Eoghan Glynn
The implementation in ceilometer is very different to the Ironic one - are you saying the test you linked fails with Ironic, or that it fails with the ceilometer code today? Disclaimer: in Ironic terms, node = conductor, key = host The test I linked fails with Ironic hash ring

Re: [openstack-dev] [all] Design Summit reloaded

2014-09-04 Thread Eoghan Glynn
Hi everyone, I've been thinking about what changes we can bring to the Design Summit format to make it more productive. I've heard the feedback from the mid-cycle meetups and would like to apply some of those ideas for Paris, within the constraints we have (already booked space and time).

Re: [openstack-dev] [all] Design Summit reloaded

2014-09-04 Thread Eoghan Glynn
Am I missing some compelling advantage of moving all these emergent project-specific meetups to the Friday? One is that due to space limitations, we won't have nearly as many pods as in Atlanta (more like half or a third of them). Without one pod per program, the model breaks a bit.

Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation

2014-09-03 Thread Eoghan Glynn
On 09/02/2014 11:33 PM, Robert Collins wrote: The implementation in ceilometer is very different to the Ironic one - are you saying the test you linked fails with Ironic, or that it fails with the ceilometer code today? Disclaimer: in Ironic terms, node = conductor, key = host The

Re: [openstack-dev] [ceilometer] indicating sample provenance

2014-08-21 Thread Eoghan Glynn
One of the outcomes from Juno will be horizontal scalability in the central agent and alarm evaluator via partitioning[1]. The compute agent will get the same capability if you choose to use it, but it doesn't make quite as much sense. I haven't investigated the alarm evaluator side

Re: [openstack-dev] [all] The future of the integrated release

2014-08-20 Thread Eoghan Glynn
Additional cross-project resources can be ponied up by the large contributor companies, and existing cross-project resources are not necessarily divertable on command. Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough.

Re: [openstack-dev] [all] The future of the integrated release

2014-08-15 Thread Eoghan Glynn
But, if someone asked me what they should use for metering today, I'd point them towards Monasca in a heartbeat. FWIW my view is that Monasca is an interesting emerging project, with a team accreting around it that seems to be interested in collaboration. We've had ongoing discussions with

Re: [openstack-dev] [all] The future of the integrated release

2014-08-14 Thread Eoghan Glynn
Letting the industry field-test a project and feed their experience back into the community is a slow process, but that is the best measure of a project's success. I seem to recall this being an implicit expectation a few years ago, but haven't seen it discussed in a while. I think

Re: [openstack-dev] [all] The future of the integrated release

2014-08-14 Thread Eoghan Glynn
Additional cross-project resources can be ponied up by the large contributor companies, and existing cross-project resources are not necessarily divertable on command. Sure additional cross-project resources can and need to be ponied up, but I am doubtful that will be enough. OK, so

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Eoghan Glynn
One thing I'm not seeing shine through in this discussion of slots is whether any notion of individual cores, or small subsets of the core team with aligned interests, can champion blueprints that they have a particular interest in. I think that's because we've focussed in this

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Eoghan Glynn
It seems like this is exactly what the slots give us, though. The core review team picks a number of slots indicating how much work they think they can actually do (less than the available number of blueprints), and then blueprints queue up to get a slot based on priorities and

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Eoghan Glynn
At the end of the day, that's probably going to mean saying No to more things. Everytime I turn around everyone wants the TC to say No to things, just not to their particular thing. :) Which is human nature. But I think if we don't start saying No to more things we're going to end up

Re: [openstack-dev] [all] The future of the integrated release

2014-08-13 Thread Eoghan Glynn
Divert all cross project efforts from the following projects so we can focus our cross project resources. Once we are in a bitter place we can expand our cross project resources to cover these again. This doesn't mean removing anything. * Sahara * Trove * Tripleo You write

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-12 Thread Eoghan Glynn
Doesn't InfluxDB do the same? InfluxDB stores timeseries data primarily. Gnocchi in intended to store strongly-typed OpenStack resource representations (instance, images, etc.) in addition to providing a means to access timeseries data associated with those resources. So to

Re: [openstack-dev] [all] The future of the integrated release

2014-08-12 Thread Eoghan Glynn
It seems like this is exactly what the slots give us, though. The core review team picks a number of slots indicating how much work they think they can actually do (less than the available number of blueprints), and then blueprints queue up to get a slot based on priorities and turnaround

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-11 Thread Eoghan Glynn
concrete progress on that score. I hope that provides enough detail to answer to your question? Cheers, Eoghan Thanks, Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From: Eoghan

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-11 Thread Eoghan Glynn
On 8/11/2014 4:22 PM, Eoghan Glynn wrote: Hi Eoghan, Thanks for the note below. However, one thing the overview below does not cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged. Many folks feel that this technology is a viable solution for the problem space

Re: [openstack-dev] [tc][ceilometer] Some background on the gnocchi project

2014-08-11 Thread Eoghan Glynn
On 8/11/2014 4:22 PM, Eoghan Glynn wrote: Hi Eoghan, Thanks for the note below. However, one thing the overview below does not cover is why InfluxDB ( http://influxdb.com/ ) is not being leveraged. Many folks feel that this technology is a viable solution for the problem space

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-11 Thread Eoghan Glynn
Ignoring the question of is it ok to say: 'to run ceilometer in any sort of non-trivial deployment you must manager yet another underlying service, mongodb' I would prefer not adding an addition gate variant to all projects. With the effort to reduce the number of gate variants we have [0] I

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-11 Thread Eoghan Glynn
So would we: (a) add a new integrated-gate-ceilometer project-template to [1], in the style of integrated-gate-neutron or integrated-gate-sahara, which would replicate the main integrated-gate template but with the addition of

Re: [openstack-dev] [all] The future of the integrated release

2014-08-09 Thread Eoghan Glynn
We seem to be unable to address some key issues in the software we produce, and part of it is due to strategic contributors (and core reviewers) being overwhelmed just trying to stay afloat of what's happening. For such projects, is it time for a pause ? Is it time to define key cycle

[openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
Hi Folks, Dina Belova has recently landed some infra patches[1,2] to create an experimental mongodb-based Tempest job. This effectively just overrides the ceilometer storage backend config so that mongodb is used instead of sql-alchemy. The new job has been running happily for a few days so I'd

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
Hi Folks, Dina Belova has recently landed some infra patches[1,2] to create an experimental mongodb-based Tempest job. This effectively just overrides the ceilometer storage backend config so that mongodb is used instead of sql-alchemy. The new job has been running happily for a

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
, Eoghan Glynn egl...@redhat.com wrote: Hi Folks, Dina Belova has recently landed some infra patches[1,2] to create an experimental mongodb-based Tempest job. This effectively just overrides the ceilometer storage backend config so that mongodb is used instead of sql-alchemy. The new job

Re: [openstack-dev] [qa][ceilometer] swapping the roles of mongodb and sqlalchemy for ceilometer in Tempest

2014-08-09 Thread Eoghan Glynn
+2 from me, More mongodb adoption (as stated) when it's questionable legally doesn't seem like a good long term strategy (I know it will/does impact yahoo adopting or using ceilometer...). Is this another one of those tactical changes that we keep on making that ends up being yet another

  1   2   >