18:00:38 #startmeeting ironic-v2-api 18:00:40 Meeting started Tue Jul 26 18:00:38 2016 UTC and is due to finish in 60 minutes. The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:43 The meeting name has been set to 'ironic_v2_api' 18:00:45 anyone around? 18:00:53 should be a short one 18:01:08 o/ 18:02:43 hey rpioso 18:02:51 hi jroll 18:03:15 * jroll waits a few minutes to see if others are around, and pings the channel 18:03:35 o/ 18:05:40 ok, quite the crowd :D 18:05:46 #topic announcements / reminders 18:05:51 I have nothing, anyone else/ 18:05:54 ? 18:06:25 so I was supposed to do a formal writeup of problems with the existing API, but I didn't get around to that 18:06:29 I should have it for the next meeting 18:06:53 also, the nova folks at the midcycle last week wanted to hear more about this work 18:07:03 we kind of went through some of the things we were intending to solve 18:07:31 they asked why we couldn't just do all of this in the v1 api via microversions, and eventually raise the minimum 18:07:50 which seems functionally equivalent, as far as versioning and dropping things goes 18:08:09 the catch is if we want to change frameworks, if that will necessitate a v2 - I'm not sure it does 18:08:20 so that's one thing to think about while we work on this 18:08:43 if we can do it all in a v1 context without making life too hard, that would be nice 18:08:55 * devananda sneaks in the room, late 18:09:28 one other thing: they noted that while an all in one "deploy" endpoint would be nice for users, they're considering parallelizing bits of spawn() (e.g. volumes, networking, image downloads, etc) 18:09:41 so we definitely want to still be able to do single pieces at a time 18:09:43 devananda: welcome :) 18:10:14 jroll: good summary so far :) 18:10:20 jroll: perhaps v1 APIs could be adapted to a new v2 framework 18:10:22 isn't one of the reasons we want a v2, is to delete some of the existing v1 API? 18:10:42 rloo: right, which we can effectively do by raising the minimum microversion 18:10:49 or can we delete some apis with a microversion. 18:10:56 rpioso: yeah, that's what I'm thinking :) 18:11:14 rloo: we can, but that doesn't help eliminate the code or needing to think about those APIs 18:11:45 so that'd be why we want a v2. 18:12:04 * rloo doesn't want to think about v1 API if we have a newer API. 18:12:30 rloo: we won't be able to remove the v1 api for a while, even if we add a v2 18:12:42 well, so that's the thing - if we do these changes in the v1 API, and then eventually raise the minimum to 1.50 (for example), it's effectively the same, right? 18:13:26 jroll: I'm not sure it is 18:13:43 we should think of it from the user's point of view and what v1, v2 means. 18:13:55 seems like something to ask the api folks. 18:14:01 devananda: assuming 1.50 is where we drop the cruft? 18:14:09 i mean, as developers, we can do *anything* :) 18:14:35 rloo: we're magical like that ;) 18:14:38 rloo: indeed, cdent wanted to help with this (and brought up some of this last week), but is traveling today 18:14:49 if we were to build a v2 api in parallel, with a new framework, etc, the development process would be quite different, I think 18:15:05 than if we incrementally add & remove features from v1 using microversions 18:15:14 sure 18:15:26 whatever we do, i don't think we want to incrementally add/remove features? 18:15:43 rloo: that was, essentially, what hte nova team suggested 18:15:49 i mean, we want the new shiny whatever available. all available. 18:15:51 to incrementally evolve the v1 API to the point we want it 18:16:02 then drop backwards compat support by bumping hte minimum version 18:16:05 devananda: one of my fears with that model is, waiting to land the v2 api until everything is 'perfect' (read: never) 18:16:36 i don't like the incremental evolution. it partially depends on the end/new API though. 18:16:37 otoh, we won't have merge conflicts and such 18:17:03 rloo: what don't you like about it? 18:17:05 would it make sense to propose what the new API would look like, then see whether it makes (better) sense as v1 or v2? 18:17:28 jroll: if the api 'model' is different from the existing model, then having both as v1 is confusing to the user. 18:17:42 got it 18:17:46 jroll: eg, it would be like having the ironic CLI and OSC plugin being 'the same' based on some versioning. 18:17:46 jroll: while I share that concern, I also see the flip side: having a separate API would allow us (devs) to build it without impacting the current API (dealing with merge conflicts, adding a lot of backwards-compat code, etc) and allow deployers to run both 18:18:02 rloo: yes, that would make sense, and I think that's what I'm proposing. I don't want to make a decision yet, but it's something to consider 18:18:14 jroll: that has downsides too -- look at keystone for an example where folks have, after years, still not widely deployed keystone v3 API 18:18:21 just wanted to summarize the discussion here 18:18:23 devananda: indeed 18:19:00 it'll take some thought, and I think we need to define what the new API semantics look like, and probably play with code both ways, before we can make a decision 18:19:01 I'm not currently advocating for anything specific, justbrainstorming the pros and cons of each 18:19:11 yeah 18:19:13 ++ 18:19:18 having a clearer idea of what end goal we want to reach will help 18:19:24 ++ 18:19:46 if it's radically different from the current API (I think it will be), we should do the exercise of planning out how to incrementally get there 18:20:27 yep, agree 18:21:37 I'm going to move to open discussion since we're not really on a topic anyway 18:21:40 #topic open discussion 18:21:53 anything else on that topic? or other things folks want to talk about? 18:22:40 sure, i've got a question 18:23:16 since we're talking about a plan that hinges on being able to raise hte min API version, I'd like to ask ya'll -- when do you feel that will be warranted / OK ? 18:23:40 I don't think anyone has yet laid out the circumstances in which we'll ever raise that, or how we'll handle it 18:23:47 that's a great question, and I think I'd want to see a mapping of cycle:version to answer it well 18:24:11 but I don't think it's crazy to give a couple cycles of deprecation and do it 18:24:17 historical cycle to max version? 18:24:21 but only for a really good reason 18:24:23 yeah 18:24:28 "deprecation" -- what's that look like for an API rev ? 18:24:36 that's a completely different question :) 18:24:45 I don't think we *can* deprecate an API version 18:24:50 (I don't have a good answer for that right now) 18:25:02 a given version of the server either supports API vX.YY or it does not 18:25:38 doesn't 'deprecation' mean it is supported but a warning is issued to say use 'blah' instead? 18:25:50 rloo: sure. but how do we send such a warning back to the user? 18:25:58 our API semantics don't provide a means for that 18:25:59 in theory, we could add a response header or something to say it's deprecated, but that's a bit odd 18:26:12 and doesn't help older clients 18:26:13 i'm going to punt all this to the api group :) 18:26:15 jroll: also, older clients (that might still be using o... 18:26:17 :) 18:26:18 yea 18:26:35 i mean whatever ironic does, should follow what openstack does. 18:26:48 rloo: I don't believe they've set a standard for this yet 18:26:53 I guess the only true way is doing lots of mass communication, right? a la keystone v2->v3 18:26:57 which we've seen doesn't work well 18:27:08 maybe time to ask them to start then. so it'll be in place when we get there. 18:27:12 jroll: I think that's different 18:27:38 devananda: let me rephrase, that's the only prior art I've seen to dropping API things "gracefully" 18:28:36 for example, what if at the 'P' release, we raised the minimum to 1.6 (Liberty, IIRC) ? 18:28:42 that's two years / four cycles 18:29:08 right, that seems reasonable in theory. but we still need to find a way to tell people 18:29:59 wrt versioning: http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html 18:30:05 do we need users / clients to change anything for that ? 18:30:13 * jroll pokes sean 18:30:17 with keystone v2 -> v3, massive changes were / are required 18:30:39 devananda: depends on the client, I guess 18:31:37 for the ironic cli, it isn't a big pain, maybe upgrade it and request a different version 18:31:49 for some client I built that only knows about 1.2, bigger pain 18:32:04 rloo: oh, interesting tangent - we should update our headers to match that spec, I guess 18:32:29 devananda: yup. i should open a bug about it. 18:32:39 +1 18:33:20 jroll: at least your client would be able to discover (by getting an error back from the server) that it was no longer compatible with that service 18:33:26 jroll: deployers won't need to change anyuthing, though 18:33:37 devananda: yeah, indeed 18:33:40 that's been the biggest issue with key v3 -- deployers needed to run a new service 18:33:51 so perhaps that's a good indication that we shouldn't do v2 as a separate service, actually. 18:34:06 * devananda is merely thinking through this outloud... 18:34:11 yeah, I never envisioned us doing a separate service for v2 18:34:25 but more a little shim to route /v1 and /v2 to the right tree in the code 18:34:32 ah, I see 18:34:59 if we did v2 as a separate framework, we might need to run it as a separate service 18:35:05 or separate mod_wsgi plugin, etc 18:35:38 I haven't tried, but I think it's possible to have a small wsgi app in front of both 18:35:45 and pass it to v2.wsgi.__call__ or whatever 18:35:55 everything is wsgi, thank $deity 18:36:00 heh 18:36:08 ok. I haven't seen that done, but maybe it is 18:36:25 yeah, I'd have to play to confirm, but I think it's possible 18:36:34 maybe that's a todo for the next week or two 18:36:48 * jroll wants to focus on resource_class stuff first though 18:37:03 ++ 18:37:59 put a note in my todo list though, it's one of those things that's interesting enough to hack on for an hour or two 18:38:21 speaking of resource_class... Jay sez it is OK for resource class value to be NULL so it might not be so urgent for ironic 18:38:35 (but we can discuss outside of this meeting) 18:38:48 +1, let's talk about that in channel after 18:39:18 so things for next week 18:39:27 1) I'll actually formalize our grunts with v1 api 18:39:46 2) someone want to talk to API folks about bumping minimum microversion? maybe ML? 18:39:59 3) I'll play with dual-wsgi-framework things over the next week or two 18:40:02 anything I missed? 18:40:17 what about the end goal? 18:40:38 i mean, all the others are means to get to the end goal. what is the new API going to look like? 18:41:19 well, we decided last time that we want to get a spec up that includes: 1) current problems, 2) what the new thing looks like 18:41:23 within the next couple months 18:41:35 oh, that spec would be good then :) 18:41:37 I think we need (1) agreed before we can do (2) 18:41:47 +1 18:41:52 and I don't have the time to do both in a single week :) 18:42:05 I can spend a little time today starting on (1) in a new 'pad 18:42:07 (or even one in one week, apparently) 18:42:10 and sketchiing it into a spec-like structure 18:42:27 devananda: that'd be helpful, I copied things from the midcycle pad into here https://etherpad.openstack.org/p/ironic-v2-api 18:42:32 ah, great 18:42:35 I'll edit in that 18:42:36 and added quick notes from nova discussion 18:42:39 +1 18:42:46 that'd be great. 18:43:01 I'll also attempt to contribute, but might not be until tomorrow or thursday 18:43:18 s/attempt to// (I already said I'd do it heh) 18:43:18 #action deva to draft current-pain-points in a spec like structure 18:43:46 awesome, ty 18:44:00 does anyone want to volunteer to start the deprecation discussion on the ML? 18:44:20 (I'm happy to help summarize ideas/issues so far) 18:45:14 *crickets* 18:45:21 I can take that on 18:45:47 i was going to say that if no one volunteered after 2 weeks, i'd do it. thx jroll :) 18:45:49 alright, anything else today? 18:45:51 lol 18:46:03 rloo: saying that is just going to make me procrastinate :) 18:46:19 * devananda has nothing else right now 18:46:19 jroll: you can procrastinate. the point is you volunteered! 18:46:39 heh 18:46:47 alright, let's get outta here 18:46:51 #endmeeting