17:00:08 #startmeeting cinder-nova-api-changes 17:00:10 Meeting started Mon Jul 11 17:00:08 2016 UTC and is due to finish in 60 minutes. The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:14 The meeting name has been set to 'cinder_nova_api_changes' 17:00:21 scottda ildikov DuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr ebalduf patrickeast smcginnis diablo_rojo gsilvis 17:00:29 * johnthetubaguy lurks 17:00:39 hi 17:00:40 o/ 17:00:48 hi 17:02:01 I have only a few topics to follow up on today 17:02:20 I started to add tests to jgriffith's new API calls 17:03:08 Cinder tests are tricky, that's my major take from last week, so I might annoy a few people this week to get better progress 17:03:37 annoy away 17:04:15 scottda: it took me two days to find the policy.json file under the unit tests folder 17:04:46 scottda: and then I got another error in the tests, so I thought to take a short break on it... :) 17:05:05 review: https://review.openstack.org/#/c/339692/ 17:05:06 ildikov: Well, feel free to ask for help. don't wait 2 days. 17:05:30 scottda: I was debugging, although I had other things to do as well 17:05:59 scottda: the follow up error, if you have any idea please ping me: http://logs.openstack.org/92/339692/2/check/gate-cinder-tox-db-functional/25e216f/console.html.gz#_2016-07-08_17_46_59_572403 17:06:28 jgriffith: if you have some time to check I would be happy to get feedback ^^ 17:06:32 ildikov: I'll have a look in a little while.. 17:06:40 scottda: cool, tnx 17:06:58 the other thing I played with is the check_attach removal 17:07:20 #link https://review.openstack.org/#/c/335358/ 17:07:57 I added an extra reserve_volume call into the flow as that was missing, I'm not sure it's the right place though 17:08:22 mriedem: johnthetubaguy: if you have any feedback on the above please comment on the review or ping me ^^ 17:08:54 isn't that a duplicate of one of hemna's changes 17:08:55 ? 17:09:01 Grenade is failing, the change looked working locally, although I haven't tried all the scenarios 17:09:19 mriedem: it's a follow up patch that actually removes check_attach to see what goes wrong 17:09:39 mriedem: hemna's current patch splits check_attach and check_availability zone 17:09:45 oh i see 17:10:27 back 17:10:28 hey 17:10:36 hemna: hey 17:10:40 I've been distracted by several things lately 17:10:50 sorry I haven't gotten back to the check_attach yet 17:11:01 hemna: I mentioned I uploaded a follow up patch on your check_attach changes 17:11:14 but yah my old patch split out the check_az stuff out of check_attach 17:11:21 as that still seemed useful on the nova side 17:11:31 since Cinder doesn't support that with reserve yet 17:11:38 hemna: Greande is still failing on it, plus I need to resolve the merge conflict it's in currently 17:11:44 :( 17:11:45 ok 17:11:56 I might be able to help some today or tomorrow on it. 17:12:11 I've been trying to get my os-brick refactor done with kendall 17:12:14 hemna: I will deal with the merge conflict today 17:12:30 I'm in trouble with where to put reserve_volume in the BFV flow 17:12:57 as it's not called there, so I added it in my patch, but I'm not sure at this stage that's the right place for it 17:13:43 is there any relevant parts of the os-brick refactor to our topics here? 17:14:01 yah, I think that's where I got stuck too 17:14:07 the BFV is buried 17:14:31 nah, the os-brick refactor is to simply break out all of the connectors from connector.py 17:14:44 it's too big now and is a pita to maintain. 17:15:06 have had problems with circular deps and figuring out how to not break compatibility 17:15:12 but I think I have it figured out. 17:15:21 https://gist.github.com/WaltHP/230dc7f0bfa33981f052b9987d2d566e 17:15:23 lots of change 17:15:36 johnthetubaguy: mriedem: it's the part with the new reserve_volume call: https://review.openstack.org/#/c/335358/3/nova/compute/api.py 17:16:07 hemna: oh, nice 17:16:19 hemna: big +1 one for better maintainability 17:19:49 next week is mid-cycle week, where we have a slot to discuss Cinder-Nova topics 17:19:52 where do we want to get to for the midcycle? i've been focusing on nova non-priority bp FFEs the last 2 weeks so haven't been back around to jgiffith's nova POC 17:20:44 mriedem: regarding the Nova part I would like to see how the new API fits with all the VM operations Nova has 17:21:01 I haven't had time to look at jgriffith's new cinder api 17:21:06 but I liked the direction it was going 17:21:15 honestly, I think that's what cinder needs asap 17:21:20 and has for a long time. 17:21:39 I'd like to get code up to microversion the new cinder api in jgriffith patch 17:21:40 just have to make sure that live migration works 17:21:45 hemna: jgriffith: can we sort out this week whether there is anything because of which it would not work out? 17:21:46 that's always been the problem child 17:22:09 scottda: +1, that would be really good as a starting point for Nova POCs 17:22:25 I wish cinder had an experimental tag for APIs re: manilla 17:22:43 honestly live-migration is a good thing to worry about, if that works, we are probably in a good place 17:22:45 hemna: yeah, that's one of the most problematics, but there are other hacks as well I think 17:23:20 johnthetubaguy: +1 17:23:29 yah 17:23:31 hemna: We've discussed experimental APIs in the past...I could write the code if the community wants this. 17:23:43 hemna: Maybe re-discuss at the mid-cycle 17:23:45 that's what I always tend to focus on first, as I've had a lot of issue with it over the last few years. 17:23:45 last week there was talk of a devstack patch or something to test the cinder api / cinderclient / nova poc together, did that happen? 17:23:58 scottda, yah it's worth talking about 17:24:12 I think the experimental API is the place for the new api for now 17:24:14 scottda: the early micro-version specs had that, but it was largely rejected, because folks start using them too easily 17:24:31 scottda: deep down, I still think we need something 17:24:55 scottda: do you know whether the Devstack patch got any progress or not before you went on vacation? 17:25:14 I agree. Many people balked because they figured we must continue to support the experimenal APIs, even though they are experimental 17:25:32 ildikov: NO, I didn't work on that. I thought jgriffith was, I sent him a pointer to an example. 17:25:54 scottda: ok, thanks, I will ping him later to see where we are on that 17:27:08 hemna: scottda: is this new API experimental in the way we think we will probably drop it or would microversion be enough to give a stable base to people and get them switch when this new thing actually works? 17:27:55 ildikov: not sure. It'd be nice to start with experimental. 17:28:05 I would hope that we could tag it experimental, give us a release to test it out 17:28:07 and make changes 17:28:16 I think if we start with microversion, you cannot go back to experimental 17:28:20 and then once it's good, move it out of experimental and microversion it. 17:28:49 I just don't want to get into the state we were with multi-attach 17:28:56 meaning, we wouldn't let code land in cinder 17:29:01 because nothing in nova was going to land 17:29:04 how we can add changes in Nova with an experimental API in Cinder? 17:29:05 chicken-egg 17:29:28 well, we could have a patch in nova that gets tested 17:29:31 we had this with get me a network with neutron 17:29:33 against the experimental 17:29:34 but that was really a new thing 17:29:41 neutron landed the api in mitaka 17:29:46 I mean I guess Nova would be the component that actually tests this new API on the first place 17:29:48 and then once everyone is happy with it in nova, and it's passing all the important CI's 17:29:50 nova started using it in newton, found some bugs, neutron fixed those 17:29:55 then we can change the Cinder side 17:30:12 and then merge the nova side once cinder moves experimental -> microversion 17:30:50 mriedem: I think we could use that here as well 17:31:17 I mean I'm not sure how much we expect others to pick up the new API besides Nova immediately 17:31:44 but I might be wrong, I'm happy with experimental tag as well if we think we can get progress with that in Ocata 17:31:45 Just FYI, manila has all api's microversioned, even if experimental 17:31:51 unless we think that's too complicated 17:32:04 since this is a new thing, I'd like to make sure this is tested well 17:32:23 scottda: you mean they microversion it as the normal API they just tag it that it still might not be completely stable? 17:32:30 the cinderclient extension would use it as well (for bare metal attach) 17:33:02 * bswartz lurks silently ¬_¬ 17:33:20 hemna: +1 on that as well, although I don't think we can land code in Nova without proper testing anyway 17:33:27 ildikov: What Manila does is use an HTTP header for exerimental 17:33:52 ildikov: And you cannot access that api unless you include the header 17:34:13 scottda: ah, ok, that makes sense 17:34:34 https:/cinder-endpoint/blahblah -H experimental -H openstack-api-version: volume 3.27 17:35:33 scottda: cool, tnx for the clarification 17:35:44 brb 17:36:13 hemna: scottda: what I would like to see is that whether it's experimental or only microversioned we should get the API working in Cinder in Newton 17:36:17 can't we test this with depends on? 17:36:35 hemna: scottda: I would like to have code for Nova in Newton as well to really start testing 17:36:40 we will need new and old in Nova anyways, so we support older cinder during the upgrade 17:37:10 johnthetubaguy: when the Devstack patch is up that allows us to get the client code changes as well it should be fine I guess 17:37:31 oh, client... I don't think we install that correctly 17:37:38 i.e. not from git 17:37:42 johnthetubaguy: that's right, we cannot really delete code just deprecate 17:38:20 johnthetubaguy: I got educated two weeks ago that Devstack can be configured to install it form source 17:38:40 yeah, I think we can make it do that, its just not what normally happens 17:38:56 so we might need to depend on a devstack hack that turns it on 17:38:59 but thats all fine 17:39:14 johnthetubaguy: yeap, that's what mriedem asked earlier whether we have patch for that already or not 17:39:23 ah, sorry, missed that 17:39:30 mriedem is good at those tricks 17:39:48 :) 17:40:30 if the devstack patch doesn't exist yet i can make that happen 17:40:49 mriedem: I don't believe it exiss 17:41:11 mriedem: I don't think either 17:41:26 i'll try to wip something up 17:41:52 mriedem: tnx! 17:42:51 BTW does it make sense to have this meeting next week or everyone will be travelling already? 17:43:14 skip 17:43:34 I won't be traveling, since I'm hosting. But everyone else probably will in Cinder. I say sip 17:43:57 ok, I will cancel it then 17:44:30 do we want to have any agenda brainstorming now for next week or let it happen during the week? 17:44:59 I think we can fill it in on the respective etherpads for the mid-cycle 17:45:23 i've already started putting some links in the nova etherpad 17:45:37 ok cool 17:45:52 mriedem: Do you have a link handy for that? 17:45:55 I hope we can get some further progress with a few items this week 17:47:17 scottda: https://etherpad.openstack.org/p/nova-newton-midcycle 17:47:59 I presume nova will have to support the older API for a while ? 17:48:13 thx 17:48:18 what is the official policy on keeping nova and cinder in lock step ? 17:48:30 meaning Nova newton vs. Cinder Liberty ? 17:48:44 it's theoretically possible 17:48:45 hemna: i don't think there is an official policy, but the unofficial is probably whatever we test 17:48:49 well, not even test 17:49:01 but yeah, probably whatever is still supported/maintained upstream 17:49:06 so master nova / cinder stable/liberty 17:49:42 so I presume that means Nova has to support the older API until Newton is the oldest supported version. 17:49:42 hemna: will the old Cinder calls be deprecated? and if yes, when? 17:50:06 hemna: i'm not even sure about that 17:50:12 ildikov, since we are microversioned, I don't think Cinder can remove the existing APIs 17:50:13 we are just starting to get to deprecating APIs 17:50:20 but we do the deprecation in a microversion, 17:50:25 yah I was just wondering out loud about it all 17:50:27 which means we still support the API below that microversion 17:50:40 we can only remove a deprecated API if we bump the minimum required microversion 17:50:47 which is a long way in the future, if we do it at all 17:50:50 I think we are bad citizens if we ever remove support for the old api 17:51:16 yah I think we are a long ways off 17:51:26 sure, but at least we should encourage people to use the new APIs and not enhance further the old ones 17:51:54 here I think we have a better situation as I would guess the user of the current/old Cinder API is mostly Nova 17:53:56 anyway, I'm not saying we should not support the old API, but we should somehow avoid workarounds that are built on it in the future if possible 17:55:06 probably not worth digging into this in this meeting, this meeting doesn't need to go an hour each week just because :) 17:55:10 talk about it at the midcycle 17:55:24 i wouldn't get lost in that discussion before the new API is a serious thing to land 17:55:43 something something chickens and eggs being hatched 17:56:09 sure, you're right, but I better see people excited about this :) 17:56:41 as said, do we have anything else to discuss for today? 17:57:24 nope 17:57:38 not I 17:58:19 ok, then thanks for today and talk to you next week! :) 17:58:31 bye 17:58:39 #endmeeting