Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-06
21:17:31 jgriffith especially if/when we all have a common interest in achieving the same thing
21:17:48 jgriffith why not utilize your resources and efforts to better the entire project and not just your product?
21:17:55 alexandrelevine jgriffith: They honestly hoped that they'd pull the refactoring in 1 month. It still goes. And that's exactly same area with the same problems.
21:19:00 mriedem alexandrelevine: i don't remember anyone claiming the entire imagebackend refactor what mdbooth was doing in newton would be done in a month
21:19:02 alexandrelevine jgriffith: Our stuff is already done and ready. New thing - is a significantly much more work for us.
21:19:05 jgriffith I've had the same debates in Cinder WRT other things EMC has proposed (VIPER, CPRHD...) so while I sympathize I can say that you're very unlikely to change my opinion on this
21:19:13 alexandrelevine mriedem: I remember
21:19:14 jgriffith others have tried for years :)
21:19:28 alexandrelevine mriedem: We were told that it'll be done by June and then we'll add our code.
21:20:45 mriedem anyway, that effort derailed and we talked about it in BCN, and it's not being worked now i don't think,
21:21:00 alexandrelevine jgriffith: At the moment people which added ploop as I know proceed with changing the code. I'd suggest to let ScaleIO in along with starting the work on cinder backend. This way people would get the only really competing to ceph storage backend soon. Otherwise - time is indefinite.
21:21:09 jgriffith alexandrelevine lucky for you I carry no weight on the Nova team, but honestly I think it'd be irresponsible to move forward with a one-off solution as opposed to workign on a generalized approach
21:21:16 mriedem and what i'm hearing is, adding a generic cinder driver is going to be hard because the code is a hot mess, and because the scaleio work has been going on for over a year, you've dealt with that mess
21:21:59 alexandrelevine mriedem: Yes. And as I said I dealt even more with that mess when I proposed the POC for that same refactoring so I think I correctly estimate the picture.
21:22:00 mriedem so rather than start over on the hard thing that everyone wants, add another special backend and all of the conditionals that go along with in the libvirt driver code
21:22:06 sdague cburgess: just for you - http://docs-draft.openstack.org/03/441203/8/check/gate-keystone-specs-docs-ubuntu-xenial/923ac60//doc/build/html/specs/keystone/backlog/hierarchical-quota-scenarios.html#make-chet-sad-model
21:22:35 mriedem alexandrelevine: i also don't really see what motivation your team has for maintaining this once it's in tree unless you're getting paid to maintain it
21:23:14 alexandrelevine mriedem: Me neither. But we're doing it right now. Maybe we just don't like to drop what we're responsible for.
21:23:48 alexandrelevine mriedem: And part-time participation is not such a big load on us comparing to, say, a full month work.
21:23:50 mriedem alexandrelevine: i can see that, i worked on getting db2 support into nova for 2 years, and then we ripped it out about 6 months later because ibm stopped supporting it upstream
21:24:18 mriedem however, i'm not trying to get db2 back into nova
21:24:28 alexandrelevine mriedem: Don't mind if we rip ScaleIO out in favor of ready cinder backend even a week after. It just has to work.
21:24:50 jgriffith alexandrelevine honestly I would've thought based on your statements you'd prefer the general cinder driver approach.
21:24:56 mriedem alexandrelevine: removing things is harder than just adding them in and letting them rot
21:25:05 alexandrelevine mriedem: I just fill sort of responsible for the unfinished solution and we don't have much resources to keep patching it aside - it's even more work.
21:25:07 jgriffith alexandrelevine you already stated you don't have resources to work on / maintain the effort
21:25:12 mriedem jgriffith: i'm sure they do, but they don't favor the investment in doing the new thing, or waiting for it
21:25:26 jgriffith alexandrelevine you know as well as anybody that this code isn't static
21:25:38 mriedem alexandrelevine: if EMC cares about it, then xing-yang's team would own rebasing it shouldn't they?
21:26:00 jgriffith mriedem ahh... well; I don't favor this option either, but I'm willing to try it to do something that better satisfies everyone involved
21:26:12 alexandrelevine jgriffith: Architecturally - absolutely. We even discussed when we designed the solution. But knowing the problems we decided to go for smaller, more safe thing. Thinking that it'll be much less time, especially after verbal confirmations.
21:26:28 mriedem jgriffith: which option? add the scaleio driver in until the generic driver shows up and then remove the scaleio driver?
21:26:37 alexandrelevine mriedem: exactly
21:26:43 jgriffith mriedem flavor :). Just ignore that
21:27:12 alexandrelevine mriedem: They don't have sufficient expertise to start new thing at the moment but to help support ours - it's possible.
21:28:50 mriedem but again, you no longer work for EMC and while it's nice you say you'd support it anyway, i don't see that happening in 6 months just from a purely motivational aspect, which is why i'd think that if EMC cares about this they'd have people backfilling your team to support this
21:29:06 jgriffith alexandrelevine wait... you're saying Xing's team doesn't have the expertise? I'd argue strongly against that statement
21:29:18 alexandrelevine jgriffith: By the way - this code is quite static, by the way :) Any attempts in refactoring have failed as I understand.
21:29:39 alexandrelevine mriedem: They do.
21:30:23 jgriffith alexandrelevine here's the thing... I want this feature as per customer requests for SolidFire
21:30:24 alexandrelevine mriedem: They care about this direction. But I said that we'll finish because any new guys would take time to get into the code and the nova procedures and processes so again 2-3 more releases at the best.
21:30:54 jgriffith alexandrelevine so if you go this route, then that means I go this route... then Pure does the same, then <insert-1-of-100-cinder-backends-here> go this route
21:30:56 jgriffith that's stupid
21:31:17 jgriffith Sure, it'd be easier for me to do it this way too, but that doesn't mean it's a good idea
21:31:19 alexandrelevine jgriffith: You can call it stupid, but that's reality.
21:31:41 alexandrelevine jgriffith: I wouldn't recommend to go the same way again now that everybody is pro universal backend.
21:31:43 jgriffith alexandrelevine wait.. to be clear, I'm saying if we had 100 backends image drivers in Nova that would be stupid
21:31:47 jgriffith not what you're doing is stupid
21:32:09 alexandrelevine jgriffith: I'd suggested to start with it. It's about the same amount of work. No need to create SolidFire specific piece.
21:32:21 jgriffith LOL
21:32:32 alexandrelevine :)
21:32:34 jgriffith so it's no good for you, but good for everyone else :)
21:32:38 mriedem to be clear, i'm not going to support 100 cinder drivers in nova
21:32:47 jgriffith mriedem no? Damn!
21:32:51 mriedem which is why we want to stop doing this
21:32:56 jgriffith mriedem +1
21:33:06 jgriffith mriedem and that's why I never even bothered trying to go down that path
21:33:09 mriedem because i'm sure veritas is wanting the same thing
21:33:23 mriedem veritas has been pushing specs for the same stuff
21:33:34 alexandrelevine Guys I totally agree with stopping doing it. I'm just saying that if you stop BEFORE Scaleio is in it means that it'll be out for 2-3 more releases.
21:34:16 alexandrelevine I tell you what. We can even consider doing or helping doing the cinder driver in nova.
21:34:31 alexandrelevine Because it's interesting and we're quite into it.
21:35:10 alexandrelevine But not as a replacement for now-ready ScaleIO. In more relaxed schedule and if Randy approves because we still work with him.
21:35:24 jgriffith Randy?
21:35:29 alexandrelevine Randy Bias.
21:35:57 alexandrelevine Basically almost all of our efforts in OpenStack are his ideas.
21:36:03 dansmith lol
21:36:27 alexandrelevine He might approve by the way if he sees that it's really needed.
21:38:05 jgriffith alexandrelevine ok, so look from my perspective; it's the wrong direction.
21:38:21 jgriffith alexandrelevine I feel for ya in terms of investment etc but my vote is generalized solution
21:38:28 jgriffith alexandrelevine I'm sorry about that
21:38:54 mriedem alexandrelevine: jgriffith: i was mostly looking for input on the specific issues that are going to delay the cinder backend,
21:38:59 alexandrelevine jgriffith: generalized solution with "no" for the specific one for now?
21:39:03 mriedem alexandrelevine: i'm not asking your team to write that code,
21:39:04 jgriffith but it's the right thing to do in terms of the overall project and it's the "fair" thing to do in terms of vendors and MOST OF ALL it's the right thing to do in terms of cloud deployers
21:39:21 jgriffith alexandrelevine correct, no specific drivers
21:39:23 mriedem but we obviously need to start with a spec and detailing the issues that are going to be hit with this will help give a better idea of how long and risky that's going to be
21:39:53 jgriffith alexandrelevine I sincerely would hope you and your team would help in the effort given you have vast experience and interest
21:40:02 alexandrelevine mriedem: You did that with imagebackend refactoring. Did it help you to predict 1.5 years and failure in the end?
21:40:18 jgriffith but if you can't/don't then that's ok too; doesn't change my opinion
21:40:49 alexandrelevine mriedem: What if you spend 2 months on the spec and find it risky and difficult or just difficult and taking 2-3 more releases?
21:40:52 mriedem i don't have enough info to make a judgement call on whether or not we should take on the technical debt for the backend that may or may not be supported, unless i have a better understanding of how hard it's going to be to get the cinder driver done
21:42:00 alexandrelevine mriedem: What I'm saying is that the question is - when did you get clear and correct specs of that complexity in this area? I'm again referring to the refactoring spec/specs.
21:42:20 alexandrelevine Ours is good because we have the code which works for 1.5 year already.
21:42:55 alexandrelevine mriedem: Who'll right such a spec? Who has a thorough enough expertise?
21:43:00 mriedem alexandrelevine: the imagebackend refactor failed for different reasons
21:43:13 alexandrelevine "write"
21:44:26 alexandrelevine I just want to remind that in order to provide my design ideas for refactoring I had to develop the whole solution and make it pass all of the existing tests. Then I was sure that my ideas would work and I was ready to write a spec.
21:49:59 alexandrelevine mriedem: Please let me know when the conversation is finished and you made up your mind with some verdict because it's 0:49 am here and unless we keep talking I can go and get some sleep.
21:51:28 mriedem alexandrelevine: i think i'm done right now. i'm not ready to add the scaleio specific driver without having a better idea of how the generic driver would happen (or not happen).
21:52:41 alexandrelevine mriedem: Ok, thank you. Do we abandon our spec or just leave it be?
21:52:56 mriedem alexandrelevine: i'd leave it for now
21:53:12 alexandrelevine Ok. Bye.
22:29:16 mriedem jgriffith: dumped my recap notes on the talk with alex in https://review.openstack.org/#/c/304715/
22:41:44 mriedem dansmith: i moved your nova meeting stuff on the forum planning into the reminders section since it's something that will probably continue to come up as we get closer
22:41:51 mriedem like for the ptg planning
22:41:52 dansmith mriedem: cool
22:51:45 ildikov mriedem: hi, are you around for a quick question?
22:52:34 mriedem ildikov: i am
22:52:42 ildikov mriedem: tnx

Earlier   Later