20:01:42 #startmeeting tc 20:01:43 Meeting started Tue Sep 3 20:01:42 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:47 The meeting name has been set to 'tc' 20:01:54 Our agenda: 20:01:59 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:09 I suspect we'll probably to next week 20:02:17 err 20:02:18 o/ 20:02:21 s/probably/overflow/ 20:02:25 :) 20:02:37 #topic Marconi incubation request: final discussion 20:02:42 \o/ 20:02:48 #link http://lists.openstack.org/pipermail/openstack-dev/2013-August/014076.html 20:02:52 o/ 20:02:57 #link https://wiki.openstack.org/wiki/Marconi/Incubation 20:02:58 oh, i'm proxying for markmc 20:03:09 btw. 20:03:11 russellb: 2 votes! power to you ! 20:03:15 yeah! 20:03:24 I think last week we covered Marconi scope questions, like: 20:03:33 - Marconi is a queuing service itself, not a provisioning service for some other queue software 20:03:45 - Marconi shall provide alternatives to MongoDB on the storage backend, but ideally keep the user-facing API(s) consistent 20:03:52 We put together a Q&A section in MArconi's incubation page: https://wiki.openstack.org/wiki/Marconi/Incubation#Raised_Questions_.2B_Answers 20:04:04 flaper87: just read that, it's pretty nice 20:04:10 I wanted us to discuss integration points with other projects. 20:04:16 +1 20:04:21 Obviously you will integrate with Keystone, I suspect you'll appear in Horizon at some point too... 20:04:22 sure thing 20:04:34 ttx: we already support keystone 20:04:36 Your wiki page mentions running on Nova servers, behind "OpenStack load balancers" -- Neutron LBaaS stuff, or somethign else ? 20:04:57 re Horizon, I could see it being helpful to see queue stats, create/delete queues, a few management things like that, so 20:05:14 ttx: LBaaS 20:05:29 kgriffs: What about using Heat vs. using Nova directly ? 20:05:40 and it doesn't use nova directly does it? 20:05:49 are you saying that it's possible to deploy on top of nova? 20:05:53 as opposed to specific integration? 20:06:13 sorry, that blurb may be a bit misleading 20:06:38 just like you could run glance on nova, or whatever 20:06:54 while we expect that the majority of deployments will utilize LBaaS and IaaS marconi's design does not preclude running elsewhere 20:07:03 yeah, I'd say so, yes! 20:07:12 what kgriffs said! 20:07:21 ok. 20:07:28 so, it's not specific integration 20:07:39 can't wait until Ironic makes all that even more confusing 20:07:39 just that you expect that it will be common to deploy that way 20:07:45 jright 20:07:47 As per Ceilo, we're planning to integrate w/ it for states and billing. I started digging into how it could be done 20:07:47 right 20:07:49 cool 20:07:55 kgriffs: has marconi been tested with neutron's lb? 20:07:56 ideally you would also hook into heat/autoscale 20:07:57 stats* 20:08:08 annegentle: it hasn't 20:08:09 but thats an operation thing and not tightly coupled to marconi 20:08:17 yeah, so maybe there's some integration work with the deployment program (tripleo) 20:08:17 /late 20:08:23 some integration that could be done, i mean. 20:08:29 russellb: totally 20:08:35 as in, help develop the heat templates to get this stuff deployed 20:08:39 notmyname: we were just slowly getting more excited. 20:08:52 :-) 20:08:59 just caught up with the buffer playback 20:09:00 Sidenote: if accepted, Queue service will become a new "program" with the Marconi project itself being in incubation for integration in the common release 20:09:09 The "mission statement" for the program is mentioned on the wiki page linked above 20:09:17 ttx: +1 20:09:27 you might want to review it as part of your decision -making process 20:09:37 hi. i'd like to encourage marconi to target integration with devstack, tempest, and the devstack-gate tests early; and i'd like to encourage the tc to view that as a goal for promotion from incubation. 20:10:00 jeblair: +1 20:10:01 jeblair: yes, we intend to be a lot more blocking on that 20:10:05 FWIW, the integration with other services and tools like devstack is part of our roadmap for our incubation process 20:10:17 meaning, we want to get all that done before graduating 20:10:23 jeblair: especially with projects that will be aware of that condition from incubation day 0 20:10:23 +1 20:10:42 (at least we discussed that, FWIW) 20:10:57 More questions on Marconi before we vote ? 20:10:58 cool; it's pretty easy to run alternate devstack tests/environments now, so a project can start running those kinds of tests before it joins the shared devstack-gate queue with the rest of the common release projects 20:11:00 kgriffs: so this is where I get confused. As an admin user, I could go to Horizon to see my OpenStack deployment's queue? 20:11:04 jeblair: +1 20:11:30 russellb: re heat templates, I think it only makes sense for the Marconi team to contribute there 20:11:30 annegentle: nah, this is different from the queues used as a part of the infrastructure 20:11:32 kgriffs: as opposed to some cool stock quote queue I made up as a web dev? 20:11:42 annegentle: yup 20:11:46 russellb: ok that's what I thought, we'd really need to map out the Horizon integration then 20:11:52 Personally I consider a queue service to be pretty essential in a IaaS+ setting 20:12:01 I'd like the focus to be first on providing a featureful and performant solution... 20:12:05 ttx: Agreed 20:12:06 ...rather than on supporting multiple "transports" and "backends". 20:12:11 flaper87: I think the answer is "no?" no? 20:12:13 flaper87: :) 20:12:15 With that caveat noted, I'm ready to vote 20:12:19 ttx: +1 20:12:21 ready here too 20:12:22 ttx: that's our goal 20:12:40 annegentle: right 20:12:42 :D 20:12:45 flaper87: ok, whew 20:12:51 ttx: ok good to go too 20:12:59 * flaper87 bites his nails 20:13:06 Heh 20:13:10 flaper87: note that it's everyoen goal, and then vendors start contributing weird stuff 20:13:18 heh 20:13:27 quick question 20:13:27 yeah, don't want to get distracted by too much of that ... 20:13:31 ttx: +1 20:13:32 (no, i won't give examples :) 20:13:32 ttx: you're too funny 20:13:51 ttx: lol 20:13:55 would you see an alternative backend (e.g., MySQL) as a requirement for successful incubation? 20:14:23 IMO, no 20:14:24 kgriffs: is successful incubation graduation to integrated? 20:14:25 i'd like to say no ... but the licensing of mongodb probably means we should consider it 20:14:31 kgriffs: I think some people see a non-AGPL deployemnt option as a key requirement 20:14:31 yes, graduation 20:14:36 because i think a lot of people are going to hate that 20:14:40 for graduation 20:14:45 ok 20:14:49 ok 20:14:52 kgriffs: but personally I would not block on that 20:15:02 i would be tempted to personally ... 20:15:05 awesome feedback, thanks 20:15:05 russellb: didn't we burn that bridge with ceilometer? ;) 20:15:07 well, maybe i wouldn't block 20:15:09 heh 20:15:12 thanks for the clarification, makes sense 20:15:22 i mean if people are upset enough, they should help add what they want, right? :-) 20:15:29 but i expect it to be an "issue" with some folks. 20:15:40 russellb: seconded 20:15:50 kgriffs: so maybe I wouldn't require for graduation, but would be a good feature to add before the first integrated release 20:15:50 cool 20:16:04 (i.e. during the J cycle once you graduated) 20:16:07 ttx: cool beans 20:16:15 that's like *forever* from now right? 20:16:21 heh. :D 20:16:22 more questions ? or all TC members ready to vote ? 20:16:28 ttx: i thought there was a licensing issue? no? 20:16:32 I'm ready 20:16:38 ready 20:16:47 what's ceilometer using now? 20:16:59 dolphm: no, the client is permissively licensed 20:17:00 dolphm: no. There is a licensing issue with one deployment option of marconi 20:17:06 o/ 20:17:17 vishy: just in time for the best part! 20:17:26 o/ 20:17:30 annegentle: mongodb or sql 20:17:40 * mordred scans scrollback real quick 20:17:41 vishy, mordred: you might want to file questions before we vote ? 20:17:51 jd__: thanks 20:17:57 <--- "some people see a non-AGPL deployemnt option as a key requirement" +100 20:17:58 sorry i'm late, just got through airport security 20:18:05 vishy: I'm in an airport too! :) 20:18:19 mordred: I was trying to proxy you informally 20:18:30 I would say non-agpl deployment option should be a requirement for graduation 20:18:35 ceilometer has one 20:18:47 ok 20:18:58 definitely more important than a new transport IMO 20:19:00 mordred: they can use sqlite, does it count ? 20:19:03 licensing is a separate issue than "alternate backends", IMO. 20:19:05 :P 20:19:09 ttx: lol 20:19:10 sqlite-- 20:19:20 back to the first question of it being a requirement for graduation 20:19:23 json blob text files 20:19:28 Well, at least one distro uses sqlite as their default 20:19:32 For nova glance etc 20:19:39 mikal: I don't consider that to be any better 20:19:44 mikal: and that's just bonkers 20:19:47 distro-- 20:19:55 I didn't say it was a good idea, just observing... 20:19:55 also worth reiterating that graduation is also decided by the future TC, not us 20:20:02 * notmyname likes sqlite 20:20:03 * mordred just doesn't want to see 'install mongodb' be a requirement for anyone wanting to run it 'for real' 20:20:08 * mordred likes sqlite too 20:20:11 dolphm: apply for reelection! 20:20:19 ttx: just sayin' 20:20:31 mordred: makes total sense to me 20:20:32 mordred, vishy: you ready to vote ? 20:20:34 * mordred does not know enough about how it uses sqlite to know if it's sensible like swift, or whether it's a silly choice like a nova + sqlite would be 20:20:41 ...just a funny discussion when a typical swift deployment can have millions of sqlite DBs 20:20:47 we had a conversation previously about setting terms for graduation on a project going into incubation 20:20:54 mordred: sqlite is just for localhost dev/test environments 20:21:02 notmyname: you're using it in a unique way arguably :) 20:21:03 notmyname: I think your architecture makes sense with sqlite - you don't have a central sqlite 20:21:03 (not production!) 20:21:14 kgriffs: right. so I think that for me it's a graduation requirement 20:21:19 and I say that 20:21:31 I would be +1 for calling it a graduation requirement, fwiw 20:21:33 just because I think we shoudl be explicit about things we expect you to work on in incubation 20:21:36 oh look, a meeting. 20:21:40 FWIW, we were already planning to implement a rel-based backend, it was a matter to know when 20:21:47 I'm cool with that 20:21:50 cool 20:22:01 so, having it for graduation makes that decision easier 20:22:03 :D 20:22:10 mordred: gabrielhurley: "it" being "an alternate storage backend" or "it" being "something not agpl licensed"? 20:22:11 gabrielhurley: having graduation requirements is all about learning from our past mistakes after all 20:22:20 we sort of expected folks would want a couple deployment options, in any case 20:22:24 notmyname: "something not agpl licensed" 20:22:32 notmyname: +1 for simply "not agpl licensed" 20:22:38 notmyname: I'd go with "something not agpl licensed which is already common in OpenStack deployments" 20:22:39 notmyname: ability to install marconi in a real production manner without having to install something AGPL 20:22:45 I don't like the increasing number of projects increasing the requisite number of underlying services a deployer has to support. 20:22:48 gabrielhurley: +1 20:22:49 gabrielhurley: +1 20:22:52 ok, so if they ripped out mongo and replaced it with something else, but not "pluggable", that's ok 20:22:53 gabrielhurley: +100 20:22:56 we shouldn't be requiring 4 different databases. 20:23:00 yes. I would be fine with that 20:23:04 gabrielhurley: +1 20:23:06 although I doubt they will make that choice :) 20:23:07 gabrielhurley: fo shizzle 20:23:22 * mordred ready 20:23:33 mordred: perhaps, but ttx (and others agreed) that the priority should be on functionality rather than plugins 20:24:01 #ready 20:24:05 #set 20:24:10 #abstain 20:24:11 notmyname: unfair! I was thinking ZeroMQ transport and RabbitMQ backend when I said that 20:24:15 :) 20:24:25 ttx: ah, sorry for the misrepresentation 20:24:42 markwash: lol 20:24:45 lol 20:24:53 notmyname: no, you're right. And I stand corrected. 20:24:57 #startvote Accept Queue service as a new program with the Marconi project in incubation during the Icehouse cycle? yes, no, abstain 20:24:59 Begin voting on: Accept Queue service as a new program with the Marconi project in incubation during the Icehouse cycle? Valid vote options are yes, no, abstain. 20:25:00 Vote using '#vote OPTION'. Only your last vote counts. 20:25:06 #vote yes 20:25:07 #vote yes 20:25:09 #vote yes 20:25:10 #vote yes 20:25:10 #vote yes 20:25:14 #vote yes 20:25:15 #vote yes 20:25:17 #vote yes 20:25:18 #vote yes 20:25:20 #vote yes 20:25:27 #vote abstain 20:25:31 russellb: who needs gerrit when we have NICKCHANGE 20:25:37 ttx: yes! 20:25:38 #vote yes 20:25:43 #vote abstain 20:25:45 30 more seconds 20:25:51 #vote abstain 20:26:04 #vote abstain 20:26:17 #endvote 20:26:18 Voted on "Accept Queue service as a new program with the Marconi project in incubation during the Icehouse cycle?" Results are 20:26:19 yes (11): ttx, notmyname, markmc_by_proxy, jd__, annegentle, russellb, mikal, mordred, shardy, dolphm, markmcclain 20:26:20 abstain (4): gabrielhurley, markwash, vishy, jgriffith 20:26:30 For the abstain votes: is that no opinion? not really convinced ? 20:26:38 not convinced 20:26:39 or haven't had enough time to investigate? 20:27:14 jgriffith: fair enough 20:27:15 Only real argument I see is "Amazon has it" 20:27:17 curious which part you're not convinced of though ... it's fit for openstack? goals? etc? 20:27:22 jgriffith: not convinced of the need, or not convinced of this approach? 20:27:27 I have nothing against marconi, I just haven't really been convinced that it should be an integrated project under a new Program. 20:27:38 goals, value, what the implementation is really going to look like etc etc 20:27:42 jgriffith: +1 20:27:47 * markwash got last minute cold feet. . 20:27:53 lol 20:28:03 id devanada back from Burning man ? 20:28:06 generally positive 20:28:07 is* 20:28:08 (fwiw, i was nearly an abstain, due to concerns about scope creep into notifications) 20:28:15 devananda: around ? 20:28:17 ttx: just because i missed the first part of the meeting 20:28:25 vishy: perfect reason! 20:28:27 i'm a little worried about scope creep in transports, even, but i took a leap of faith, heh 20:28:28 aww ttx u dont wanna do trove first ;) 20:28:36 haha 20:28:40 NobodyCam is maybe around in devananda's stead? 20:28:40 just making sure I haven't missed something obvious 20:28:51 If marconi does eventually become integrated I'm all for it, fwiw 20:28:54 we can definitely curtail that scope creep, FWIW. :D 20:29:06 hub_cap: ironic should be fast. I'm trying to delay yours so that you can get heat-trusts in :P 20:29:12 lol 20:29:13 HAH ttx 20:29:13 lol 20:29:26 ttx: thats a bug afaic 20:29:29 in trove 20:29:29 hub_cap: code faster..... 20:29:36 not a feature, wink wink 20:29:37 unfortunately nobody from ironic is around yet... 20:29:40 kgriffs: yep, i have faith 20:29:49 hub_cap: so you go now 20:29:51 ttx: default deny request? 20:29:52 #topic End-of-cycle graduation review: Trove 20:29:58 Thanks guys 20:30:03 lol notmyname glad im here! 20:30:19 hub_cap: Could you describe your current status and progress ? 20:30:22 so fwiw, the heat optional provisioning is under review and passing tests 20:30:25 sure ttx 20:30:33 we are integrated into horizon (thx gabrielhurley +crew) 20:30:46 we have gone from 2 companies to about 8 with at least 4 actually coding daily 20:30:48 kgriffs: i think my concerns weren't valid... you're clearly venturing into notifications, but the long term scope seems reasonably well defined 20:31:05 weve cleaned up a good bit of tech debt 20:31:15 hub_cap: I think there were two main concerns I think wrt graduation: Heat integration and Tempest integration 20:31:25 hub_cap: ++ 20:31:31 ttx: we decided it woudl be just plain wrong to push tempest on me 20:31:33 If those are not addressed yet we at least need to be convinced that they will be addressed soon enough to not adversely impact the Icehouse cycle 20:31:34 a few wks ago 20:31:50 heat is under review, w 2 caveats 20:31:50 hub_cap: can you link the heat provisioning patch pls? 20:31:56 https://review.openstack.org/#/c/44530/ 20:31:59 1) trusts 20:32:17 2) resize isint using heat, because we rely on the confirm resize nova step to do some "stuff" 20:32:43 #2 id like to address by not necessarily using the nova resize, but a smarter cluster-like resize 20:32:44 hub_cap: like I just said, i wouldn't block graduation on that... we just need to be convinced this is top prio and will not be a problem during Icehouse 20:32:48 if possible 20:32:52 ttx: its my #1 past heat 20:32:53 so trusts *should* land really really soon, hopefully tomorrow 20:32:58 woo shardy 20:33:14 i really want to do tempest integration really really bad 20:33:15 how about CI integration? 20:33:18 i want official gating tests 20:33:22 hub_cap: https://review.openstack.org/#/c/43380/ 20:33:23 hub_cap: but your use case should work now, even without trusts 20:33:33 jeblair: that's what I mean by tempest integration 20:33:36 * mordred is specifically less worried about tempest and trove due to existence of trove ci stuff - I know the work exists, so porting it in in icehouse should be doable 20:33:45 zaneb: it does when i send the password 20:33:56 mordred: it's existed for a long time but still isn't being run in the context of openstack ci 20:33:59 yes mordred, but i still really want to make all new tests go thru tempest 20:34:02 jeblair: agree 20:34:07 it's being run as a third party test system 20:34:12 i dont know if we want to do that jeblair/mordred 20:34:12 * mordred thinks all of trove ci needs to be integrated 20:34:13 hub_cap: there was a patch to remove that requirement... I thought it got merged 20:34:17 hub_cap: we do 20:34:17 id rather start making tempest tests 20:34:21 which is just a little weird for an official openstack project 20:34:23 hub_cap: can the current version be configured to work using full vms instead of openvz containers. 20:34:30 mordred: id be happy to work w/ you 20:34:34 vishy: default is not ovz 20:34:38 its whatever devstack uses 20:34:47 trove is virt agnostic 20:34:52 hub_cap: the question is whether or not we give you a pass on not having done that yet :) 20:34:52 hub_cap: corollary: so it might be possible to do it via docker instead? 20:35:07 (for example) 20:35:10 hub_cap: bug #1217617 will allow most use-cases except autoscaling work with token auth and no trusts 20:35:11 Launchpad bug 1217617 in heat "Always requiring password on create is too restrictive" [High,In progress] https://launchpad.net/bugs/1217617 20:35:12 mordred: well sure, but i dont remember that being a requrement a few mo' ago 20:35:20 vishy: if docker works w/ nova then hell yes 20:35:20 jeblair: the "no graduation without integration tests" condition was added a bit recently, while the trove folks were already struggling to get our "heat integration" condition in 20:35:28 +1 ttx 20:35:35 trust me ;) its my highest prio 20:35:37 hub_cap: yup. but that's before we realized that letting things graduate without ci integration was getting us into a bad place as a project 20:35:38 hub_cap: interesting. Do you make use of cinder volumes? 20:35:39 past getting heat in 20:35:41 ttx: well, this is your show, but honestly, it's not like devstack or tempest or the openstack ci system has been a secret 20:35:44 hub_cap: actually, my bad. you are waiting on this: https://review.openstack.org/#/c/44400/ 20:35:58 hub_cap: because you _do_ have some CI, I can be convinced that making it an icehouse task might not be terrible 20:35:59 zaneb: yessir 20:36:00 jeblair: so for that last time I'd settle with "it's my top priority once heat is in, which should be in a few days" 20:36:16 mordred: should be pretty easy honestly i bet we could get it knocked out in a few days 20:36:31 sounds acceptable to me. there's clearly a plan here. 20:36:46 jeblair: but I tend to agree with you it should have been worked on even while not being a strict condition. 20:37:22 ya we got it running a while ago and havent really mucked w/ it. id gather we could get it running before the summit tho 20:37:55 its really just running a script on a vm 20:37:57 thats all we do :P 20:38:07 and you have the whole "prov a vm" stuff worked out 20:38:08 hub_cap: no, I think we're missing each other 20:38:20 vishy: yes it does, but hub_cap will have to provide details 20:38:21 mordred: im always missing you /me sniffles 20:38:36 at least last time I looked 20:38:46 vishy: yes we do (Sry) 20:38:47 hub_cap: we're not interested in infra running additional things that aren't related to devstack-gate 20:39:08 hub_cap: we're interested in integrating the things that your script does into the normal scripts 20:39:10 mordred: ah ic. i dont blame you! then it can be retrofitted id imagine :) 20:39:13 hub_cap: is there any missing feature in your havana release that you would definitely want to add during the Icehouse cycle ? 20:39:32 like a blatant feature gap ? 20:39:36 well tempest, buit that not a feature 20:39:45 hub_cap: apart from the two already-mentioned 20:39:45 ttx: i have wants but nothing is missing 20:39:53 config mgmt is gonna be nice 20:39:56 and so is clustering 20:40:02 and replication/resizes 20:40:08 but those arent missing 20:40:16 they just arent done yet 20:40:19 hub_cap: does troveclient work with normal OS_* env vars yet? 20:40:22 oh! the plane is moving 20:40:23 * mordred runs away 20:40:37 ha. 20:40:46 HA mordred not yet but i can knock that out fast 20:40:51 please do 20:40:59 aboslutely 20:41:02 gah thought today was monday :( 20:41:04 ill put it as a bug in rc1 20:41:13 cuz it is a bug to me 20:41:22 hub_cap: you mentioned 4 companies working daily on the project now... but then you seem to be the only one working on graduation-essential stuff like CI and heat integration ? 20:41:38 does that mean they contribute tactical features ? 20:41:38 heh.. well yes 20:41:47 basically ya 20:42:18 mirantis/cern made rhel work, and are making the dev env a bit nicer before they jump in full force w/ features 20:42:19 when you say "you", is that "rackspace" or really just you ? Worrying about bus factor 20:42:34 i prefer the lotto factor ttx 20:42:50 im not the only person working on public facing interests 20:43:01 i just took it upon myself to tackle the graduation stuff 20:43:12 horizon got done via rax/cern/mirantis together 20:43:20 devstack is a hp thing thats happening 20:43:33 so other teams/companies are working on non tactical features 20:43:47 well non $tactical$ features 20:44:00 OK. On my side I can report that trove has been following the release schedule for a few milestones already and it worked really well 20:44:13 yes thank you ttx for the help w/ all that 20:44:16 so no objection from a release management perspective 20:44:24 its nice to be in the know at the begin of the process 20:44:28 rather than after graduation 20:44:46 i liked a full cycle of milestones + rc's (when that comes), ff, etc.. 20:45:02 maybe other programs could chime in (docs, QA, infra) -- although jeblair already raised his QA/Infra concerns 20:45:25 annegentle: is Docs fine with trove being integrated in Icehouse ? 20:45:31 docs http://docs-draft.openstack.org/30/44530/3/check/gate-trove-docs/cef4dbc/doc/build/html/ 20:45:41 annegentle: I guess that would be a prio 2 (non core) project ? 20:45:44 so for a docs perspective, they have done the work we've outlined with openstack processes 20:45:48 also we have a mirantis fellow who has created docs for a existing install 20:45:57 thats under review 20:46:33 https://review.openstack.org/#/c/44668/ 20:46:40 OK, I'm ready to vote -- other questions ? Anyone wanting a delay before we vote ? 20:46:58 it's our first end-of-cycle graduation review so the rules are a bit fresh 20:47:03 :) 20:47:14 horray /me is a guinea pig 20:47:21 oh nm 20:47:26 just this cycle lol 20:47:29 #ready 20:47:29 I guess we could do it over two meetings if that gives people time to look into the code with more details 20:47:37 #ornot 20:47:40 HA 20:47:51 although I don't expect that many people reading random code those days 20:47:54 * jgriffith is still ready 20:48:01 ttx: quite a busy week ahead ... 20:48:02 w/ the review rush ttx ;) 20:48:06 * gabrielhurley is ready 20:48:07 russellb: ++ 20:48:14 ready 20:48:20 steady! 20:48:28 go? 20:48:32 :) 20:48:38 -2 20:48:40 kidding. 20:48:46 russellb: slap! 20:48:57 ouch i got a big red X from russellb 20:48:58 I'm giving it another minute to make sure everyone is fine with voting now 20:49:02 :) 20:49:09 hes good at giving those ;) 20:49:34 fine with voting now 20:49:38 same 20:49:59 #startvote Graduate Trove to be integrated during the Icehouse cycle? yes, no, abstain 20:50:00 Begin voting on: Graduate Trove to be integrated during the Icehouse cycle? Valid vote options are yes, no, abstain. 20:50:01 Vote using '#vote OPTION'. Only your last vote counts. 20:50:07 #vote yes 20:50:09 #vote yes 20:50:11 #vote yes 20:50:12 #vote yes 20:50:13 #vote yes 20:50:13 #vote yes 20:50:13 #vote yes 20:50:16 #vote yes 20:50:27 #vote yes 20:50:33 #vote yes 20:50:35 30 more seconds 20:50:45 #vote yes 20:50:48 #vote yes 20:50:50 #vote abstain 20:50:51 #vote yes 20:51:11 #endvote 20:51:13 Voted on "Graduate Trove to be integrated during the Icehouse cycle?" Results are 20:51:14 yes (13): ttx, vishy, markmc_by_proxy, jd__, annegentle, shardy, russellb, markwash, mikal, gabrielhurley, dolphm, jgriffith, markmcclain 20:51:16 abstain (1): notmyname 20:51:21 no mordred? 20:51:28 he got on a palce 20:51:29 mordred: is on a plane 20:51:30 mordred: on a plae now 20:51:32 *plane 20:51:37 snakes not included 20:51:47 thx everyone!! 20:51:48 #topic End-of-cycle graduation review: Ironic 20:51:53 hub_cap: congrats! 20:51:54 hub_cap: nice work 20:52:02 still no ironic dude around ? 20:52:05 congrats hub_cap 20:52:09 me 20:52:16 NobodyCam: hi! 20:52:20 deva is driving right now 20:52:29 NobodyCam: So my understanding is it's pretty obvious this one should not graduate, since devananda himself said it's not ready 20:52:38 ...and it does not really work yet... 20:52:42 correct 20:52:49 So the question is more... should it continue to be incubated or should it be dropped because it's not going anywhere ? 20:53:06 it is going forward! 20:53:08 oh I hope we keep incubating 20:53:16 not going anywhere? 20:53:23 I would be opposed to dropping it from incubation 20:53:29 Although I also don't have the time to work on it... 20:53:40 vishy: s/because/if/ 20:53:58 vishy: just making sure we still all want it in incubation. 20:54:00 ironic - 72 code reviews in the laast 30 days 20:54:02 i haven't been keeping up with the status 20:54:04 so still moving 20:54:05 ttx: perhaps a better way to phrase it is "should it be dropped and reapply when it is ready" 20:54:07 stupid english lacking subjunctive 20:54:12 462 reviews in the last 90 days 20:54:17 so, quieter in the last month 20:54:21 russellb: do you have stats on how many active devs? 20:54:25 well, burning man 20:54:28 lifeless: yeah 20:54:28 yes we are moving forward we had a lot vacations last couple of weekes 20:54:32 mikal: just reviewers 20:54:37 http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt 20:54:42 notmyname: yes, better. That said I'm very fine with projects taking more than one cycle to incubate properly 20:54:55 do you think it'll take one more cycle to be ready? two? three? 20:55:02 mikal: 24? 20:55:05 I would be glad to set a precedent, actually 20:55:09 ttx: one of the issues being discussed now is that graduation isn't "winning" just as not graduation isn't "losing" 20:55:22 mikal: ah, nvm 20:55:22 ttx: (being discussed in context of the "what is core" stuff) 20:55:26 dolphm: wow, more than I expected 20:55:35 define active 20:55:50 * mordred back 20:56:07 mordred: trove was accepted, discussing ironic now 20:56:12 http://stackalytics.com/?release=havana&metric=commits&project_type=openstack&module=ironic&company=&user_id= 20:56:16 ironic contributors ^ 20:56:27 * mikal looks 20:56:33 So I'm fine with voting for keeping Ironic in incubation now 20:56:54 do we need to vote on that? 20:56:56 not sure we really need more time to discuss it, but was can also wait until next week 20:56:58 looks like the project could use some more heavy contributors beyond devananda 20:57:11 russellb: +1 20:57:18 mordred: maybe ? It's the first cycle we do end-of-cycle reviews :) 20:57:25 I was sort of looking forward to seeing the incubation process for this last until it's ready 20:57:30 mordred: I'm fine with not voting too. 20:57:48 probably only needs a vote if anyone suggests that it be dropped 20:57:54 i think the default answer should be that it stays 20:57:56 ttx: it is currently incubated - nothing automatically removes that - I think it's just still incubated unless someone wants to move that we un-incubate it 20:58:02 what russellb said 20:58:02 mordred: we need some way to remove dead stuff from incubation, but that can be ad-hoc rather than a regular review 20:58:14 russellb: +1 20:58:37 ttx: I think someone will propose we drop it if it's dead 20:58:48 #info Ironic stays in incubation for the Icehouse cycle 20:58:51 yikes. laggy plane wifi 20:58:57 dang, productive meeting :) 20:59:07 mordred: first world problems 20:59:07 #topic Open discussion 20:59:08 mikal: since june, 19 authors (including jenkins and a dupe)... so 17 by my count http://paste.openstack.org/raw/45694/ 20:59:19 all: You might have noticed that we're not using Gerrit to vote yet 20:59:23 jgriffith: lol 20:59:28 The repository is almost set up, blocking on bug 1219731 20:59:30 Launchpad bug 1219731 in openstack-ci "Populate tech-committee* groups in Gerrit" [Undecided,New] https://launchpad.net/bugs/1219731 20:59:39 Then we can review/accept the initial commit of reference documents at: 20:59:43 #link https://review.openstack.org/#/c/44489/ 20:59:50 Anything else, anyone ? 21:00:39 markmc from France ! 21:00:48 markmc: oh snap! 21:00:49 yah :) 21:00:50 * mordred thinks everyone is great - and also you all might have blinky lights around your head in mmy mind 21:01:18 ok then, next meeting 21:01:21 #endmeeting