| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-06 | |||
| 21:13:46 | alexandrelevine | And such... | |
| 21:14:06 | jgriffith | alexandrelevine but the Cinder approach would require handling all of those for ALL backends no? | |
| 21:14:08 | mriedem | how do 3 and 4 not get handled by cinder and os-brick? | |
| 21:14:13 | jgriffith | with the exception of #3 | |
| 21:14:50 | alexandrelevine | It would take some design decisions, communications between interested parties, talks, reviews, etc. With the usual round-trips for all of this, realistically, it's 2-3 releases at the best. Of course if it was all in one organization it could've be done in month or two. But that's not the case. | |
| 21:14:55 | mriedem | for #2, wouldn't live migration and resize work the same as for boot from volume? | |
| 21:15:51 | alexandrelevine | jgriffith: Abouth the #4. I'm not sure. It might. But most probably it won't. | |
| 21:16:10 | jgriffith | alexandrelevine well I don't think that's necessarily true, I certainly hope not | |
| 21:16:24 | jgriffith | I'm honestly hoping that this is something that we can somehow pull of in this cycle | |
| 21:16:39 | jgriffith | otherwise I'll go back to pushing my flavor-extra-specs proposal and forget all of it :) | |
| 21:16:43 | jgriffith | alexandrelevine so seriously... | |
| 21:16:57 | jgriffith | alexandrelevine I get where you're coming from and I understand you've already invested a lot perhaps | |
| 21:16:58 | jgriffith | BUT | |
| 21:17:02 | alexandrelevine | jgriffith: There is a number of different disk types in nova - local/root/config/volume - some of which are intermingled with other. So I'm not sure that mapping/unmapping would be enough to be done outside. Probably but not necessarily | |
| 21:17:17 | jgriffith | I think it's fundamentally WRONG to continue doing all these one offs for just one particular vendors interests | |
| 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? | |