20:01:49 #startmeeting 20:01:50 Meeting started Tue Jul 10 20:01:49 2012 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:51 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:57 o/ 20:01:59 o/ 20:02:02 o/ 20:02:02 o/ 20:02:05 o/ 20:02:05 sorry i'm late... 20:02:10 \o 20:02:11 o/ 20:02:13 here 20:02:29 great...that's 7 ppb members (anyone want to double check my count?) 20:02:33 http://wiki.openstack.org/Governance/PPB - agenda 20:02:42 hmmm 20:02:58 yes 7 20:02:59 o/ 20:03:01 o/ 20:03:02 8 20:03:06 #topic cinder core progress 20:03:07 .. 20:03:13 o/ 20:03:33 so we had agreed to fast track cinder provisionally for core in Folsom with a check at the f-2 milestone 20:04:07 the requirement was enough feature parity to replace nova-volumes as default 20:04:08 vishy is on the way 20:04:17 From a release management perspective, the project hit its deadlines and followed the procedured, even if jgriffith is obviously still learning the ropes 20:04:22 o/ 20:04:39 so no blocker from my release-management-hat side 20:04:50 jgriffith: could you give us a status update from your perspective? 20:04:52 jgriffith talks to me, so CI is not unhappy 20:05:12 jbryce: Yes, for the most part we're at feature parity 20:05:26 jbryce: Remaining issues are availability zones and quota implementation 20:05:41 jbryce: After that we have mostly the same bugs as Nova-V today :) 20:05:48 jgriffith: can those be done by F3? 20:05:57 jaypipes: Absolutely!! 20:06:06 k 20:06:09 jaypipes: We hit my goals for F2 20:06:14 excellent. 20:06:15 Remaining is slated F3 20:06:39 May not get to the "new" features I had hoped for but... 20:06:46 * jaypipes has noticed an increase in coordination with dtroyer around devstack and cinder, which is great to see 20:07:00 anyone have other questions for jgriffith? 20:07:10 dtroyer along with other folks have been very willing to help 20:07:28 jgriffith: I'd like to see some more involvement between cinder folks and tempest team 20:07:36 jgriffith: I'll email you about it. 20:07:39 jaypipes: You got it 20:08:09 looks like the project is tracking and being managed well. jgriffith, what are your concerns? 20:08:22 johnpur: time :) 20:08:39 lol, always 20:08:40 johnpur: Really it's getting better, more folks becoming interested 20:08:49 jgriffith: my final question is how have you been regarding coordination with annegentle and the docs team. that is an absolutely critical integration point IMHO considering the accelerated core promotion. 20:09:04 do we have POC installs that we trust? 20:09:05 jaypipes: +1 20:09:13 jaypipes: I've chatted with anne a number of times.... 20:09:27 jaypipes: I have a lot of work to do there but I'm keeping in communication with her 20:09:33 jaypipes: I have a plan for F3 20:09:36 good to hear! 20:10:10 remind me... if cinder is pushed to core is nova volume deprecated? what is the plan? 20:10:12 jgriffith: see johnpur's ? above... I agree would be cool to see some demo/POC envs for cinder 20:10:28 johnpur: There's some debate on if/when that happens 20:10:31 johnpur: no, shouldn't be. similar to Quantum, IIRC. 20:10:43 johnpur: deprecated over the following release series, right? 20:10:45 so nova volume is being maintained? 20:10:51 jaypipes: actually we are hoping that we remove nova-volumes 20:10:54 johnpur: correct 20:10:55 since the code was literally a cp -r 20:10:57 oh, ok... 20:11:05 johnpur: Maintained in terms of bug fixes yes 20:11:09 since otherwise we have to port between them 20:11:12 johnpur: crtical features as well 20:11:22 hopefully we can just take the bugs in nova for volumes and move them to cinder 20:11:25 and they are relevant 20:11:33 anotherjesse: well, if it *can* be a drop-in replacement, I suppose I could go along with that... if it truly is drop-inable by F3 20:11:43 * jaypipes adds drop-inable to Merriam Websters 20:11:45 anotherjesse: currently I'm fixing any bugs in "both" and will continue to do so as long as feasible 20:11:51 anotherjesse, you seem to be disagreeing with jgriffith? 20:12:04 johnpur: yes, doing double work for literally the same code base doesn't add value 20:12:05 I think we have to leave nova-volumes in for compatibility in Folsom, but mark it deprecated. 20:12:18 anotherjesse +1 if we can pull it off 20:12:19 vishy: +1 20:12:47 vishy: that makes sense to me 20:12:51 vishy: I actually thought that was the plan... am a bit surprised about the planned exorcism of nova-volume in Folsom. 20:13:07 jaypipes: There was some concern raised from lunar team to me 20:13:17 jaypipes: Being the new guy trying to keep people happy :( 20:13:19 jgriffith: could you elaborate? 20:13:25 but that means that there is a level of maintenance that has to continue, at least until the code is deprecated 20:13:53 I think we need to maintain both until the end of Folsom, and mark it deprecated there 20:13:55 * bcwaldon shows up late 20:14:11 so, what is the messaging? do we recommend anyone uses nova-volumes? 20:14:13 jaypipes: They're not likey to be ready to switch at F3, they are just asking to make sure we don't rip nova-v out 20:14:20 jaypipes: which we wouldn't 20:14:39 anotherjesse: no, we wuld recomment people use cinder fir volumes (and quantum for networking) in folsom 20:14:45 jaypipes: But that means IMO that there is still some bug maintenance that has to be done, at least up until F3 20:14:49 jgriffith: ok, I see. it seems you and anotherjesse need to discuss? 20:14:51 we cannot "force" everyone to move overnight 20:15:08 jgriffith: or is it just a matter of timing? 20:15:11 * ttx should fix his keyboard 20:15:31 jaypipes: I think it's timing more than anything. TBH I think it's handled and not going to be a major issue 20:15:42 I've had a number of talks with cthier about it 20:15:56 anotherjesse: I'm not proposing full on support of both either 20:16:05 jgriffith: k. so are we saying that n-vol will be deprecated through f3 and beyond, or removed? 20:16:14 jaypipes: deprecated 20:16:22 * creiht bows 20:16:23 :) 20:16:29 k. I *think* anotherjesse was saying removed though :) 20:16:33 jaypipes: I would propose removal in the H release 20:16:34 creiht: afternoon! 20:16:47 jgriffith: hmm... ok. not G? 20:16:59 let's hold on a minute 20:17:03 k 20:17:06 sounds like we're digging into a separate issue 20:17:10 yes 20:17:38 jbryce: vote on cinder core promotion? 20:17:41 first, does anyone have any objections to cinder being core in folsom? then we can decide if we need to make a call on it's relationship to nova-volumes or if that's just up to the nova team to decide 20:17:45 jaypipes: exactly 20:17:57 #startvote Has cinder met the folsom-2 milestone requirements and should be included in the Folsom core release? yes, no, abstain 20:17:58 Begin voting on: Has cinder met the folsom-2 milestone requirements and should be included in the Folsom core release? Valid vote options are yes, no, abstain. 20:17:59 Vote using '#vote OPTION'. Only your last vote counts. 20:18:07 #vote yes 20:18:09 #vote abstain 20:18:09 jaypipes: don't believe everything anotherjesse says. 20:18:16 #yes 20:18:18 #vote yes 20:18:20 #vote yes 20:18:21 #vote yes 20:18:21 #vote yes 20:18:22 #vote yes 20:18:23 #vote yes 20:18:23 #vote yes 20:18:24 #vote yes 20:18:30 #vote yes 20:18:31 quorum reached. 20:18:34 jaypipes: I dislike nova-volumes it in G, but that is a different topic 20:18:47 anotherjesse: do you want to revote just to make yours count? 20:18:53 no 20:18:54 #endvote 20:18:55 lol 20:18:56 Voted on "Has cinder met the folsom-2 milestone requirements and should be included in the Folsom core release?" Results are 20:18:57 yes (10): bcwaldon, johnpur, jbryce, vishy, heckj, jaypipes, jk0, ttx, danwent, pvo 20:18:58 abstain (1): notmyname 20:18:59 my irc is really delayed 20:19:11 * koolhead17 looks around 20:19:14 * mtaylor too 20:19:50 so it looks like that's settled... jbryce move on to ceilometer proposal? 20:19:58 so the second issue is what to do in relation to nova-volumes and the options seem to be rip out completely in F or deprecate in Folsom and remove in G (or H). is that correct? in 20:20:02 anotherjesse: you should move to a 1st-world country. 20:20:25 My vote is deprecated in Folsom 20:20:39 anotherjesse is suggesting that we should delete it 20:20:41 jbryce: I think we were just discussing the possibilities there... not sure the technical committee is needed to decide that? the PTL can/should be able to? 20:20:54 I think it would be a bad message to send (and contrary to our lately-established practices) to deprected and rip in the same release 20:21:03 ttx: ++ 20:21:04 Deprecate in Folsom, remove in G seems logical 20:21:05 deprecate* 20:21:08 jbryce: I don't like having the same code in two places… multiple places to fix bugs, we have to explain when to use one versus another 20:21:22 ttx: who is going to commit to maintaining the nova-volumes code? 20:21:22 ttx: but it isn't a rewrite or a remove, it is a MOVE 20:21:30 ttx: is that the cinder team? 20:21:39 * mtaylor agrees with anotherjesse 20:21:41 it is effectively a remove though 20:21:48 this is a reorg, not a rewrite 20:21:55 anotherjesse: then it's not a question of deprecating. 20:22:08 mtaylor: can the packaging issues be solved? 20:22:09 how much does it change the user experience though in terms accessing and using block storage? 20:22:20 jbryce: a huge amount 20:22:23 anotherjesse: we should be recommending/pushing folks to Cinder in Folsom... Deprecation implies that the Volumes code will be static and not updated. 20:22:23 jbryce: good question. 20:22:25 jbryce: we never had a release of a client or library that used the nova volumes extension 20:22:28 I disagree with that 20:22:29 jbryce: if they were using essex nova client it works exactly the same way 20:22:29 anotherjesse: would it be possible to list cinder as a dep of nova, and replace nova-volume with a proxy shim? 20:22:32 anotherjesse: it's a question of reorganizing, and we can do that in a single release alright. There is nothing being "deprecated" 20:22:44 jbryce: or they can switch to cinder client. 20:22:45 ttx: yes, because in essex we had a VOLUME endpoint 20:22:51 anotherjesse: python-novaclient uses nova columes 20:22:53 volumes 20:22:54 and nova-client used the VOLUME endpoint 20:22:55 vishy: I do not know what all of the packaging issues are 20:23:06 not the volume extension for COMPUTE 20:23:16 mtaylor: I don't like that idea 20:23:33 at one time it did use the volume extension 20:23:38 creiht: it actually doesn't, the essex (and current release) uses /volumes 20:23:38 before you guys just ripped it out 20:23:42 creiht: right, but it was never in a release 20:23:47 * creiht sighs 20:23:48 it was in the internal release ... 20:24:20 creiht: so the only change is switching the endpoint in keystone 20:24:34 I will just say that I think we set a very bad president if we make that drastic of change by removing nova-volume and only having cinder in the next release 20:24:49 vishy: but I'm happy to go bang on figuring them out if I someone has a list 20:24:51 from a client perspective that is correct vishy, but not from a provider perspective 20:25:03 vishy: and what abvout the migration story... will volumes regiastered using nova-volumes work with cinder (and the vbolume endpoint) out of the box? 20:25:10 creiht: if the code is the same on both sides, how is it a different story? 20:25:12 I'm about to release a whole set of infrastructure, and if you do this you will rip the carpet right out from under us 20:25:17 jaypipes: yes 20:25:21 jgriffith: k, thx 20:25:34 creiht: if there is an upgrade path for packaging, is it still an issue? 20:25:36 anotherjesse: it isn't exactly the same on both sides 20:26:01 creiht: elaborate? 20:26:05 the code 20:26:11 can't be exactly the same 20:26:18 specifically for attach 20:26:26 /detach 20:26:33 either way 20:26:53 you have a prescident of infrastructure for nova with nova-volumes that has already been a pain to track 20:27:08 and now you are saying you want to rip the whole rug out from under the table 20:27:15 creiht: so for your internal project, just don't delete it? 20:27:15 is this different than if those changes were made in nova-volumes inside of the nova codebase? 20:27:17 I don't think that is acceptable 20:27:29 creiht: rax has their own branches for this stuff right? 20:27:36 nope 20:27:40 creiht: since you're the advocate of keeping nova-volumes in, can you commit to helping keep it maintained 20:27:42 not for volume 20:27:45 we are tracking trunk 20:27:51 as close as we can 20:28:08 creiht: the main issue with leaving it in deprecated is it doubles maintenance for bug fixes 20:28:26 creiht: and nova-core has already demonstrated that they don't really care about keeping that up-to-date 20:28:30 creiht: so if I understand correctly, it's technically a move, but it affects you because you were expecting it not to chnage in Folsom release, is that right ? 20:28:44 vishy: I understand, we will help where we can, but I can't promise to take over all maint 20:28:47 creiht: is deprecating in f and removing in g going to be better for you? 20:28:56 or is it still the same problem just later 20:29:02 jbryce: I think that is very reasonable 20:29:09 jbryce: it allows them to switch over at there leisure 20:29:15 That gives providers time to adjust 20:29:15 what about leaving the code in there the deprecation means that we don't even release it.... 20:29:19 if people want to notice it is there 20:29:22 then they can use it? 20:29:46 anotherjesse: +1 20:30:00 anotherjesse: define don't even release it 20:30:08 creiht: we don't have packages of it 20:30:24 and don't recommend that redhat, ubuntu or other distros/companies ship it 20:30:26 I think we need to take this to the mailing list and see if we are causing anyone else pain 20:30:32 vishy: +1 20:30:35 I didn't think openstack provided any packages for anything 20:30:39 we don't 20:30:40 vishy: +1 20:30:49 i don't think this is a ppb call ultimately, but i think it's a worthwhile discussion to be had and the mailing list is a better place 20:30:53 anotherjesse: I can't speak for everyone, but for me personally that wouldn't bother me 20:30:58 let's move on to ceilometer 20:31:00 but we can do what anotherjesse said and recommend that redhat and ubuntu don't make packages for it 20:31:01 jbryce: agree 20:31:12 #option ceilometer incubation application 20:31:13 my compromise would be to leave it in in the source tree for people building their own packages 20:31:18 we _could_ filter it out from the source tarball 20:31:24 and ++ mtaylor anotherjesse 20:31:25 #topic ceilometer incubation 20:31:29 vishy: would you commit to continued bug fixing? 20:31:35 (reading and typing at the same time...) 20:31:39 http://wiki.openstack.org/Governance/Proposed/Ceilometer 20:31:58 creiht: well hopefully there are no bug reports because no one is using it! 20:32:00 :p 20:32:04 jbryce: I'd say it's a cinder+Nova call, the PPb should only be involved if the decision creates issues... not to make the call 20:32:04 * creiht sighs 20:32:14 creiht: I have no problem merging bugfixes 20:32:16 ttx: i agree 20:32:18 lol 20:32:24 * creiht stands down 20:32:38 creiht: sighs and laughter? 20:32:49 creiht: but I plan on immediately dumping the code, so it will have to be a backport from cinder i guess? 20:32:51 jbryce: incubation meaning that it is on the way to becoming core? 20:32:57 * ttx has been missing creiht sighing lately. happy to see you're back :) 20:33:11 creiht: it would be ship folsom, remove code right after release 20:33:14 anotherjesse: yes, the same meaning for incubation we've had for the past year :P 20:33:20 vishy: if it is the same code, then why don't they share some *gasp* common codebase? so that they could share bug fixes? 20:33:26 jaypipes: right - just making sure :) 20:33:29 :) 20:33:36 creiht: craziness! 20:33:40 do we expect a metering project to be part of core? 20:33:41 Are we on the Ceilometer topic? 20:33:45 I think so 20:33:55 anotherjesse: I think that's what we're about to discuss. 20:33:57 yes...on the topic of ceilometer incubation... 20:33:58 creiht: that's what I was suggesting earlier when I suggested making cinder a dep of nova and having nova/volume just be proxy calls to the cinder code, btw 20:34:02 (think that we are on the topic - I am not sure if metering should be core) 20:34:05 vishy: I don't like that idea either, but will wait to see what the mailing list turns up 20:34:23 creiht: ok. Am I on the hook for the email? 20:34:28 can we take the other discussion to the mailing list? or we can hit it again next week if we need to 20:34:45 vishy: depends... do you *really* want the mailing list email from me? ;) 20:34:51 jgriffith: can you take point on sending a mailing list email out? 20:34:57 jbryce: Yes!! 20:35:01 thanks 20:35:02 jgriffith: thanks 20:35:05 CEILOMETER! 20:35:05 :) 20:35:07 NOW! 20:35:08 = ) 20:35:13 jgriffith: talk with me offline 20:35:20 nijaba: you're up. :) 20:35:21 ceilometer has applied for incubation 20:35:27 * nijaba is here :) 20:35:36 nijaba: would you like to give an overview of what you all are trying to build? 20:35:36 * dhellmann is here, too 20:35:52 On Ceilometer, the application says, incubation in F, core in G: I think in all cases it would need to incubate longer than just one month (core projects for G need to be decided before the G cycle starts, which means somewhere in August) 20:36:08 dhellmann: welcome. 20:36:16 so we are trying to collect all metering information from various projetcs so that billing system and others have a single point of contact to callect all info 20:36:21 so we are talking incubation for the rest of F and for G, I think 20:36:29 ttx: i agree 20:36:50 * nijaba makes a note of it 20:37:00 ttx, can`t extra effort make it possible to have metering in G ? 20:37:17 Just because it's not core doesn't mean it doesn't exist. 20:37:18 the ceilometer team has been doing a great job of being open, using common code and practices, etc. I'm just not totally convinced that it needs to be a core project. 20:37:18 koolhead17: it's not a question of effort, it's a demonstration that you can follow a cycle 20:37:25 koolhead17: having it != core 20:37:31 koolhead17: just because the project isn't core / incubated doesn't mean that it doesn't work 20:37:58 koolhead17: doing just one milestone before an application sounds like an automatic rejection reason for me 20:38:09 ooh okey 20:38:19 vishy and anotherjesse, can you elaborate? 20:38:37 so we have 3 main infrastructure categories with compute, storage and networking. and then we have shared services like dashboard and keystone that make the other categories more unified and more easy to use. seems like metering is something that we get a LOT of requests for and could make sense in the shared services category 20:38:40 vishy: can you elaborate? I would think it is a piece of code that most if not all deployment will need 20:38:51 jbryce ++ 20:39:11 jbryce, ++ 20:39:41 nijaba: We've discussed limiting the scope of infrastructure to core IaaS services, metering seems to be right on the border 20:39:46 my reaction is that the ceilometer project should continue as they have, and the incubation discussion should be just before the G summit. If it makes sense, the project incubates in G and applies for core in H if it makes sense. 20:39:51 jbryce: although I can see it being that we have the hooks for it, and let various entities support it 20:40:09 an opensource project called ceilometer or a commercial product called FOO 20:40:19 johnpur: ++ 20:40:24 anotherjesse: I think the plan is to support multiple backends in ceilometer 20:40:28 in september we should have a good view on the metering project, and gives the community/mailing list time to react as well 20:40:43 anotherjesse: FOO would talk to ceilometer, but why have all FOO reimplement the hooks? 20:40:46 johnpur: would be a valid objection if we were questioning their maturity... but apparently we are questioning the coreness of its scope..; and that can be answered today 20:40:54 that's right, vishy: we won't be charging users, just collecting data 20:40:55 but i don't know how well it would support commercial implementations 20:40:59 nijaba: because then it requires that everyone runs ceilometer ... 20:41:08 johnpur: I don't think there's any reason not to start incubation in F (and continue incubation in G) if the PPB decides Ceilometer has the potential to be core. 20:41:12 nijaba: if you already have a metering system in place then you might want to use it 20:41:17 ttx: i am proposing delaying that determination, subject to more discussion 20:41:38 jaypipes: yes, i think the question is do we reasonably see that ceilo fits in core 20:41:40 nijaba: reading the roadmap - is there no public API to this in the folsom release? 20:41:43 (at some point) 20:41:51 johnpur: I think that's a bit unfair to them. We can determine the coreness of the matter now. Unless we prefer to punt to the TC 20:41:56 heckj: it's about to be done 20:41:57 vishy: sure, that is a perfectly reasonable question. 20:41:58 (which would be a valid thing) 20:42:06 heck, we are starting work on the API in the next week or two 20:42:07 jaypipes: if we say no now, I don't think it is no forever, but we could say lets let it stew a while longer. 20:42:08 heckj: before folsom is released 20:42:17 vishy: sure, agreed. 20:42:29 i don't think that saying it's attacking a problem that could also be attacked by a commercial entity is necessarily the best argument since everything in openstack has commercial competitors 20:42:50 ttx: i don't get the attitude that if a project isn't in incubation/tracking to core that it isn't important? 20:43:02 and as nijaba said, from my understanding, it's more about centrally exposing data from the different projects which could be consumed by zuora or x commercial billing product 20:43:14 jbryce: exactly 20:43:16 jbryce, that's right 20:43:26 heckj: http://wiki.openstack.org/EfficientMetering/APIProposalv1 20:43:29 jbryce, sounds good 20:43:41 at dreamhost we are going to pull data from ceilometer and push it into our existing billing system 20:43:46 johnpur: oh, no. By a bit unfair to them, I just mean, we make them wait and do extra efforts, which will not really help us determine the question of whether metring is core openstack or not 20:43:51 The project is for collecting resource usage data related to billing, but does not include any facility for recording customer billing details or actually charging customers or for transforming collected data into billing items 20:44:08 ttx: ok, ic 20:44:20 As someone who vote no to Horizon being core (for reasons that I believed core projects to be the building blocks of the infrastructure), I've come to view Horizon as the critical piece of the OpenStack puzzle that it is: while it is not required for Openstack to function, it is the canonical reference implementation for a GUI. And if Ceilometer represents a canonical reference implementation for a metering project, I think it deserves to 20:44:21 be incubated. 20:44:26 if ceilometer is incubated and becomes core, does that mean you *HAVE* to use it to be considered an OpenStack cloud (TM) 20:44:44 johnpur: but yes, I can see how waiting could help us see how their API stabilizes and how well they become indispensable to the other projects 20:44:49 anotherjesse: I'd say no more than horizon 20:44:59 anotherjesse: I woudl hope not 20:45:13 anotherjesse: no. you don't require Horizon, but it's still a critical core reference implementation of a part of OpenStack 20:45:27 anotherjesse: can we say that being an OpenStack cloud (TM) is providing all published APIs? 20:45:30 jaypipes: while I'm almost the other way - horizon is critical but it confuses to have a GUI next to the service - I had voted yes originally ;) 20:45:33 anotherjesse: how would you even test that? the others apis, horizion, etc would be easier to test for. 20:45:52 i guess the ceiliometer api could be tenant facing 20:46:00 anotherjesse: funny how time changes our opinions, eh? :) 20:46:00 I'm asking because I want to know what it means to be in core for ceilometer 20:46:13 currently we single out compute and storage apis as requirements for being "openstack", not the shared services 20:46:15 pvo: not at this point, but is considered for future versions 20:46:21 pvo: it isn't clear to me that the ceilometer API needs to be tenant facing, but it could be 20:46:24 I hope that we can grow to have lots of projects that integrate with openstack but aren't core… I'm now pro-small-core ;) 20:46:29 I mean in terms of providing features useful to tenants 20:46:32 I would love to know my potential bill through an api 20:46:33 anotherjesse: to me, "being core" means that the project prioritizies integration with the other core pieces of OpenStack. 20:46:49 pvo: we don't know how much you might be charged, only how many resources you've used 20:46:57 *potential* 20:47:01 so the provider still needs to do some calculation to determine the bill 20:47:03 the usage consumed is the important part 20:47:06 anotherjesse, ask me how much horizon changes openstack. greatly :) 20:47:06 pvo: from roadmap: "End-User API access to own metering information" 20:47:18 nijaba: totally agree 20:47:25 koolhead17: I know - I and my team has done a lot of work on it 20:47:27 and usage consumed metering with an api seems like a useful thing to be consistent across implementations 20:47:30 to me 20:47:43 mtaylor: ++ 20:47:45 core designation really has historically been around integration with other releases, coordinated cycles, a level of maturity and meeting a threshold of being generally useful to most openstack users 20:47:49 anotherjesse, :) 20:48:02 mtaylor: ++ 20:48:09 jbryce: ++ 20:48:24 jbryce, ++ 20:48:53 also, core projects are packaged by our downstreams, with other projects added by picking and choosing 20:48:53 given that approving for incubation today won't mean it is in core by G, I like johnpur's originally idea of voting before the summit 20:49:03 One thing to note is that the foundation would weigh in on the final core inclusion call anyway 20:49:12 ttx: good point 20:49:14 (board of directors) 20:49:18 anotherjesse: yes, that would be totally fine with me. 20:49:50 so the question of "belonging to the scope of openstack" might end up being decided by them... while the TC vouches that the project is well ru and integrated with the others 20:49:54 i'm ok with deferring, but could we define what we are hoping to gain in the deferral period so we can make sure we act on it? 20:50:04 jbryce: so shall we vote on whether to delay this incubation vote until September? 20:50:08 is it more feedback from the mailing list? 20:50:17 making sure it's taking a sane technical approach? 20:50:25 scope of openstack? 20:50:39 jbryce: I kinda feel like we should have a section in proposals of integration status and efforts with all existing core projects 20:51:06 * jaypipes thought we had that.. 20:51:25 basically its a bit of bad timing, with Folsom nearing the end and the future BoD/TC split 20:51:32 since the project is primarily about aggregating and making usage information available to a variety of downstream consumers (billing systems, etc.) it would be cool to get feedback fromt he potential consumers on the approach, API, etc. 20:51:52 anotherjesse: Nova integration is close to complete, and we have intiated dicussions with all other projects 20:51:59 its on my list to evaluate, just haven't had time 20:52:19 on the other side, there is no reason why we couldn't incubate it and later the TC can decide that it doesn't belong as a core project. 20:52:26 vishy: also true 20:52:35 but unlikely 20:52:45 nijaba: cool - I'm just thinking about the meta-process :) that as we incubate things we should have an explicit section on what it means for all the projects - for instance nova has a notification queue, but what does it mean for keystone, or glance 20:52:49 vishy: yes, that would be my preferred option 20:52:53 notmyname: unlikely what? 20:53:01 I don't see the need to vote today. The work is progressing and the decision will be reevaluated later. 20:53:15 ttx: unlikely that a vote today would be overturned by tomorrows PPB/TC 20:53:17 anotherjesse, we are going to be working with the other projects to add notifications as needed 20:53:18 ttx: i think he's going off the track record that we've sent everything through incubation to core so far 20:53:18 pvo: +1 20:53:37 anotherjesse, that is easier now that RPC and notifications are in openstack-common 20:54:05 notmyname: right... I think there would actually be more risk that the BoD would turn down our suggestion as "not in their idea of openstack scope" 20:54:47 i think we should defer and try to gather a little more information 20:55:03 jbryce: to answer which question? 20:55:16 I think we made a mistake with keystone, incubating it before it was ready to be used. I'd prefer to look about incubation *after* the project is fully operational rather than make a keystone-mistake again 20:55:18