17:00:23 <NobodyCam> #startmeeting Ironic
17:00:23 <NobodyCam> #chair devananda
17:00:23 <openstack> Meeting started Mon Feb  9 17:00:23 2015 UTC and is due to finish in 60 minutes.  The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:24 <NobodyCam> Welcome everyone to the Ironic meeting.
17:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:27 <openstack> The meeting name has been set to 'ironic'
17:00:28 <openstack> Current chairs: NobodyCam devananda
17:00:32 <devananda> o/
17:00:37 <mjturek1> hey all o/
17:00:40 <naohirot> o/
17:00:41 <NobodyCam> Of course the agenda can be found at:
17:00:41 <NobodyCam> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:00:42 <rameshg87> o/
17:00:45 <lucasagomes> o/
17:00:45 <Nisha> o/
17:00:49 <NobodyCam> #topic Greetings, roll-call and announcements
17:00:50 <dtantsur> o/
17:00:50 <NobodyCam> Roll-call: Who's here for the Ironic Meeting?
17:00:57 <Shrews> ahoy!
17:00:58 <rloo> o/
17:01:01 <mjturek1> o/
17:01:03 <rameshg87> o/
17:01:03 <NobodyCam> howdy ya'all
17:01:10 <naohirot> o/
17:01:14 <NobodyCam> \o/ :)
17:01:25 <JoshNang> o/
17:01:26 <jroll> \o
17:01:38 <maurosr> \o
17:01:51 <NobodyCam> devananda: is getting some coffee so may be a minute late
17:01:55 <NobodyCam> announcements:
17:02:17 <NobodyCam> one meetup (sprint) down
17:02:30 <NobodyCam> another (in San Fran) in a couple of days
17:02:36 <jroll> woohoo
17:02:39 <jgrimm> o/
17:02:42 <NobodyCam> whos going to be at the SF sprint
17:02:47 <NobodyCam> o/
17:02:49 <devananda> last week's sprint went very well, IMHO
17:02:50 <Shrews> o/
17:02:52 <wanyen> o/
17:02:56 * jroll is already there
17:03:07 * GheRivero says hi
17:03:07 <NobodyCam> ahh welcone devananda :) awesome to hear
17:03:14 <NobodyCam> hi GheRivero :)
17:03:30 <lucasagomes> devananda, +1 that was great
17:03:33 <devananda> with ~10 ppl, it felt like we all were able to actually get things done
17:03:47 <NobodyCam> saw some great ski photos :)
17:04:07 <lucasagomes> :D
17:04:23 <NobodyCam> :) anything else for announcements?
17:04:41 <devananda> just one
17:04:54 <devananda> kilo-2 was tagged last week, for those who weren't watching
17:05:10 <devananda> for the list of what blueprints were completed: https://launchpad.net/ironic/+milestone/kilo-2
17:05:10 <NobodyCam> :)
17:05:31 <devananda> I have yet to post a complete CHANGELOG, but will try to do that today
17:05:34 <devananda> that's it for me
17:05:35 <NobodyCam> I also sow a couple bp got bumped to k3
17:05:53 <devananda> yah. anything not done by thursday was bumpbed automatically
17:06:04 <NobodyCam> #link https://launchpad.net/ironic/+milestone/kilo-3
17:06:05 <jroll> wow, 40 bugfixes, love it
17:06:18 <devananda> moving on ...
17:06:20 <rloo> yay to everyone (us) for contributing to kilo-2 :-)
17:06:31 <devananda> #topic subteam status reports
17:06:35 <NobodyCam> https://launchpad.net/ironic/+milestone/kilo-
17:06:39 <NobodyCam> doh
17:06:48 <wanyen> deva, like toadd secure boot to kilo3
17:06:58 <NobodyCam> did we get a status report after last weeks meeting?
17:07:03 <jroll> I've been really bad about sending subteam reports :/
17:07:16 <NobodyCam> :)
17:07:18 <jroll> is there anyone else willing to do that, that can do a better job?
17:07:30 <NobodyCam> it was kinda a small meeting lastweek
17:07:33 <rloo> jroll: I can help you
17:07:50 <jroll> rloo: that would be great, even just a reminder would help :)
17:08:03 <rloo> jroll: we can discuss how many beers later ;)
17:08:07 <jroll> also, sorry IPA broke the gate :P
17:08:08 <NobodyCam> rloo: can I ginve you a #action item for that?
17:08:10 <jroll> haha
17:08:13 <rloo> NobodyCam: yup
17:08:23 <devananda> wanyen: I'll do what I can with Nova to get the capabilities change approved over there. I know it's just a small patch....
17:08:38 <naohirot> devananda: I'd like to know the status of new state machine transition
17:08:39 <devananda> wanyen: as far as secure boot, what is the spec name?
17:08:40 <NobodyCam> #action rloo to start helping jroll with status reports after meeting
17:08:46 <devananda> naohirot: which transition?
17:08:57 <lucasagomes> devvesa, yeah, that patch is also blocking the local boot one
17:08:59 <lucasagomes> hope they accept the FFE
17:09:04 <naohirot> devananda: I saw your patch https://github.com/openstack/ironic/commit/e7958dee652ecd961a90eafd2c0411bc464b0adb
17:09:07 <wanyen> I will find the name for secure boot
17:09:18 <lucasagomes> devvesa, sorry I meant devananda
17:09:28 <devananda> lucasagomes: capabilities change in Nova is blocking our local boot support?
17:09:29 * lucasagomes can't dev<tab> here
17:09:37 <naohirot> devananda: but there is still NOSTATE here https://github.com/openstack/ironic/blob/master/ironic/tests/drivers/ilo/test_deploy.py#L388
17:10:01 <naohirot> devananda: does that mean that the code transition is still on going?
17:10:07 <lucasagomes> devananda, yeah, local boot is set as a capability which is then passed via the Nova Ironic driver to the instance_info
17:10:12 <jroll> naohirot: that's target_provision_state
17:10:18 <jroll> naohirot: where NOSTATE is valid
17:10:26 <lucasagomes> we could change that tho, I was mostly following a spec that was upstream and I took over
17:10:54 <jroll> lucasagomes: capability for the flavor? hrm
17:11:02 <lucasagomes> jroll, yeah
17:11:03 <naohirot> jroll: I see, target_provision_state still is valid to be NOSTATE.
17:11:06 * jroll thinks we may be way off topic here on many threads
17:11:06 <devananda> naohirot: all "stable" states will continue to have target_provision_state == NOSTATE
17:11:10 <wanyen> deva : https://review.openstack.org/#/c/135228/ and https://review.openstack.org/#/c/135845/
17:11:11 <devananda> jroll: yes :(
17:11:38 <NobodyCam> our agenda is light today
17:11:47 <lucasagomes> devananda, jroll yeah we are a bit off, but we can talk about it later... we could do it differently, but I will have to update the spec
17:11:50 <naohirot> devananda: jroll: I'll check the new state machine blue print again
17:12:09 <stendulker> devananda: secure boot spec for ilo drivers: https://review.openstack.org/#/c/135228/
17:12:45 <Nisha> devananda, one query(may be we can take up in open dsicussion)...dtantsur has posted a comments states patch for inspection that the transient state INSPECTED may not be needed noe
17:12:49 <devananda> #action devananda to update launchpad status for several approved specs
17:13:01 <devananda> ok, we've really gone off topic now folks
17:13:01 <Nisha> s/noe/now
17:13:13 <devananda> this should be a time for driver maintainers to share their status
17:13:25 <NobodyCam> anything else on subteam status'
17:13:30 <devananda> wanyen was pointing out that the ilo driver has some approved specs that are not targeted or reflected in launchpad
17:13:39 <rloo> question about IPA breaking the gate -- is there no way to see if it breaks the gate first, before making the change?
17:14:04 <jroll> rloo: the nova configdrive patch landed, and that's when it broke, configdrive was not being tested in gate previously
17:14:17 <NobodyCam> rloo: thats tuff at least how I see things
17:14:26 <rloo> jroll: ahh. ok thx
17:14:33 <devananda> #action devananda and wanyen to work with Nova team to try to land the capabilities-related change to ironic driver
17:14:35 <lucasagomes> jroll, oh didn't know that
17:14:39 <jroll> rloo: ipa has tempest jobs that test ipa with ironic, ironic has tempest jobs that test ipa with ironic, it should generally be fine
17:14:46 <wanyen> deva, tx
17:14:49 <jroll> nova only has tempest jobs for ironic with pxe_ssh
17:14:57 <NobodyCam> wanyen: did you get ffe for that?
17:15:08 <jroll> lucasagomes: no worries, not your fault, apparently partprobe doesn't work on the VMs that the ssh driver uses :|
17:15:10 <devananda> adam_g hasn't chimed in yet, but I believe he started looking at tempest-lib'ifying our functiona ltests
17:15:17 <Nisha> NobodyCam, requested FFE in mailing list already
17:15:19 <devananda> eg, moving them out of tempest and into ironic's tree last week
17:15:19 <wanyen> I submitted ffe but I have not got approval
17:15:26 <lucasagomes> jroll, urgh... I see
17:15:33 <jroll> devananda: +1
17:15:50 <devananda> AIUI there is still a lot of work to do there, not just in Ironic, so there was no concrete progress
17:15:51 <NobodyCam> is there a #link for the request we can post here?
17:16:54 <devananda> on the oslo side, I believe the oslo'ification of the Object code is still blocked on dhellmann. and not really a priority for anyone this cycle
17:16:55 <rameshg87> NobodyCam, http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg45394.html
17:17:22 <devananda> oh, and one more thing
17:17:34 <devananda> I proposed a novel change to how we classify drivers
17:17:44 <devananda> to make it more clear which drivers are meant for production -- and which are meant for testing environments
17:18:09 <devananda> I'm raising it here because it affects driver maintainers (which is what this section is about)
17:18:09 <NobodyCam> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056256.html
17:18:12 <devananda> #link https://review.openstack.org/#/c/152056/
17:18:31 <devananda> I would like to elicit feedback from the driver authors on this patch before doing any more work on it
17:19:19 <devananda> on teh review -- not right now :)
17:19:35 <devananda> ok, that's all for me. any other last words before we move on?
17:19:45 <NobodyCam> should we update the #topic?
17:19:51 <NobodyCam> :)
17:19:52 <devananda> NobodyCam: I will shortly
17:20:05 <naohirot> devananda: I'll certainly take a look
17:20:22 <devananda> naohirot: thanks
17:20:39 <naohirot> devananda: you are welcome
17:20:42 <devananda> #topic whether or not RAID should have a separate interface
17:20:51 <devananda> rameshg87: you're up -- anything to discuss?
17:20:53 <NobodyCam> this spec landed on friday
17:21:14 <rameshg87> there were some opinion that for raid configuration should use management interface instead of a new RAIDInterface
17:21:28 <rameshg87> there were people for it and against it
17:21:53 <rameshg87> so just thought we could discuss it out here. spec has landed by the way. but i would like to get everyone's thoughts
17:21:53 <rloo> what was decided?
17:21:58 <devananda> rameshg87: can you summarize both sides of the debate?
17:22:09 <lucasagomes> what are the pos/cons people pointed out?
17:22:10 <rloo> link to spec?
17:22:21 <rameshg87> rloo, raid configuration on bare metal node requires methods
17:22:33 <rameshg87> rloo, i meant https://review.openstack.org/#/c/135899/
17:22:51 <devananda> #link http://specs.openstack.org/openstack/ironic-specs/specs/kilo/ironic-generic-raid-interface.html
17:22:53 <NobodyCam> #link https://review.openstack.org/#/c/135899/
17:22:57 <mrda-sfo> \o
17:22:59 <rameshg87> raid configuration requires methods to create and delete the raid configurations on bare metal node
17:23:12 <jroll> my only concern with the RAIDInterface is that our driver matrix is growing at an exponential rate, and we need to find a better way to handle it
17:23:13 <rameshg87> currently proposed one is a new RAIDInterface which will be a new attribute to the driver
17:23:39 <rameshg87> as opposed to we could be having the new methods in ManagementInterface itself
17:23:49 <NobodyCam> we need to rething how we're naming our drivers
17:23:53 <dtantsur> jroll, we already have it pretty insane :D
17:24:06 <jroll> right
17:24:12 <devananda> rameshg87: what is the benefit to using a separate interface?
17:24:15 <dtantsur> (and we used to have for some time, if we count console and vendor interfaces)
17:24:27 <rloo> will the RAIDInterface be a standard interface? (I should read the spec before asking)
17:24:45 <lucasagomes> rloo, yeah, I assume it's
17:25:02 <jroll> I don't want to necessarily block this on that fact, however I think we really need to start figuring this ouy
17:25:05 <jroll> s/ouy/out/
17:25:10 <lucasagomes> core is only what is really needed to put workload on a node
17:25:14 <lucasagomes> like power and deploy
17:25:42 <rameshg87> devananda, my opinion it's just the cleaner approach. raid being new functionality that we introduce could demand it's own interface
17:26:15 <devananda> jroll: let's dive into that this week, then. I think we are all concerned about it
17:26:44 <jroll> indeed
17:26:47 <lucasagomes> +1
17:26:54 <lucasagomes> but idk, RAID is a very vendor specific thing no?
17:26:56 <devananda> one aspect to point out -- having this as a separate interface means that support for it is discoverable in the REST API
17:27:02 <devananda> via node-validate
17:27:04 <lucasagomes> I mean, management should be common ground across drivers
17:27:27 <devananda> if it were part of ManagementInterface, then all nodes that support the management functions would need to support RAID as well
17:27:33 <devananda> which they may not
17:27:47 <dtantsur> devananda, ++
17:27:52 <lucasagomes> yeah, they can't not
17:27:52 <devananda> or it would violate the API contract whereby a driver supports only some of the management commands but not all
17:27:55 <lucasagomes> can not*
17:27:57 <NobodyCam> +
17:28:07 <rloo> console is in ManagementInterface and that isn't supported by all drivers
17:28:08 <lucasagomes> that's my reason why I prefer it in a separated interface
17:28:14 <lucasagomes> but well, I could argue both sides really
17:28:23 <dtantsur> rloo, console is a separate interface IIRC
17:28:26 <devananda> rloo: that makes me sad. I like things to be consistent. want to file a bug?
17:28:33 <rloo> dtantsur: oh, is it?
17:28:37 * rloo checks
17:28:41 <rameshg87> rloo, may be sensors
17:28:44 <lucasagomes> rloo, yeah console is separated
17:28:49 <lucasagomes> sensors is mgmt
17:28:49 <devananda> oh yah. console is separate
17:28:49 <dtantsur> rloo, yeah, console is separate
17:28:53 <NobodyCam> I thouht it was
17:29:03 * rloo wrong. Sorry, it was sensors I was thinking of.
17:29:11 <lucasagomes> maybe we should brainstorm, what should be part of each interface
17:29:18 <lucasagomes> come up with some guides
17:29:21 <lucasagomes> very clear
17:29:30 <NobodyCam> lucasagomes: ++
17:29:38 <NobodyCam> maybe in SF
17:30:00 <lucasagomes> NobodyCam, could be, but keep me in the loop pls :( I won't make it to SF unfortunately
17:30:10 <NobodyCam> ya ofc :)
17:30:13 <devananda> isn't thatd already be documented in-line? if not, it should be
17:30:19 <devananda> on the drivers/base.py module
17:30:39 <lucasagomes> """Interface for management related actions."""
17:30:47 <lucasagomes> not very specific
17:30:48 <NobodyCam> devananda: I feel a clearity doc would only help
17:30:55 <devananda> yup
17:30:59 <devananda> it definitely is
17:31:02 <NobodyCam> my only concern is keeping it up to daye
17:31:06 <devananda> lucasagomes: look down. each method on taht interface has a doc string
17:31:11 <devananda> and they're all abstract
17:31:20 <devananda> so any driver implementing ManagementInterface has to implement those
17:31:44 <devananda> anyway, if folks feel that can be improved -- please feel free to do so :)
17:31:51 <devananda> I just want to avoid havign docs in two places for the same thing
17:31:55 <rloo> devananda: I think they implement and return some NotImplemented exception
17:32:05 <devananda> rloo: oh. that's ... bad
17:32:15 <lucasagomes> devananda, right, I was thinking about new methods... like if you want to add support for something, should it go to the mgmt interface ? e.g is it something common which all drivers could implement
17:32:19 <devananda> drivers shouldn't get to say "I'm only half a driver" and still be allowed in tree
17:32:23 * lucasagomes not sure, thinking out of loud here
17:32:33 <devananda> vendor_passthru is the place for that
17:32:49 <devananda> anyway ... we're now quite far off topic again :)
17:32:54 <rloo> eg get_sensors_data
17:33:00 <lucasagomes> heh yeah, let's talk about it later
17:33:05 <devananda> this sounds like a good discussion to have at the meetup, too
17:33:08 <lucasagomes> add to the SF agenda :)
17:33:31 <devananda> #topic is the install-guide complete, w.r.t. neutron setup?
17:33:35 <devananda> mjturek1: hi! you're up
17:33:44 <mjturek1> hey! really nothing urgent, but just thought I'd bring it up here.
17:33:56 <mjturek1> I noticed a missing step in the installation guide last week (subnet creation step -- already patched and committed).
17:34:08 <NobodyCam> mjturek1: and thank you for your doc patch for subnet setup
17:34:12 <mjturek1> which had me wondering how complete the guide is as I've had some issues with getting a setup working using it, though it may be some networking problems on my end.
17:34:19 <mjturek1> NobodyCam np :)
17:34:28 <mjturek1> There is already an initiative to get the installation guide improved https://bugs.launchpad.net/ironic/+bug/1323589
17:34:28 <openstack> Launchpad bug 1323589 in Ironic "Installation guide needs updating" [Medium,In progress] - Assigned to Chris Krelle (nobodycam)
17:34:36 <NobodyCam> mjturek1: there is always room to improve our docs
17:34:50 <mjturek1> NobodyCam, very true. Just wanted to push to possibly get a few more eyes on it (the guide and the bug page).
17:34:52 <NobodyCam> me?
17:34:58 <devananda> mjturek1: good question. I believe haomeng had been doing some work on that
17:35:10 <devananda> mjturek1: but largely it's user contributed, so please continue fixing things you find missing
17:35:25 <mjturek1> devananda, okay fair enough :) will do
17:35:37 <NobodyCam> awesome thank you mjturek1 :)
17:35:43 <mjturek1> thanks!
17:35:48 <devananda> mjturek1: cheers. thank you!
17:35:57 <devananda> #topic open discussion
17:36:10 <NobodyCam> wow OD with > 20 minutes
17:36:21 <NobodyCam> thats a first :)
17:36:22 <devananda> oh .. so I do need to ask folks about the summit
17:36:25 <devananda> #undo
17:36:26 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x99c07d0>
17:36:29 <devananda> #topic summit planning
17:36:37 <lucasagomes> jroll, wanna talk about the local boot capabilities thing?
17:36:44 <Nisha> i have a question to ask in open-discussion
17:36:44 <lucasagomes> oh ok, wait for OD again
17:36:50 <devananda> usually the layout of design summit sessions is done a little later
17:36:51 <jroll> heh
17:36:58 <NobodyCam> I'll be driving up to SF tomorrow and mostly off line
17:37:04 <devananda> but ttx needs us to decide soon how many sessions we want to have
17:37:12 <jroll> devananda: all the sessions
17:37:17 <mrda-sfo> +1 :)
17:37:18 <devananda> split between big "fishbowl" style -- everyone in a big room
17:37:20 <ttx> devananda: or at least provide a wild guess
17:37:25 <lucasagomes> devananda, what I really felt on the last summit is that when we got the room for ourselfs
17:37:30 <lucasagomes> for half a day it was very productive
17:37:34 <devananda> and smaller "working" sessions where it's just us and a whiteboard, basically
17:37:41 <lucasagomes> better than having sessions the normal way
17:37:47 <devananda> and then whether we have half or a whole day on friday
17:37:56 <lucasagomes> if we could have a room for at least one full day, that would be awesome
17:37:57 <dtantsur> my impression is that "us and a whiteboard" works much better
17:38:00 <devananda> the "workign" sessions are a new style we have never had before
17:38:39 <lucasagomes> we could have a normal session for operators give feedback tho
17:38:50 <lucasagomes> idk how much it worked last time, but it's good to keep it open
17:38:51 <rloo> the fishbowl sessions were useful for ^^ what lucasagomes just said
17:38:52 <NobodyCam> I kinda felt like we had to many seesions last summit, I would vote to limit topics
17:39:04 <devananda> here's what I'm leaning towards -- 2 fishbowl sessions (one general project things and one for operators) 6 working sessions (for what ever) and then a whole day friday
17:39:36 <mrda-sfo> I liked the unstructured time, although most people just hung around the state machine discussion, and very little other work was done.  So I think we need a mix of both.
17:39:38 <lucasagomes> devananda, sounds good
17:39:40 <rloo> what's the diff between working sessions, whole day Friday?
17:39:53 <NobodyCam> I say that only because I missed a bunch of the state stuff which if we had all been focused *may* have landed quicker
17:39:55 <devananda> rloo: working sessions are on tue/wed/thur
17:40:01 <lucasagomes> like a hackaton I believe ?
17:40:17 <rloo> devananda: but what is done at working sessions that is diff than what we'd do on Friday?
17:40:17 <devananda> we can do less working sessions if we think we'll want to be in other tracks
17:40:24 <devananda> eg, nova, cross-project, etc
17:40:42 <devananda> rloo: only that they have a formal topic and get listed in the schedule
17:40:53 <devananda> rloo: well, and we could NOT give them a formal topic, if we wanted to
17:41:09 <NobodyCam> I like the two Fishbowl sessions and rest as working
17:41:22 <devananda> but they COULD have one. whereas friday definitely does not have a presence in the scheduling app
17:41:24 <NobodyCam> the large fihbowls tend to side track
17:41:26 <rloo> devananda: so working sessions would sort of be/replace the pod stuff that didn't work
17:41:31 <devananda> rloo: exactly
17:41:39 <devananda> there will be no pods this time
17:42:24 <devananda> it sounds like I'm hearing that folks like my suggestion of 2 fishbowl / 6 working / unstructured all day friday
17:42:32 <jroll> seems fine to me
17:42:35 <lucasagomes> +1
17:42:36 <NobodyCam> ++ here
17:42:39 <rloo> interesting. I guess it depends on what the other projects do too. cuz before we'd sit in on nova etc sessions, I don't know now if those would be fishbowl or working.
17:42:57 <devananda> rloo: taht's up to those PTLs ... I dont know either at this point
17:43:49 <rloo> how many fishbowl did we have last summit?
17:43:54 <devananda> rloo: 5
17:44:01 <devananda> and a half day friday, and no working sessions
17:44:13 <devananda> thanks for the input, everyone
17:44:34 <rloo> hmm. am worried that 2+6 would be too many, if people want to attend others that overlap, but we could try and see.
17:45:01 * mrda-sfo thinks we were a little light on with sessions last summit, fwiw
17:45:21 <NobodyCam> rloo: I'm sure we can adjust as the other sessions harden there paln
17:45:26 <NobodyCam> plans even
17:45:36 <rloo> haha, I thought NobodyCam said 'pain'.
17:45:43 <devananda> we're always trying something new as things keep changing rapidly :)
17:45:46 <lucasagomes> we probably will re-revise it when they start making the conference schedule
17:45:54 <NobodyCam> ++
17:45:58 <devananda> #topic open discussion
17:46:06 <lucasagomes> jroll, yo
17:46:14 <rloo> microversioning -- should we announce/mention how to use it?
17:46:24 <devananda> rloo: yes!
17:46:31 <lucasagomes> jroll, so, I thought it would make sense to say, give me a machine with local boot and using flavor as the way to ask for it
17:46:35 * lucasagomes maybe I was wrong?
17:46:39 <devananda> rloo: folks should read the nova spec
17:46:45 <NobodyCam> do we need a how to bump the microversion type doc?
17:47:00 <devananda> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html
17:47:01 <NobodyCam> or is spec good enough?
17:47:05 <jroll> lucasagomes: sure, that's fine... though I don't know that the user always cares. or maybe the operator wants to decide (make all flavors localboot?)
17:47:10 <wanyen> lucasgomes, +1
17:47:11 <Nisha> INSPECTED - should this state be removed?
17:47:18 <devananda> Nisha: why?
17:47:30 <lucasagomes> jroll, yeah, exactly it's possible
17:47:34 <rloo> I think we need something more than spec. The spec mentions using decorators that we're not using.
17:47:44 <Nisha> devananda, there is a suggestion from dtantsur on code changes for inspection
17:47:58 <lucasagomes> jroll, sounds like an operator decision to me whether the instances will always localboot or only some of them will
17:47:59 <NobodyCam> Nisha: #link?
17:48:01 <devananda> rloo: refactoring what we have to use decorators ++
17:48:09 <dtantsur> yeah, I'm a bit confused by these *ED states
17:48:12 <Nisha> so just wanted to have everyone's opinion
17:48:14 <jroll> lucasagomes: ok, maybe it's fine, I just haven't thought about it much
17:48:16 <Nisha> #link https://review.openstack.org/#/c/147857/
17:48:17 <devananda> rloo: or something else, maybe something like version-utils
17:48:23 <NobodyCam> ty :)
17:48:41 <devananda> on the *ED states, my intent was to provide an optional hook for additional call backs
17:48:44 <lucasagomes> jroll, cool, np, yeah we can think over it
17:48:51 <lucasagomes> see if it really makes sense
17:48:55 <jroll> yep :)
17:49:32 <Nisha> devananda, one ques then how does the node then move from *ED (INSPECTED) to some stable state (in thi case MANAGEABLE)
17:50:11 <devananda> Nisha: on the completion of what ever callback is triggered by INSPECTED, the "done" action would move it to the next state, namely MANAGEABLE
17:50:16 <Nisha> devananda, in my code changes i am not sure when to move the node from INSPECTED to MANAGEABLE
17:50:26 <devananda> Nisha: however, since no drivers are using this now, I'm fine if we skip over that transition
17:50:39 <devananda> Nisha: or if we implement it as a no-op
17:51:06 <Nisha> devananda, ok
17:51:08 <devananda> but for example, I can envision the CLEANED state performing a re-verification of the node before moving it to MANAGEABLE
17:51:10 <wanyen> no-op sounds more flexible
17:51:22 <lucasagomes> +1 for no-op in that case
17:51:47 <JoshNang> hmm i like that idea for CLEANED
17:52:00 <devananda> no-op would be my preference
17:52:06 <JoshNang> +1
17:52:08 <mrda-sfo> +1
17:52:12 <Nisha> ok :)
17:52:13 <wanyen> +1
17:52:26 <dtantsur> ok, it's clearer now :)
17:52:30 <devananda> #agreed implement the CLEANED state transition using a no-op for now, to allow it to be extended by drivers later on
17:52:46 <Nisha> devananda, its INSPECTED
17:52:51 <devananda> oops
17:52:52 <devananda> #undo
17:52:53 <openstack> Removing item from minutes: <ircmeeting.items.Agreed object at 0x982a5d0>
17:52:57 <dtantsur> CLEANED too
17:52:58 <devananda> #agreed implement the INSPECTED state transition using a no-op for now, to allow it to be extended by drivers later on
17:53:04 <rloo> wouldn't we want to do a similar thing for all *ED states?
17:53:04 <dtantsur> I was asking about it as well IIRC :)
17:53:06 <lucasagomes> sounds like it's *ED states
17:53:11 <devananda> rloo: yep
17:53:18 <devananda> #undo
17:53:19 <openstack> Removing item from minutes: <ircmeeting.items.Agreed object at 0x982aa50>
17:53:26 <devananda> #agreed implement all the *ED state transition using a no-op for now, to allow it to be extended by drivers later on
17:53:29 <devananda> hehe
17:53:32 <lucasagomes> +1 :)
17:53:58 <NobodyCam> :-p
17:54:07 <wanyen> +1
17:54:17 <devananda> NobodyCam: as far as "how and when do we bump the API microversion" -- I think that would be a good wiki page
17:54:34 <lucasagomes> developer doc maybe?
17:54:44 <NobodyCam> Five minutes left
17:54:47 <NobodyCam> :) ++
17:54:49 <devananda> lucasagomes: maybe? let's start on wiki to iterate more quickly
17:54:58 <lucasagomes> wiki is good but not sure if many people look at it
17:55:11 <lucasagomes> in the dev docs we have things like how to create a vendor passwhtru method etc
17:55:14 <mrda-sfo> I think wiki sounds good
17:55:17 <devananda> especially if rloo is going to encourage us to use a decorator rather than the functional checks I implemented
17:55:18 <NobodyCam> if its there we can reffer (point) folks to it
17:55:19 <lucasagomes> devananda, ah right, like a draft?
17:55:20 <lucasagomes> ok
17:55:24 <devananda> lucasagomes: right
17:55:31 * rloo stays quiet...
17:55:35 <mrda-sfo> but how do we go about reordering, when a patch gets delayed and a later revision lands before the earlier one?
17:55:35 <NobodyCam> :-p
17:55:51 <lucasagomes> cool :)
17:55:56 * lucasagomes assigns the work to rloo
17:55:56 <NobodyCam> mrda-sfo: example?
17:55:58 <lucasagomes> jk :)
17:56:00 <devananda> mrda-sfo: that's going to be tricky. but we have the same challenge with the RPC API
17:56:15 <NobodyCam> oh for versoning
17:56:31 <devananda> when ever there are multiple changes affecting either RPC or micro API, those authors will need to, you know, talk with each other to coordinate
17:56:39 <mrda-sfo> So if logical name got delayed, and 1.6 needed to land...
17:56:53 <devananda> and coordinate with some core reviewers about what order to land them in
17:57:00 <devananda> it's not a perfect system ...
17:57:07 <rloo> mrda-sfo: you'd have to rebase + update your change.
17:57:11 <devananda> mrda-sfo: also, I'd *really* like logical names to land this week
17:57:11 <lucasagomes> yeah the comments on the top of the version
17:57:17 <mrda-sfo> sure, no probs with that
17:57:21 <lucasagomes> may cause a merge failed (I expect it too)
17:57:28 <mrda-sfo> it's just managing the change on a wiki or whatevs
17:57:31 <NobodyCam> we could also patch both conflicting patches to swap the version # if needed
17:57:37 <lucasagomes> since the descriptions of what was added are different across diff patches
17:57:42 <rloo> how do users know what is in which version?
17:57:52 <mrda-sfo> devananda: Should be fine now, thanks to your fix :)
17:57:53 <devananda> rloo: we document it in release notes
17:58:11 <devananda> rloo: is there a more discoverable way via the API ?
17:59:06 <rloo> devananda: I don't know. Was wondering. Can't remember if the spec mentioned anything about that.
17:59:16 <devananda> rloo: there's nothing in the nova spec about that, fwiw
17:59:37 <rloo> maybe need to enhance the error to add more details like the version
17:59:47 <devananda> clients can discover the min and max supported version, and clients should be written to expect the behavior according to the version they will request
17:59:48 <mrda-sfo> I think macking the mapping of revisions to a short description of the new functionality is going to be important
17:59:50 <devananda> which reminds me
17:59:53 <rloo> well, that is only useful if you know of a feature
17:59:54 <mrda-sfo> s/macking/mapping/
17:59:56 <devananda> we need to land support for version headers in our client :)
18:00:01 <NobodyCam> Beep * Times up
18:00:04 <devananda> yup!
18:00:09 <devananda> thanks all! -- see some of you soon
18:00:13 <devananda> #endmeeting