20:02:14 #startmeeting tc 20:02:14 Meeting started Tue Aug 12 20:02:14 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:15 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:18 stupid wireless issues 20:02:18 The meeting name has been set to 'tc' 20:02:27 The agenda for today: 20:02:29 various Manila interested parties here as well.. 20:02:34 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:53 dolphm: around? 20:02:55 #topic Identity program scope and rename, take 2 20:03:09 We had that discussion two meetings ago, it's still a bit stalled 20:03:20 It's in two parts 20:03:23 1. Expand scope of the Identity program to include auditing (https://review.openstack.org/109664) 20:03:32 So this one hasn't reached the majority threshold yet, although it has enough votes to pass a simple vote 20:03:43 It's about moving pyCADF to keystone program and tweaking the mission to reflect that 20:03:54 There haven't been enough votes cast on this one, but I don't feel we should block it any longer. 20:04:04 especially with both PTLs involved approving it 20:04:17 yeah, the teams involved with that code agree to the move 20:04:17 So I'm calling for final vote on that one -- Please vote on this, otherwise it will pass just because it has 5 +1s and more +1s than -1s 20:04:21 I'm curious how this changes the requirement for projects to integrate with keystone 20:04:33 (I probably won't pick up the votes before tomorrow though) 20:04:36 do all projects now have to integrate with pycadf, if it is part of keystone? 20:04:47 it's not part of keystone :) 20:04:54 it's part of the identity program (proposed) 20:05:05 devananda: AIUI, some keystone middleware will use it 20:05:08 they are just taking over maintenance 20:05:15 russellb: "Identity:codename: Keystone" 20:05:28 zaneb: heh, fair 20:05:28 devananda: well, swift already has ways to be used without keystone 20:05:48 The second part is: Rename the "Identity" program (https://review.openstack.org/108739) 20:05:55 Now this part is not nearly as popular. 20:05:59 devananda: but yeah, it's a good question, are there dependencies inherited? 20:06:05 My take on it is that it's encumbered with the various ways we reuse program names for the moment 20:06:06 annegentle: right 20:06:19 So I would rather table any program rename until we have come to a point where a program short name really no longer applies to a program 20:06:26 In this case it's close enough, I think 20:06:32 and we have more pressing issues to address 20:06:33 program renames are really tough for user-facing docs 20:06:43 So I think it makes sense to abandon this one for the moment 20:06:43 ttx: ++ 20:06:48 so I'm +1 20:06:51 maybe we should just use uuids instead of names 20:06:59 dhellmann: frowny! 20:07:01 ttx: ++ 20:07:07 so unless it magically gets 7 +1s oevrnight, i'll abandon this one 20:07:43 Hi, sorry I'm here 20:07:49 other comments on that before we move on? 20:07:50 I'm sorry you're here too :) 20:07:51 dhellmann: maybe we should just use the code names and stop with the parallel naming :) 20:07:54 just kidding mikal 20:08:02 zaneb: heh 20:08:13 zaneb: I'll work on that as soon as we have all the other problems in openstack solved 20:08:18 should be sometimes next month 20:08:26 zaneb: doit! 20:08:35 ttx: I like your timeline 20:08:37 o/ 20:08:42 so, about that... 20:08:45 #topic Upcoming graduation reviews & future of the integrated release 20:08:55 we have a busy schedule ahead, and I want to talk about how we can meet our deadlines 20:09:08 We basically need to have Kilo contents wrapped up by September 16, so that we can plan the design summit AND get the official PTL election process started 20:09:21 That leaves 5 meetings to cover all graduation reviews. And one of them falls during Burning Man week 20:09:34 If we don't count the recently-incubated projects and the current padawans, we have ironic, marconi, barbican to consider for addition 20:09:54 how many people here will not be here during burning man week? 20:09:59 During the same time we have a couple of new program / incubation requests to wrap up (Rally, Manila) 20:09:59 ttx: regarding that, this is my last TC meeting until 9/9. probably ditto for mordred. 20:10:13 yup 20:10:17 devananda: so now it's burning man 3-week ? 20:10:19 * anteaya notes the election process will start earlier than usual due to the new questions feature this round 20:10:32 ttx: well, devananda and I go early and stay late because we feed people 20:10:36 anteaya: "questions"? 20:10:37 ttx: yes. well. it's two weeks, but +travel and the meeting falling on tuesday 20:10:40 we also need to have some serious discussion on what we want to do with the integrated release 20:10:43 but timelines for nominations and so on will be teh same 20:10:50 and we may want to have that discussion *before* considering those graduations 20:11:00 Do you think we are on track, or do we need to add a few more meetings to clear things up ? 20:11:01 ++ 20:11:11 ttx: I would *really* like to have that discussion without it side tracking to the (also very important) discussion on how to prioritize reviews 20:11:11 dhellmann: we talked aabout submission and curation of questions for tc candidates, for improved voter participation 20:11:21 anteaya: ah, yeah, I just forgot 20:11:21 devananda: ++ 20:11:24 dhellmann: it is on my timeline to implment 20:11:26 dhellmann: np 20:11:32 ttx: personally, the "wtf is the integrated release and why do we care so much about new programs" discussion needs to happen ASAP, IMO. 20:11:36 jaypipes: + 20:11:40 ++ 20:11:42 I mean 20:11:46 and I know mordred wants to be part of that one 20:11:51 so how do we solve this 20:12:00 there are two different aspects - one of them is "how do we scale our resources" - but the other is "how do we ship good things" 20:12:03 I think it warrants its own meeting 20:12:08 would it make sense to call a single topic meeting? 20:12:09 yes, its own meeting makes sense 20:12:14 ttx: as do I. this week, preferably. 20:12:16 and I think they're both important, and I'm happy to show up at additional times myself 20:12:21 devananda: good point about separating 20:12:26 to discuss where we want to go and how much drastic measures are warranted 20:12:33 single topic meeting sounds good 20:12:40 this week? 20:12:41 +1 to another meeting 20:12:42 ++ 20:12:46 * dhellmann never thought he'd say that 20:12:50 dhellmann: right? 20:12:52 never hear me say this, but yes let's have an extra meeting 20:13:02 mordred: if it's not this week, you will miss it? 20:13:06 russellb: just cuz devananda and mordred are out until 9/9 20:13:11 i've been away for a few days; is there something very urgent i need to catch up on? 20:13:17 jaypipes: no no, i'm agreeing that let's knock it out asap 20:13:22 I guess I can find time out of my roof to make that happen this week 20:13:28 i feel like the urgency of this topic is universally agreed to be high and i'm not sure why :) 20:13:30 jeblair: reading the whole "the future of the integrated release" ML thread... 20:13:33 otherwise monday sounded like a good idea 20:13:36 I feel the urgency too 20:13:36 jeblair, I've been away too; just the thread AFAIK 20:13:41 jaypipes: thanks, i'll put at at the top of my list. 20:13:43 ttx: deva and I could also figure something out if it's next monday, early next tuesday, or late the tuesday 3 weeks away 20:13:48 and it's only Tues/Wed. 20:13:48 jeblair: it's a meaty one... 20:14:04 i just want it discussed and out of the way, so it doesn't get in the way of all of the project consideraions we need to do 20:14:12 russellb: agreed. 20:14:13 I would advise against late tuesday 3 weeks away 20:14:22 So I'd propose 19:00 or 20:00 UTC, Monday. If that doesn't work, same hours, this Thursday 20:14:23 russellb: + 20:14:23 i don't want several discussions stalled with "but we need to wait until we decide at the future of release discussion" 20:14:24 yes. that would be my least favorite choice 20:14:25 if i'm doing aything, it'll be related to juno3 and feature freeze and nova integration 20:14:42 russellb: ++ 20:14:50 russellb: ++ 20:14:51 or we do Thursday and keep Monday as a backup extra session 20:14:58 ttx: wfm 20:15:02 I like having a backup 20:15:06 it's POSSIBLE this one might be a longer discussion 20:15:08 Thurs then Monday would be my preference 20:15:09 any time thursday is fine with me 20:15:12 me too. 20:15:17 thurs then monday ++ 20:15:19 * jaypipes will make time. 20:15:31 thurs or mon is fine 20:15:33 I guess I can make Thursday work, but 19:00 UTC would have my preference then 20:15:42 but I know thaat makes it difficult for mikal 20:15:50 * mordred willing to show up whatever time is good for mikal and ttx 20:15:55 same 20:15:59 yeah me too 20:16:01 mordred: there is unfortunately no such good time 20:16:04 I know 20:16:06 I will come whenever 20:16:13 This time is about the earliest I would voluntarily do 20:16:15 happy show up when needed 20:16:16 it's either very early for him or very early for me :) 20:16:17 (Its 6:15am here) 20:16:34 if there was a second "good time" we'd rotate :) 20:16:35 Wednesday at 1800 utc in this channel looks free 20:16:36 * mordred hands mikal a recently blow-dried kitten 20:16:44 achievement unlocked: have a meeting about meetings 20:16:45 mordred: thanks? 20:16:53 o/ 20:16:54 18.00 is really too early, not even convenient for me 20:16:57 russellb: heh 20:16:58 So yeah, this time slot on some other day of the week works 20:17:02 ttx, do you have a sense of concrete suggestions from the thread that there might be reasonable consensus around? 20:17:16 Thursday, 19:00 in #openstack-meeting-3 20:17:16 markmc: i certainly don't 20:17:27 ttx, agree with devananda that the thread seemed to have been derailed from issues directly related to adding new projects 20:17:37 markmc: not really. i want the first meeting to get people to shout problems and proposed solutions 20:17:58 thursday at 2000 utc all meeting channels open 20:18:04 then use some time to digest them, and if we think there can be convergence, call another meeting to come up with something 20:18:10 wednesday at 2000 -alt and -3 open 20:18:27 everyone OK for Thursday, 19:00 in #openstack-meeting-3 ? 20:18:31 ttx, just wondering whether we can make real progress on list in preparation for the meeting 20:18:40 is 19:00 UTC now? 20:18:41 we may just have to bring our own brains 20:18:46 * annegentle asks the dumb time questions 20:18:47 Yep 20:18:51 annegentle: now is 20:18 UTC 20:19:05 20:19 20:19:08 annegentle: 3:00 Eastern 20:19:09 :) 20:19:18 Got it, thanks 20:19:23 4 eastern. 20:19:30 heh hm 20:19:38 #info Extra TC meeting on Thursday, 19:00 in #openstack-meeting-3 20:19:56 oh, 1900UTC, yeah, 3 eastern 20:20:10 markmc: i think it was derailed from the topic of culling fail[ed/ing] projects, which is related to not adding new projects. 20:20:10 #info specific agenda: The need for change in integrated release for Kilo 20:20:18 (or absence thereof) 20:20:32 OK, next topic 20:20:43 markmc: and that the litmus we use when deciding to add new projects should be mroe than just "meets QA and release process standards" 20:20:58 devananda: the requirements list is already quite a bit more than that 20:21:16 Feel free to fire warning shots on that ML thread 20:21:25 * dhellmann hopes anyone with specific goals makes them clear in that thread before thursday 20:21:28 i'd rather concrete suggestions / discussion than warning shots 20:21:31 although don't expect me to particiapte that much, I still need to rpetend I'm taking 3 days ofgf 20:21:37 devananda, actually, that felt like a slight derailment from the original topic - that we're hitting scaling limits as we add new projects 20:21:55 russellb: +1 20:22:17 russellb: yay, getting a bit more info on everyone's position on this could help 20:22:24 ok, we need to move on 20:22:26 #topic Propose Manila for Incubation (initial discussion) 20:22:27 markmc: I thought that the original topic presented the general issue in such a way that that seemed like the one and only topic at hand 20:22:33 I'm still here -- wireless appears to have stabilized... 20:22:36 markmc: but I can try to express that better on the list 20:22:37 bswartz: o/ 20:22:50 The program application is at: 20:22:56 #link https://review.openstack.org/111149 20:23:00 And the incubation application at: 20:23:04 #link https://review.openstack.org/#/c/113583/ 20:23:20 Manila was considered and application was rejected/delayed in the past 20:23:33 in November 2013 to be exact 20:23:34 ttx: so, the disconnect here is strange to me. We have an issue of general policy (are we too big) which we've deferred, but we're not discussing an issue of specific policy (should we become bigger by adding a thing) 20:23:43 ttx: shouldn't this conversation happen after the first one? 20:23:45 Incubation application has a pretty good account on what was said then 20:24:00 mikal: yes, at least final decision needs to 20:24:01 s/not/now/ 20:24:10 ... what mikal said 20:24:17 yeah we included an appendix in the incubation application answering questions raised last time 20:24:22 but I figured we could still have a few early questions 20:24:37 Nothing against Manilla 20:24:37 If you feel like this is useless, we can skip though 20:24:54 this is what i was afraid of ... deadlock until the other is resolved 20:25:00 * jaypipes recommends skipping until we answer the bigger questions. 20:25:00 Useless is a bit strong 20:25:13 Well, we could talk it through but defer our decision 20:25:17 ttx: the summary you'd issued from the November discussion on the topic "We would like to have Manila in OpenStack one day, needs more maturation, solve multi-tenant concerns and get devstack-gate integration before revisiting incubation request" 20:25:21 That gives scope for if we have questions which need time to answer 20:25:22 we need to move swiftly on the "big questions" so we don't leave all of these projects hanging though 20:25:24 well, bswartz, how much code is manila still sharing with cinder? are you copying stuff back and forth there? 20:25:25 that's not terribly fair to them 20:25:40 I do want to hear about cinder collab and so on 20:25:42 How about bswartz quickly introduces the recent progress they made, but we don't judge yet, and move tyo next topic ? 20:25:43 dhellmann: no, we don't copy anything -- the common stuff is in oslo 20:25:45 is jgriffith around? 20:25:55 So that he didn't come here for nothing ? 20:25:59 leftover overlapping code is gradually being removed and replaced with oslo stuff 20:26:03 bswartz: so after that initial fork, you haven't updated anything based on ongoing work? 20:26:03 yes, i'd love to hear about progress 20:26:47 dhellmann: no we're not messing with cinder code at all -- we have everything we needed from the original fork 20:27:00 bswartz: that's not a bad thing, I'm just trying to understand the split, because a lot of the application emphasized how similar the architectures of the two projects were, and I wonder if there should be more code shared 20:27:16 bswartz: how much duplication of code is there now between cinder and manila? and what portion of that should be oslo'ified in the fullness of time? 20:27:17 the only sharing we envision at this time is through oslo 20:27:24 we'll push to move more common stuff into oslo ofc 20:27:53 devananda, dhellmann, could ask the same question about cinder/nova 20:28:00 with all due respect, we've engaged on a number of occasions in the past and made major changes to Manila in response... in good faith. It seems poor form to change the game on us yet again. 20:28:15 the duplication is fairly low at this point -- mostly not we inherit the architecture, in terms of the services and their relationships 20:28:21 ok, well, oslo isn't the only way for you to share code if it's just the 2 projects using it, so I'm worried that the oslo team will have to agree to adopt something that the 2 teams could be managing together without us 20:28:22 mostly now* 20:28:27 markmc: yes, indeed 20:28:54 but it's good to know that oslo is on your radar, in any case :-) 20:29:07 as for a general update on our progress, we have many more vendor involved now, and even more asking about how to get involved 20:29:30 Do those vendor drivers all implement a similar level of functionality? 20:29:33 do you envision having third-party testing like some of the other vendor-heavy projects? 20:29:35 a good bit of work went into satisfying specific requirements (like the gate integration, docs, etc) late last year 20:29:36 How granular is the functionality in fact? 20:29:40 #link http://stackalytics.com/?release=all&project_type=all&module=manila 20:29:50 since then we've been working on new features and broader driver support 20:29:55 bswartz: Looks to me that https://github.com/stackforge/python-manilaclient's README is still referring verbatim to the cinderclient's README. Just FYI... 20:30:26 regarding third-party testing, we plan to replicate the approach cinder is taking 20:30:32 #link http://stackalytics.com/?project_type=all&module=manila&release=all&metric=commits 20:30:38 russellb, commits :) 20:30:41 cinder is hitting some bumps in the road and we're learning a lot for free 20:30:49 markmc: d'oh, i keep forgetting the default change 20:30:54 bswartz: curious, how well does the manila API abstract vendor differences 20:31:12 bswartz: have you considered at all what functionality to require as a minimum from drivers? That might save you some pain later. 20:31:19 bswartz: what third-party drivers are you including? what first-party drivers? 20:31:29 devananda: right now it does it very well because the API is quite lowest-common-denominator 20:31:29 markmc: oh yeah good point 20:31:37 wow, 79% from the top company 20:31:40 commits makes the project look a lot less diverse than i thought, though i think we've settled on that being primarily a graduation concern, not incubation 20:31:43 bswartz: nice. do you have auto-generated api docs? 20:31:57 as we add more cool features keeping the API abstracted will be a challenge but no more than the challenge cinder faces doing this 20:31:59 mikal: +1 20:32:15 dhellmann: drops to 72% in Juno fwiw 20:32:26 jeblair: the first-party driver we support is called "generic" and it's software only 20:32:34 it layers on top of cinder and nova 20:32:34 devananda: at the incubation request, our requirements for docs are only for contrib docs 20:32:44 bswartz: what shared filesystem does it use? 20:32:49 NFS 20:32:52 for third party drivers we have netapp and glusterfs in tree 20:32:55 devananda: would still like to know the answer, but just noting 20:33:02 jeblair: ext4 20:33:03 NFS for the generic driver 20:33:15 and NFS for the sharing 20:33:18 jeblair: nfs and cifs 20:33:24 actually cifs too 20:33:34 bswartz: does it provision its own nfs servers, like trove does for databases? 20:33:38 annegentle: if they aren't able to autogenerate docs eg. with sphinxcontrib-pecanwsme, it's going to be more challenging later to retrofit that 20:33:53 annegentle: but yes, i agree, not an incubation req 20:33:53 and we have several more 3rd party drivers in development or waiting for merge 20:33:54 jeblair: yes, depends on driver 20:33:57 devananda: yes 20:34:11 jeblair: yes 20:34:16 what's the mapping between VMs, cinder volumes, and NFS shares? 20:34:16 bswartz: why is glusterfs considered 'third party'? 20:34:36 russellb: designate had 68% in juno timeframe as well - http://stackalytics.com/?project_type=all&module=designate-group&release=juno&metric=commits 20:34:37 bswartz: could you link to the nice incubation requirements table you prepared? 20:34:38 well it's maintained by redhat 20:34:56 russellb: nova creates VM with our image where nfs and cifs are preconfigured and uses cinder's volumes as devices for shares 20:35:04 #link https://wiki.openstack.org/wiki/Manila/Graduation#New_Program_Requirements 20:35:08 ok, so a VM and volume created per share? 20:35:16 bswartz: thx 20:35:27 russellb: volume per share, VM not 20:35:39 russellb: VM per tenant network 20:35:42 k 20:35:46 makes sense 20:35:55 yep 20:36:15 vponomaryov1: thanks for jumping in with answers , I can only read/type so fast.. 20:36:50 OK, any more question for this first round ? We always do those reviews in two rounds fwiw, so this is not really special 20:37:06 fwiw, this still seems like useful functionality, and i'm hoping we can work through our growing pains without hurting the progress and momentum here 20:37:08 bswartz: glusterfs seems like a useful bit of free software to support; so i think what i'm trying to get a handle on is how opinionated manila wants to be... what's your criteria for 'third party' drivers vs internal support 20:37:13 I think it gets the elephants out of the room 20:37:18 russellb: agreed 20:37:39 we don't want to be opinionated about drivers -- that should be the admins choice 20:37:49 yep I think it's useful functionality 20:37:52 russellb: +1 20:38:07 as PTL my goal is the make the project maximally useful -- not to promote particular backends 20:38:21 agree this looks like a lot of promising progress, nice work 20:38:26 i'm also wary of another neutron -- where all the "real action" happens with proprietary hardware and there's very little support for a fully open source solution 20:38:28 From an architecture/position standpoint it seems to fill the same spot as Trove or Designate, provision useful base services 20:38:30 bswartz: what's your sense of vendor interest vs. user interest? 20:38:36 jeblair: ++ 20:38:38 jeblair: +1 20:38:39 jeblair: yeah that's sort of what I mean too... 20:39:00 annegentle: we're seeing a big spike in vendor interest, but user interest has been steadily high 20:39:11 bswartz: ok good to see correct order of cart and horse 20:39:13 so it's great to see nfs in there as the primary driver; i think exploring why glusterfs didn't make the cut will be interesting 20:39:14 user interest has greatly outweighed vendor interest to date. 20:39:17 jeblair: +1 20:39:20 bswartz: how are yhou planning to handle vendor differentiation? 20:39:32 bswartz: also you don't want to be another Cinder -- being the target of a zillion driver request is not that fun 20:39:43 annegentle, you know, that's a great question - I think user interest should be huge in this, but it isn't something other clouds offer ... 20:39:56 ttx: I actually think that's not unlikely, and we're prepared for it 20:40:06 annegentle, i.e. we can't just say "AWS has this and people use it a tonne" 20:40:23 markmc: right 20:40:32 annegentle, I've heard people say they'd love AWS to have something like this though, but that's just anecdata 20:40:33 markmc: yeah. I found quite a number of people that were regretiing that AWS didn't have this though 20:40:34 markmc, annegentle, bswartz: it's definitely the sort of thing we have often discussed would be useful in infra (putting on our "really big user" hats) 20:40:39 devananda: two types of drivers, where some, like gluster fs can not have network isolation 20:40:44 ttx: in some ways that's exactly what end users have asked of Manila though.... a single, abstracted API for provisioning of shared file systems. That almost certainly will invite vendor specific implementations behind it. 20:40:49 I wonder if we could get some sort of a question into the user survey about upcoming projects 20:40:55 vponomaryov1: i mean, where vendors want to add $special-feature 20:41:01 "which solve a real need you have?" 20:41:10 markmc: good idea 20:41:24 i feel like this has come up in conversations for me several times though 20:41:25 On the plus side we can follow the trail that the cinder project has blazed 20:41:29 but it's just a gut feeling, i don't have data 20:41:34 so i have a small concern about knock-on features, let me see if I can express 20:41:41 esker: users want the common abstraction, sure - 20:41:49 currently cinder is lagging nova for some pretty significant features 20:42:03 russellb, not saying lack of data is a blocker for me, have a gut feeling too - but could be easy to get and very interesting 20:42:03 esker: but vendors will want to differentiate, leveragign some $special $feature, to increase sales of their hardware 20:42:05 in the past we had things like scheduler improvements, db races 20:42:12 esker: and i'm curious how you plan to balance these two demands 20:42:12 markmc: indeed 20:42:18 markmc: our overview session at the atlanta summit on manila was standing room only - as one indicator of interest 20:42:26 currently it is the object model and rpc versioning 20:42:28 rcallawa: awesome 20:42:28 rcallawa, excellent 20:42:47 you still can’t upgrade cinder versions without restarting 20:43:01 so it seems that things go, make changes in nova, some get pulled into cinder 20:43:18 i’m concerned that since manila is a fork of cinder that adds another step in the trickle-down 20:43:20 timeboxing to 5 more minutes 20:43:21 devananda: Cinder is certainly instructive in this light... and it is ultimately a balance. I think it also makes sense to acknowledge that of course vendors will want to put their best foot forward. 20:43:28 vishy: manila is not as tightly coupled to nova as cinder is 20:43:36 vishy, conclusion? cinder should never have split out? more focus on cross-project/oslo sharing? 20:43:39 its not the coupling i’m concerned about 20:43:51 its that important features get pushed into nova 20:43:58 and then cinder gets them eventually 20:44:00 in fact manila attempts not to involve nova at all (although we do have plans to support attach-by-instance-id) 20:44:05 vishy: the fact that the manila team seems to have a better attitude about working on sharing via oslo makes me think that will be less of a problem with them 20:44:12 if you are waiting on cinder to lead the way then there is a longer delay 20:44:31 i guess i’m suggesting that they should attempt to pull things more quickly from nova 20:44:32 vishy: I don't think they depend on cinder though 20:44:35 like the object model 20:44:39 we're not waiting for cinder -- it's just a reality that they are about 2 years more mature than us and they hit problems earlier than we do 20:44:47 vishy: in my understanding they mostly use cinder as atemplate, rather han a fork 20:44:48 like filter_secheduler 20:44:50 etc. 20:44:50 vishy: yeah, I'd like that object code to go into the incubator next cycle to make that easier 20:44:50 ah, I see - well, good advice for manila folks there - if you're syncing new features (like object model) don't wait for cinder to adopt first 20:45:01 markmc: hmm... merge cinder back in to Nova then? 20:45:10 jgriffith: seriously? 20:45:15 markmc: thanks 20:45:17 i understand it was a template, but the reality is cinder often doesn’t know about improvements until nova makes tehm 20:45:22 dhellmann: fwiw, it was submitted before and denied :) 20:45:22 vishy: I've talked to dan about it, but we didn't get to it this time around 20:45:27 for example retry_on_deadlock was only just added 20:45:31 russellb: yep, that was me, and I've talked to dan about it 20:45:35 cool 20:45:46 russellb: just expect it to be fixed once it comes over :-) 20:45:55 heh, k 20:45:56 so concretely, my suggestion is parts of the code that were ultimately derived from nova 20:45:58 vishy: well, obviously adding another project (whichever it is) will increase the need for cross-project coordination 20:46:02 track nova directly for changes 20:46:14 vishy, ironically, if manila had started from scratch we wouldn't really ask about this yet the problem would be same/worse 20:46:20 like the db layer stuff, the object model stuff etc. 20:46:51 markmc: that is true, but might as well take advantage of the grandparent code in this case :) 20:46:53 vishy: oh, I see what you mean 20:47:05 vishy, yep, it's a good point 20:47:09 I see lots of oslo libs in the manila requirements already, which makes me happy. :-) 20:47:15 i think the point is, nova is leading several changes, and its better to be following that directly than following a follower 20:47:18 vishy: not intention to follow Cinder, but rather to learn from it given common heritage 20:47:31 cool 20:47:49 OK, we need to move on, we'll have another session on Manila in a future meeting. 20:47:58 thanks 20:47:58 thanks bswartz and esker 20:47:58 thanks guys 20:48:01 You can continue those discussions on the Manila incubation ML thread 20:48:17 which didn't attract so much comments until now :) 20:48:24 eglynn: around? 20:48:29 ttx: o/ 20:48:30 #topic Background information about Gnocchi project 20:48:35 #link http://lists.openstack.org/pipermail/openstack-tc/2014-August/000757.html 20:48:40 eglynn asked for some time to explain a few things about Gnocchi 20:48:46 ^^^ background on that ML thread 20:48:50 We don't have that much time left, but since Eoghan will be in vacation soon, maybe a quick mention here can't hurt :) 20:49:04 are there TC-level concerns? 20:49:07 yeah thanks for the opportunity ... 20:49:11 * markmc thought the mail was a nice summary 20:49:12 I'm timeboxing this to 6 minutes so that we have time to cover the other changes 20:49:15 markmc: ++ 20:49:16 well the intent is just to get TC folks caught up on what gnocchi is about 20:49:24 cool 20:49:26 thanks for the ML post 20:49:31 as there was an info deficit 20:49:47 yep, so the TL;DR is ... 20:49:57 gnocchi is an arms-length project from ceilometer, in which we're exploring one option to pay down some architectural debt 20:50:06 happy to answer any questions is there's time 20:50:22 So there are no plans to move to it at this time? 20:50:23 I did go into a bit more detail in the thread on what it is, and what it ain't 20:50:24 i'm still a bit confused on the scope overlap between Gnocchi and InfluxDB 20:50:27 Its still an experiment? 20:50:34 eglynn: did anyone look into existing time-series databases before implementing another one? 20:50:43 sounds like a nice way to try out a major improvement, without too much disruption to the project for now 20:50:44 eglynn: would it be fair to describe it as a branch that will eventually be merged back or not? 20:50:44 seems reasonable 20:50:48 there seems to be a layer that would be duplicated between them 20:50:48 and something we should encourage 20:50:56 mikal: timeline is kilo to swicth if it meets the grade 20:51:10 zaneb: yep that's fair 20:51:24 devananda: well we're not just reinventing 20:51:32 eglynn: how do you decide if it meets the grade? What's the process for that? 20:51:33 eglynn: "not jsut reinventing" ? 20:51:40 devananda: they can piggyback on a time-series DB, but yeah, it seems like they would reimplement some parts of it 20:51:40 eglynn: a summit session? 20:51:57 devananda: ... there's a pluggable driver model that allows us to plug in InfluxDB etc. as the backend 20:52:18 mikal: at the juno session, yes there was a session 20:52:42 mikal: https://etherpad.openstack.org/p/ceilometer-tsdaas 20:53:06 mikal: a-ha, you mean at the kilo summit? 20:53:34 mikal: yes the process would include performance profiling and ensure a semantic match in the API 20:53:36 The thread explains the sitiation pretty well, and it just gets started 20:53:55 eglynn: ok, cool 20:53:59 so I think discussion can continue there 20:54:00 eglynn: that's what I was asking about 20:54:00 I'm still very unclear as to why a new time-series anything needs to be written 20:54:06 eglynn: I'm sure there's a reason why gnocchi didn't work with trove to provision influxdb instances? 20:54:09 mordred: as am I 20:54:38 gnocchi is also partially a response to all of the complaints about operators having to learn yet another new service, since can use swift for storage 20:54:52 mordred: sandy raised a similar question on the ML, and I go into more detail there on the additional semantics 20:55:09 eglynn: ok. I'll go read that before I dive in more 20:55:10 yeah, I think the discussion can continue tere, we won't solve it in 4 minutes 20:55:10 mordred: (i.e. above and beyond pure timeseries storage) 20:55:18 but it seems very much like a description of carbon 20:55:22 Thanks eglynn 20:55:32 mordred: apparently the carbon code is really ugly 20:55:35 which already exists and is in use at massive scale around the world and is in python 20:55:38 *meh* 20:55:52 that's clearly not stopped us before 20:55:52 works > pretty :) 20:55:54 ugly code is not a reason to write a new thing 20:56:08 russellb, mordred: ++ 20:56:17 well, from the perspective of it not quite doing what we want and also being hard to change, it might be 20:56:19 mordred, we could give the program the benefit of the doubt that they're not NIH for the sake of it 20:56:43 yes, i think we should assume good faith on that ... but a summary about what was considered and why it didn't work out would be good 20:56:44 markmc: no, I don't think we have very good track record with that overall aroudn here 20:56:57 I don't assume bad faith 20:57:04 I feel like at this point we should let gnocci do its thing, and then ask for a merits based comparison with other options before its baked into ceilometer 20:57:17 russellb: I can dig out more detail on jd__'s analysis of the fit with carbon 20:57:21 Its not really fair comparing a half done thing with a finished thing 20:57:27 eglynn: sounds like that'd be helpful 20:57:29 agreed, i think we need to ask these questions, if for no other reason than people may simply not be aware of all the options. we have things to offer other than just being grumpy. :) 20:57:31 russellb: cool 20:57:36 mikal: I DO think it's fair 20:57:38 mikal: fair point 20:57:49 mordred: I'm not sure that's true, although we definitely don't have a good track record of communicating why something is not NIH 20:57:51 jeblair: we got quite a lot of both at the summit in atlanta :-) 20:57:52 it's not comparing gnocci with carbon 20:57:56 my only suggestion is the tsdb portion be one project and the abstraction layer be another (gnocchi proper) 20:57:58 it's comparing carbon to requirements 20:58:04 mordred: it sounds like other options were considered before they went down this path 20:58:08 mikal: and if that thing is intending to a substantial part of an integrated project, then I think it's worthwhile for us to get involved if we're going to be on the hook for maintaining a thing 20:58:16 mordred: I think we should leave second guessing them until they're done with their counter proposal 20:58:33 OK, let's continue that discussion (1) on the thread and (2) at the special meeting 20:58:38 mikal: it also sounds like they weren't aware of influxdb at the time 20:58:41 mikal: ok. I'm just saying, I do NOT think we need to wait until the thing is finished to have discussions about whether doing the thing is a good idea 20:58:53 I'll use the last minute to cover the housekeeping changes 20:58:56 mordred: ++ 20:58:58 (i wasn't either -- that's not a judgement, just an illustration of why asking and discussing options early is good) 20:59:02 #topic Other governance changes 20:59:07 * Move DevStack to QA program (https://review.openstack.org/112090) 20:59:09 jeblair: ++ 20:59:14 jeblair: InfluxDb is pretty new in fairness, but the discussion with the Influx devs started in ATL at the same time as gnocchi 20:59:14 It looks like we are hugely in favor, but it needed a rebase last time I looked 20:59:30 which was posted... so please reapprove 20:59:38 * Add oslo.serialization to Oslo program (https://review.openstack.org/112996) 20:59:43 This one now has dhellmann +1 so should be good to go, unless someone objects now 20:59:48 * Add oslo.middleware to the Oslo program (https://review.openstack.org/112395) 20:59:54 Same for this one, will approve after meeting unless someone objects now 20:59:59 * Add repository glance.store to glance (https://review.openstack.org/107585) 21:00:05 This one is still missing Glance PTL's +1, markwash is in vacation right now 21:00:10 #topic Open discussion 21:00:18 And as usual, no time left for open discussion weeee 21:00:45 * ttx could do with a meeting that finishes early 21:00:56 too late :) 21:01:03 * dhellmann invites ttx to the oslo meetings 21:01:24 OK, so we'll all see each other on Thursday, 19:00 UTC on #openstack-meeting-3 21:01:27 well maybe we can try for thursday's to end early :) 21:01:33 markmcclain: haha 21:01:38 unlikely. 21:01:39 #endmeeting