18:01:48 <jroll> #startmeeting ironic-api-v2
18:01:48 <openstack> Meeting started Tue Sep 20 18:01:48 2016 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:51 <openstack> The meeting name has been set to 'ironic_api_v2'
18:02:21 <jroll> our (lack of) agenda is here
18:02:23 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic_v2_API
18:02:31 <jroll> devananda: so, you had something to share today yeah?
18:02:35 <devananda> I did!
18:02:46 <devananda> a draft of a bunch of specs for us to begin thinking about is here
18:02:48 <devananda> #link https://review.openstack.org/367583
18:02:52 <rloo> hi sorry i'm late
18:02:56 <devananda> rloo: hi hi!
18:02:59 <jroll> hey :)
18:03:22 <jroll> oh, multiple specs, neat
18:03:25 <devananda> yah
18:03:28 <rloo> so we need to review deva's patch, right?
18:03:43 <devananda> the last couple times we met to talk about these, it became apparent that much of the work could be parcelled out
18:04:00 <devananda> so I went about writing specs for the big things that seemed like they could be done incrementally, within microversions
18:04:17 <devananda> one of those specs, "api-evolution", is just the problem statements for each of them
18:04:34 <devananda> the other 4 specs have some amout of detail of a proposed solution for each problem
18:04:44 <jroll> awesome
18:04:48 <devananda> this doesn't yet cover everything from the etherpad, but it covers a lot
18:04:52 <rloo> i like that approach but wouldn't it be better to have a separate patch for each spec? or are they starting points, to be flushed out more in the spec?
18:05:08 <devananda> I'd like to know what you both think of this approach
18:05:19 <devananda> rloo: agreed -- and I'd like to file an RFE to go with each spec
18:05:34 <rloo> devananda: yes, that is what i was thinking. for 'admin' purposes, ha ha.
18:05:53 <jroll> yeah, agree with separate rfe/spec for each
18:05:58 <devananda> if I do that, should the all encompassing spec be the first one in the chain (we land it as a signal of intent) or the last one (we land it as a signal of completion of planning) ?
18:06:24 <rloo> i think the all encompassing one (w/o having read it) should be first.
18:06:34 <rloo> wouldn't that be similar to the states spec we did?
18:06:51 <jroll> yeah, I think first as well
18:07:11 <jroll> maybe the subsequent patches can remove those problems from the all encompassing spec as they go?
18:07:23 <jroll> and at the end, that spec is gone, because we have no problems anymore :)
18:07:49 <devananda> jroll: hah :) interesting idea
18:07:52 <rloo> or should the all-encompassing spec be a spec. I mean, does it need to be a spec? do the individual specs stand alone w/o it?
18:08:02 <devananda> rloo: they do stand alone
18:08:10 <devananda> or they could -- right now, I think they include references to it
18:08:16 <rloo> meta spec!
18:08:43 <devananda> but I think it's possible to land the api-evolution "metaspec" as a backlog item, then move each problem description out into a new spec (when it lands)
18:08:50 <devananda> and at the end, remove the metaspec from backlog
18:08:55 <devananda> and not change any of the unit tests
18:09:01 <jroll> yeah, that's my thought
18:09:33 <rloo> that'd be a fun thing to do, something different :)
18:09:54 <devananda> if you'd like to peer at the metaspec, here's a rendering:
18:09:56 <devananda> #link http://docs-draft.openstack.org/83/367583/2/check/gate-ironic-specs-docs-ubuntu-xenial/2f1716f//doc/build/html/specs/approved/api-evolution.html
18:10:45 <jroll> nice, looks good
18:11:04 <rloo> if other issues come up, would we update this spec?
18:11:18 <rloo> the API could/will most likely continue to evolve...
18:11:19 <devananda> I think we could follow the same sort of process again
18:12:01 <rloo> ok, maybe we should clamp this down then, once we approve it, to indicate that it reflects issues raised until newton cycle or something like that.
18:12:20 <devananda> jroll: for barcelona, what are you hoping to get out of the f2f discussion?
18:12:54 <rloo> you mean the fishbowl/workroom sessions?
18:12:55 <jroll> devananda: I haven't thought about it too much - maybe we focus on one of the hard pieces and get consensus there?
18:13:54 <devananda> rloo: if someone were to later on propose another specific change to the API, that should follow the usual process, I would think
18:14:10 <devananda> I could even do that for each of these, and not land a metaspec at all
18:14:29 <devananda> but its presence seemed useful to capture that we've all had this discussion in the past, which identified many issues
18:14:32 <rloo> i haven't read the metaspec -- but i do wonder whether we need it.
18:14:38 <devananda> maybe we don't
18:14:57 <devananda> jroll: I am not going to be a good judge of which one of these is hard
18:15:01 <rloo> yes, its presence is useful. what happened to that spec section/directory you wanted to add that had 'useful' info but not necessarily specs?
18:15:03 <devananda> jroll: i think they're all easy ;)
18:15:13 <jroll> devananda: not hard, but contentious
18:15:24 <jroll> or we could spend 40 minutes debating frameworks :D
18:15:43 <devananda> hah hah hah
18:15:47 <jroll> though thinking more about it, maybe we leave the "get off WSME/pecan" out of this
18:15:55 <devananda> jroll: you may notice that I left that off
18:16:12 <rloo> we should decide though, about getting off wsme/pecan. or make it a xproject thing to decide.
18:16:16 <devananda> the four specific proposals here are all ones that I feel like we can do // shouldn't be too contentious
18:16:35 <jroll> rloo: it will never happen cross-project, imo
18:16:44 <rloo> jroll: too bad
18:17:04 <devananda> there will be upgrade concerns and impact on 3rd party drivers -- we will need to agree on how we handle that, but I don't think anyone objects to, eg, "stop overloading node.properties with control metadata"
18:17:48 <rloo> yup. so the sooner we make these changes, the better.
18:17:49 <jroll> right
18:17:58 <jroll> so I was thinking about talking about that one, though
18:18:06 <jroll> because there's a lot of impact there
18:18:23 <jroll> the rest seem fairly obvious
18:18:36 <devananda> for reference
18:18:38 <devananda> #link http://docs-draft.openstack.org/83/367583/2/check/gate-ironic-specs-docs-ubuntu-xenial/2f1716f//doc/build/html/specs/approved/evolve-driver-info.html
18:19:01 <devananda> and yes, there is a lot of impact
18:19:17 <devananda> but it's limited to specific drivers
18:19:31 <jroll> ahhh
18:19:44 <jroll> I was thinking of "make capabilities a first class thing"
18:20:01 <devananda> right - which I did not include
18:20:04 <rloo> yeah, we need to do that too.
18:20:09 <devananda> ehhh...
18:20:14 <devananda> that's a can of worms
18:20:31 <devananda> I have intentionally focused this on things that I do not think are contentious // that we can actually achieve
18:20:57 <jroll> considering we expect this to be a somewhat ongoing thing, one spec at a time... why did you focus on those?
18:21:19 <devananda> jroll: I think these four could all be done in one cycle
18:21:31 <devananda> with the appropriate deprecation periods following it
18:22:19 <jroll> we could still lay it out and do these four first
18:22:29 <jroll> like, these easier changes are great
18:22:48 <jroll> but we have some seriously terrible things in our API that I would like to try to fix sooner than later
18:22:55 <jroll> and that's what I originally intended for this group to do
18:23:00 <jroll> (the hard stuff)
18:23:25 <rloo> the hard stuff is what i think the f2f meetings will be useful for.
18:23:27 <jroll> I'm not saying "this is a bad way to do this", just surprised, as it isn't what I imagined
18:23:45 <jroll> rloo: right, not sure any of this needs summit time
18:23:56 <devananda> jroll: which items from https://etherpad.openstack.org/p/ironic-v2-api do you feel are hard // need summit time?
18:24:14 * devananda notes that "make capabilities a first class thing" isn't on there
18:25:02 <jroll> it is, #4
18:25:12 <jroll> your spec proposes a partial fix for #4
18:25:47 <devananda> jroll: no - my spec is a complete fix for #4
18:25:55 <devananda> it doesn't address how the nova scheduler uses capabilities
18:26:05 <devananda> I did not interpret that as the problem described by #4
18:26:08 <jroll> but I think task tracking, API version deprecation, a deploy API, multitenant without nova, get off pecan/wsme - are all hard things that need discussion
18:26:40 <jroll> maybe we understand #4 differently, but I think putting those at node.capabilities is important and part of #4
18:27:01 <jroll> and I think #4 is about more guarantees about what is in our json blobs in general
18:27:16 <devananda> I see
18:27:36 <devananda> "Having undefined configurations/options is a separate problem that should be fixed with better documentation and more unity between different drivers  +1000"
18:28:02 <devananda> I agree with whoever wrote that -- that it's a separate problem from "some values in node.properties.capabilities actually change how Ironic behaves"
18:28:14 <devananda> so that is what I focused on
18:28:37 <devananda> anyhow -- if the structure here is good, I'll continue writing proposals for the harder changes (task tracking, deploy API, etc)
18:28:47 <jroll> got it
18:28:54 <jroll> yeah, I'm good with the plan/structure
18:29:03 <jroll> I'm not sure I agree we can do the first four in ocata, but hey :)
18:29:11 <jroll> certainly willing to try
18:29:18 <devananda> :)
18:29:27 <rloo> i hadn't thought about ocata, but now i'm starting to worry about everything i'd like to see in ocata...
18:29:52 <jroll> heh
18:29:54 <jroll> so much to do :)
18:30:21 <rloo> so i think we should decide which harder things we'd like to see in ocata, so that we can get those in good enough shape to discuss at the summit.
18:30:56 <devananda> maybe we pick one right now?
18:31:12 <rloo> and we need to remind/ask folks to spend time before the sessions, getting uptospeed/reading the proposals first.
18:31:27 <devananda> rloo: indeed
18:32:03 <devananda> maybe we post a sign, like at the county fair, "if you haven't read these 1,000 lines of spec proposal, you do not get to ride this ride" :)
18:32:07 <jroll> I'd love to see version deprecation mechanisms worked on, in a cross-project context
18:32:11 <rloo> we should make capabilities a first class citizen. do we even know whether it is a dict that can take any key?
18:32:22 <jroll> rloo: it is, afaik
18:32:36 <devananda> rloo: it can right now, except in some cases, where the drivers do different things
18:32:44 <devananda> it's bizarre :(:
18:32:58 <rloo> devananda: i think we probably need to let folks know that the sesssions are not going to be spent describing the problem but discussing the solution. unless we don't know what the problem is.
18:33:20 <devananda> well, at the midcycle we made a list of the problems :)
18:33:34 <rloo> yeah, i know it can take any key now. in the new world, would we want to predefine what is allowed for capabilities?
18:33:36 <devananda> jroll: I would like to see that as well, but I do not think it will happen
18:33:44 <jroll> devananda: ever?
18:34:05 <devananda> rloo: you temp the can of worms I was referring to earlier...
18:34:11 <devananda> jroll: not this cycle anyway
18:34:19 <jroll> sure
18:34:21 <devananda> jroll: but I may be wrong
18:34:21 <rloo> devananda: gotta face the worms head on!
18:34:35 <devananda> jroll: anyhow, I don't think we should take that one on ourselves yet
18:34:49 <rloo> i wonder how productive the barcelona summit will be... depends on who shows up...
18:35:04 <jroll> devananda: yeah, I just wonder how soon we'll want it, I suspect it is soon
18:35:25 <rloo> jroll: you could always propose it to the xproject part. if you propose, does it mean you have to have a solution?
18:35:44 <devananda> so, other ideas: task tracking tokens ? deploy API without Nova ? better multi-user support ?
18:36:25 <jroll> I'd hold off on the last one, but task tracking seems like it could be doable, not crazy hard
18:37:02 <rloo> do either of you have an idea of the operators' pain points. the really bad ones they would like fixed sooner rather than later?
18:37:07 <devananda> rloo: IME, xproject discussions often lack a concrete solution going in - sometimes the goal is to see who in the room can think of one
18:37:26 <jroll> right, deva said it better than me
18:37:49 <rloo> clint to the rescue with the architecture whatever group
18:37:56 <devananda> rloo: nova interaction. rolling upgrades. stuck nodes. better debugging of IPA. (just off of memory )
18:38:18 <jroll> I'd agree with those
18:38:24 <rloo> devananda: and those are higher than these api issues?
18:38:49 <jroll> probably
18:39:18 <rloo> hmm. we should use the summit to discuss any hard issues that prevent us from getting something done in ocata.
18:39:32 <rloo> what nova interactions are left ? :)
18:39:43 <devananda> rloo: capabilities :p
18:39:47 <jroll> heh
18:39:55 <jroll> yeah maybe we should focus on capabilities
18:39:58 <rloo> why do i hear 'capabilities' again?
18:40:08 <rloo> yup. i think we should tackle that then.
18:40:18 <devananda> jroll: speaking of summit time, we should definitely discuss the nova / scheduler / resource tracker stuff
18:40:28 <devananda> we rushed in an API change for that in newton
18:40:44 <rloo> and maybe it will be sufficient to work on the easier api stuff via spec discussions, and not at summit.
18:40:49 <jroll> devananda: as in kind of a knowledge sharing session, or?
18:40:51 <jroll> rloo++
18:41:00 <devananda> jroll: yes, knowledge/plan sharing
18:41:12 <jroll> ++
18:41:17 * rloo hopes there are enough (knowledgeable) developers and reviewers in ocata to get the work done.
18:41:33 <devananda> we don't have a lot of f2f time, but IMO that's important enough to give it some time
18:41:35 <devananda> rloo: me too ....
18:41:39 <rloo> probably a fishbowl for the nova/scheduling/...
18:41:41 <jroll> devananda: agree
18:41:51 <jroll> I think there are enough people in nova, this is now one of their priorities
18:42:04 <devananda> jroll: if you think these 4 things, plus, say, task tracking, are uncontentious enough that we won't need summit time for them -- tht's great
18:42:18 <rloo> is that a joint nova/ironic session?
18:42:47 <rloo> we can see what is being proposed for summit sessions; can always have one to discuss things we want to see done...
18:42:47 <jroll> it's just sharing time, I think if we can get jay pipes in to an ironic session and it should be sufficient
18:43:26 <rloo> true. i think with nova, if you bring one nova person, you get a few more for free. with neutron, you get them all :)
18:43:27 <devananda> that's another session where folks should read the docs ahead of time
18:43:39 <jroll> devananda: I think the capabilities thing might need one, if we go further than "move a few capabilities to driver_info"
18:44:00 <devananda> I don't think we need to take that on in ocata, tbh
18:44:03 <rloo> now, the nova/scheduling/ stuff could do with a meta spec!
18:44:43 <devananda> jroll: or to put it another way, I have no idea how to solve that at the moment // in this cycle
18:44:47 <jroll> rloo: there's already 10+ specs in nova :)
18:44:50 <jroll> devananda: sure
18:45:07 <rloo> jroll: that's what i mean. wading through them all to understand how the new nova scheduling will work...
18:45:46 <jroll> rloo: yeah
18:45:55 <jroll> it's dense, and confusing
18:46:00 <jroll> maybe jay and I can write a thing
18:46:25 <rloo> jroll: that'd be good. can be the basis of your summit session :)
18:46:30 <rloo> so wrt the api stuff...
18:46:35 <rloo> what did we decide?
18:47:00 <jroll> sounds like "probably don't need a barcelona session"
18:47:02 <devananda> I'll add a task tracking spec
18:47:18 <rloo> and we're not going to look at capabilities in ocata?
18:47:29 <devananda> rloo: not the major overhaul of it, at least
18:47:41 <jroll> right, just the move some to driver_info bit
18:48:00 <rloo> oh, yuck. still keep the rest in properties/capabilities?
18:48:18 <jroll> we need to get more of the scheduling work done to be able to move those out
18:48:23 <jroll> currently people use them in nova
18:48:25 <devananda> what jroll said ^
18:48:32 <rloo> SIGH. ok.
18:48:59 <jroll> we all want them gone. soon.
18:49:08 <rloo> i guess you don't like the idea of a shim in the ironic-virt driver to convert capabilities <-> properties/capabilities?
18:49:11 <jroll> we *will* do it, just needs a bit more work
18:49:19 <rloo> ok, i can be patient.
18:49:25 <jroll> I mean, we could do that too
18:49:35 <jroll> but there's some complications, idk
18:49:48 <jroll> probably worth shaking out scheduler changes first
18:49:54 <rloo> it isn't worth the complications. i don't think. there's already lots of other work to do anyway.
18:50:07 <jroll> ya
18:50:11 <devananda> jroll: agreed. let's not complect the scheduler changes more than they already need to be
18:50:23 <jroll> right
18:50:53 <jroll> so action items for now is deva writes more words, the rest of us review said words, yes?
18:51:07 <rloo> yup.
18:51:13 <jroll> cool
18:51:15 <jroll> anything else?
18:51:16 <devananda> yah
18:51:18 <devananda> nope
18:51:33 <devananda> yah - I write more words. nope - nothing else :)
18:51:35 <jroll> rloo?
18:51:39 <rloo> i'm good.
18:51:42 <devananda> thanks, ya'll
18:51:44 <jroll> cool
18:51:48 <jroll> yes, thanks
18:51:50 <rloo> thx deva!
18:51:50 <jroll> oh before we go
18:51:56 <jroll> next week or skip a week?
18:52:02 <devananda> skip is good with me
18:52:12 <rloo> i'm always happy to skip
18:52:22 <jroll> heh, cool, see you here in 2 weeks :)
18:52:37 <jroll> #endmeeting