17:00:04 <jroll> #startmeeting ironic
17:00:06 <openstack> Meeting started Mon Jan  9 17:00:04 2017 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:07 <aslezil> o/
17:00:07 <jroll> ohai!
17:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:08 <dtantsur> o/
17:00:09 <zhenguo> o/
17:00:10 <openstack> The meeting name has been set to 'ironic'
17:00:15 <NobodyCam> o/
17:00:29 <joanna> o/
17:00:30 <lucasagomes> o/
17:00:33 <rpioso> o/
17:00:33 <ricardoas> o/
17:00:42 <rloo> o/
17:00:44 <jlvillal> o/
17:00:45 <baha> o/
17:00:46 <jroll> as always, we have an agenda:
17:00:51 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:00:52 <mjturek> o/
17:01:02 <jroll> #topic announcements and reminders
17:01:10 <jroll> first meeting of 2017, happy new year everyone :)
17:01:15 <mjturek> happy new year!
17:01:19 <jroll> couple things:
17:01:30 <jroll> #link https://releases.openstack.org/ocata/schedule.html
17:01:34 <jroll> lots of deadlines coming up
17:01:40 <jroll> client release freeze next week
17:02:06 <jroll> er, library freeze
17:02:08 <rloo> jroll: isn't it the week after next?
17:02:10 <jroll> feature freeze the week after (and requirements freeze, client freeze etc)
17:02:22 <rloo> jroll: :)
17:02:41 <milan> o/
17:02:42 <jroll> we still tend to merge features post-feature-freeze, but need to keep it in mind for things that affect nova and such
17:02:57 <bfournie> o/
17:03:04 <jroll> our final release deadline for ironic and inspector is R-1 (feb 13-17)
17:03:17 <jroll> and PTG is feb 20-24, hope everyone will be there
17:03:26 <rloo> jroll: for any ironic-nova feature changes, nova will only accept them til week of Jan 23, right?
17:03:32 <jroll> on that note, we've started planning topics for the PTG:
17:03:33 <JayF> o/
17:03:34 <jroll> #link https://etherpad.openstack.org/p/ironic-pike-ptg
17:03:39 <jroll> rloo: correct
17:03:49 <jroll> preferably earlier
17:03:58 <rloo> jroll: ++
17:04:51 <jroll> and I think my last announcement, if you haven't read the ML, is that I won't be running for PTL next cycle
17:05:20 <jroll> so please step up and run if that's a thing you'd like to do, I'm happy to help anyone running and will certainly help whoever gets the position
17:05:22 <jroll> :)
17:06:01 <jroll> anyone have other announcements?
17:06:22 <davidlenwell> o/
17:06:29 <dtantsur> I'll say it several times before end of Ocata, but as you mentioned it: you're an awesome PTL jroll, thanks :)
17:06:30 <jlvillal> Python 3 experimental job added :)
17:06:41 <jlvillal> Thanks to jroll
17:06:41 <jroll> dtantsur: thank you :)
17:06:43 <jroll> jlvillal: ++
17:07:01 <jroll> I hope to get that to non-voting soon but I think swift may have some problems, per the ML
17:07:03 <jlvillal> +1 on what dtantsur said!
17:07:34 <jroll> :)
17:07:40 <jroll> ok if nothing else, I'll move on
17:07:44 * jroll waits for a few
17:08:26 <jlvillal> Yeah the Swift phase it where it died
17:08:52 <jroll> right on
17:08:56 <jlvillal> s/it where/is where/
17:08:58 <jroll> #topic subteam status reports
17:09:03 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:09:13 <jroll> starts around line 101
17:09:24 * jroll gives folks a few minutes to review
17:09:41 <jroll> I think our top priority right now will be attach/detach, since we have some nova stuff hanging on that
17:09:55 <jlvillal> Oh, I think our gate is working again. Not sure if any known issues at this moment. I believe stable/newton is working and testing now.
17:10:14 <jroll> +1, thanks jlvillal
17:12:41 <rloo> JayF: can you update the rescue mode status?
17:12:52 * JayF on it
17:13:34 * jroll is proposing priorities
17:13:39 <jroll> looks like things are moving along nicely
17:13:47 <jlvillal> Should there be a Python 3 section?
17:13:48 <rloo> yay, notifications are DONE!
17:13:52 <mariojv> \o/
17:13:54 <jroll> I had to report up status on a bunch of our cycle priorities last week and I was very pleased :)
17:14:02 <dtantsur> notifications \o/
17:14:16 <jroll> jlvillal: nah, not a priority, just trying to get the ball rolling. next cycle it will likely be a cross-project goal and we'll add it then
17:14:32 <jlvillal> Ah okay. I'm glad we are ahead of the curve then :)
17:14:54 <jroll> jlvillal: or just finding out how behind the curve we are :D
17:15:13 <rloo> jroll: wrt ironic-neuton interactions, now that the weekly meetings are no more, do you want to add a subteam for that?
17:15:14 <jlvillal> Inconceivable!
17:15:26 <lucasagomes> heh glass half empty or half full :-)
17:15:28 <jroll> rloo: porgroups and attach/detach should cover it
17:15:37 * jlvillal realizes that probably makes no sense to people who haven't watched "The Princess Bride"
17:15:59 <rloo> jroll: ok, that works for me
17:16:12 <JayF> rloo: updated, that was very out of date
17:16:13 <rloo> jlvillal: true, but inconceivable
17:16:17 <JayF> rloo: my apologies
17:16:25 <rloo> JayF: no worries, thx for updating!
17:17:01 <jlvillal> :)
17:17:04 <jroll> ok, I've got review priorities proposed, any questions/comments on those or do they look ok?
17:17:40 <rloo> jroll: are we hoping to get nova attach/detach only, and/or nova portgroups done too?
17:17:52 <jlvillal> How many more driver composition patches are likely left? /me curious
17:18:01 <rloo> jlvillal: gazillion :)
17:18:05 <jroll> rloo: both, they're fairly simple
17:18:08 <dtantsur> jlvillal, I have rough estimate in the white board
17:18:09 * jlvillal was afraid of that... :)
17:18:10 <jroll> jlvillal: >1
17:18:12 <jroll> :)
17:18:24 <rloo> jroll: ok, would be good to mention the portgroups stuff as eg 2 in priority?
17:19:03 <jroll> rloo: not opposed to that
17:19:08 <jlvillal> dtantsur: I must be blind but I didn't see an overall estimate. Unless that is listing all of them and there are like 3 more?
17:19:39 <dtantsur> jlvillal, items under "next steps" are my estimates for big bits for Ocata
17:20:02 <jlvillal> dtantsur: Oh cool, so three big things left. Thanks :)
17:20:33 <rloo> the code freeze for libraries (ironic-lib) is next week; are there any patches that we need to look at?
17:20:44 <JayF> There is a bugfix in review right now
17:20:48 <JayF> that's pretty worth looking at
17:20:49 <dtantsur> last time I looked there were 3 patches there open
17:21:00 <jroll> JayF: which one?
17:21:12 <dtantsur> all probably need rechecking, one has (procedural?) -2
17:21:14 <jroll> yeah, I see 4, one is old
17:21:15 <rloo> if any of those are priorities maybe we should mention
17:21:28 <JayF> https://review.openstack.org/#/c/417022/
17:21:31 <jroll> they don't look like priorities to me
17:21:40 <jroll> bug fixes are great to get in though
17:21:46 <JayF> this one isn't a feature priority, but a regression bug we introduced this cycle in IPA
17:21:56 <jroll> that one is pretty hairy :D
17:22:00 <jroll> is it a regression?
17:22:21 <jroll> I don't recall yolanda mentioning it worked in the past
17:22:48 <dtantsur> configdrive + whole disk images is relatively new
17:23:00 <JayF> We moved IPA to do configdrive writing via ironic-lib
17:23:04 <JayF> and I know it worked before we did that
17:23:16 <JayF> that move was in this cycle, so I presumed it was a relatively recent regression
17:23:24 <JayF> I haven't bisected it or anything crazy like that
17:23:32 <jroll> oh, could be
17:23:38 <jroll> I know this is iscsi driver
17:23:47 <jroll> so a bit unclear still, but ¯\_(ツ)_/¯
17:23:54 <JayF> I mean, the code is the same for both methods now
17:23:57 <JayF> I believe
17:23:57 <lucasagomes> yeah I not sure if it's a regression
17:23:58 <jroll> a couple folks have been working with yolanda
17:24:07 <lucasagomes> the thing is, yolanda wants to pre-create the configdrive partition
17:24:17 <JayF> lucasagomes: yeah, we used this code downstream
17:24:25 <JayF> lucasagomes: to be able to have a precreated configdrive partition
17:24:26 <lucasagomes> probably we just tested having IPA creating the partition for us at the end of the disk ?
17:24:29 <lucasagomes> JayF, oh right
17:24:30 <JayF> lucasagomes: because of that I'm 1000% sure it used to work
17:24:36 <jroll> lol
17:24:45 <lucasagomes> JayF, hah ok so yeah seems like a regression
17:24:48 <JayF> lucasagomes: and the only time that code has changed in recent memory is the change to do configdrive writing via ironic-lib
17:25:12 <lucasagomes> it could be related to the version of blkid tool as well ? Cause I tested on xenial and I can confirm that the command didn't work
17:25:22 <jroll> let's continue this in channel or open discussion
17:25:25 <jroll> please :)
17:25:26 <lucasagomes> right on
17:25:31 <jroll> anything else on subteam reports?
17:25:36 <JayF> lucasagomes: very possible, but yeah, I see it as an important bug to fix before freeze :)
17:25:42 <lucasagomes> JayF, ++
17:25:57 * jroll added ironic-lib patch queue to priorities
17:26:33 <jroll> okay, one discussion topic today
17:26:39 <jroll> #topic Policy for deprecating metric names
17:26:44 <jroll> #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/109580.html
17:26:45 <mariojv> hi - that was one i suggested
17:26:51 * jroll hands mic to mariojv
17:27:02 <mariojv> the question about having a deprecation policy for metric names was brought up in response to this patch
17:27:05 <mariojv> #link https://review.openstack.org/#/c/412339
17:27:10 <mariojv> essentially, we don't have any consistent policy for metric names for users of the feature
17:27:15 <mariojv> so if we have a decorator @METRICS.timer('my_module.MyClass.my_func') for a function named my_func, and we change that function's name to "foo"
17:27:20 <mariojv> there's a question about whether we change the name to "my_module.MyClass.foo", or do something else
17:27:21 <JayF> mariojv: I think simply a release note notifying the value has changed is sufficient. I am very much against the suggestion of doing multiple metrics as a transition period.
17:27:32 <mariojv> JayF: +1
17:27:45 <lucasagomes> yeah, I hardly can think of a way to have deprecation on changing method's name
17:27:53 <mariojv> i think we should also start documenting individual metrics and what they're supposed to mean, and keep that up to date
17:28:09 <JayF> mariojv: I think that's a slippery, and dangerous slope
17:28:10 <mariojv> otherwise operators need to be familiar with the internals of the codebase for them to be useful
17:28:24 <mariojv> JayF: why? too many metrics?
17:28:25 <lucasagomes> perhaps keeping sending two notifications with the different names at the same time ? But, nothing that I can think of seems to solve the problem gracefully
17:28:31 <JayF> mariojv: It's going to be borderline impossible to create that document, organize it in a sane way, and ensure it stays up to date
17:28:44 <JayF> lucasagomes: very -1, that's a bad idea because of how much more storage it can cause on the metrics backend
17:28:46 <mariojv> lucasagomes: the problem with that is the policy falls apart if a function is removed
17:28:47 <rloo> mariojv: there are a lot of metrics to be documenting, if there was some way to generate that doc from the files, i'd be ok with that
17:28:49 <mariojv> and the storage thing
17:28:58 <rloo> mariojv: i wonder if we should have some xproject discussion about metrics
17:28:58 <JayF> lucasagomes: it's a relatively trivial operational task to combine the old+new metric names if a deployer wishes
17:29:08 <JayF> rloo: ++ agreed, I'm only onboard for it if it's generated
17:29:09 <lucasagomes> mariojv, right, but if it's removed we won't care about the metrics for it anymore right ?
17:29:14 <lucasagomes> JayF, right
17:29:21 <mariojv> i think it could be generated - just the meanings of each metric would be the work
17:29:30 <lucasagomes> JayF, mariojv would be feseable to create the document for the metrics from code ?
17:29:39 <lucasagomes> like having a parser for the decorators which auto-generates it ?
17:29:39 <mariojv> rloo: not sure about the xproject discussion, i don't think many other projects have metrics the way we do
17:29:41 <mariojv> maybe swift
17:29:44 <JayF> I think it's more effort than it's worth, to be honest
17:29:49 <JayF> to document each one individually
17:29:58 <mariojv> lucasagomes: yes, you could do that
17:30:04 <JayF> there's a false impression that an operator will use these metrics to ask specific questions
17:30:20 <JayF> ime, I much more often used these metrics, and similar ones, to track down unforseen issues
17:30:32 <mariojv> maybe the effort ought to be scoped before dismissing it outright - tbh, i have not counted how many there are
17:30:34 <JayF> i.e. "why is my api slow?" then look for metrics with large deltas indicating a performance change
17:31:18 <jroll> so there's a lot of good questions here, but let's focus on process for changing one
17:31:25 <jroll> I think I'm fine with just a release note
17:31:35 <rloo> so if metrics stuff doesn't fall under the whatever policy of deprecations, then let's just rename or whatever.
17:31:40 <jroll> and maybe add to metrics docs that these may change with only a release note
17:31:40 <JayF> I think to change one, you should simply need a release note under upgrade noting it's moved, the name has changed
17:31:44 <mariojv> I'm fine with that too jroll
17:31:49 <jroll> also add that to dev docs
17:31:49 <JayF> +1
17:31:54 <lucasagomes> yeah I'm good with it too
17:31:55 <lucasagomes> seems sane
17:32:06 <rloo> ++
17:32:15 <lucasagomes> we can document that names for the metrics could change at any time to alert operators
17:32:15 * rloo senses a vote coming up. goodie.
17:32:23 <jroll> cool, any objections?
17:32:36 * jroll hates votes, let's just see if anyone hates it
17:32:57 <jroll> while we wait, who wants to write those docs?
17:33:03 <mariojv> i'll do it
17:33:03 * rloo likes votes, it is so democratic :)
17:33:10 <jroll> perfect, thanks mariojv
17:33:38 * jroll reserves his thoughts on democracy
17:33:41 <lucasagomes> rloo, :-) seems we don't need to vote
17:33:47 <jroll> ok if nobody objects let's just do it
17:33:48 <rloo> ha ha.
17:33:54 <jroll> any later objections can happen in gerrit
17:34:00 <jroll> thanks for bringing it up, mariojv
17:34:02 <rloo> mariojv: you didn't get any replies from the ML so this decision should be fine
17:34:03 <mariojv> ty
17:34:08 <mariojv> yeah
17:34:19 <jroll> oh yeah, we should post back to the ML what we decided
17:34:30 <jroll> alright, moving on
17:34:33 <jroll> #topic open discussion
17:34:41 <jroll> mriedem left me some announcements here
17:34:49 * jlvillal is slightly disappointed that #undo wasn't used in this meeting to show off his changes to meetbot :)
17:34:51 <jroll> (mriedem): Status of Ironic driver changes for Nova are in here: https://etherpad.openstack.org/p/nova-ocata-feature-freeze - some of those are close, some are probably not going to make Ocata due to dependencies or inactivity. Here are the changes which look close but need a push on the Ironic side:
17:35:01 <jroll> #link https://review.openstack.org/#/c/364413/ Support Ironic interface attach/detach in nova virt
17:35:04 <jroll> Depends on an Ironic API and client change, but would also unblock the portgroups change(s) on the Nova side.
17:35:06 <jroll> #link https://review.openstack.org/#/c/407977/ ironic: Add soft power off support to ironic driver
17:35:08 <jroll> Depends on an Ironic client change, the Ironic API change is already merged (v1.27)
17:35:16 <jlvillal> Not sure if that #link worked. With the leading spaces?
17:35:19 <jroll> attach/detach we know about
17:35:21 <jroll> probably not
17:35:25 <jroll> #link https://review.openstack.org/#/c/364413/
17:35:30 <jroll> #link https://review.openstack.org/#/c/407977/
17:36:00 <jroll> so I guess we should prioritize this one as well:
17:36:03 <jroll> #link https://review.openstack.org/#/c/357627/
17:36:43 <lucasagomes> the base patch is already merged in Ironic AFAICT
17:36:47 * jroll added to priorities
17:36:50 <jroll> yep
17:37:16 <jroll> just need the client patch, that would be a great feature to get in nova this cycle
17:37:29 <jroll> anything else for open discussion?[
17:37:38 <rloo> well, need client patch and folks to review the nova-related patch :)
17:37:45 <jlvillal> Still seeing that timeout issue on Grenade at times
17:37:53 <rloo> jlvillal: :(
17:38:00 <jroll> jlvillal: yeah, someone put up a patch for that iirc
17:38:01 <JayF> If anyone is in Seattle area and wants to say hello, I'll be giving a talk on systemd at the SASAG meeting on Thursday night.
17:38:03 <jlvillal> Strange I thought it got bumped to 45 seconds
17:38:12 <jlvillal> But I see 30
17:38:14 <jlvillal> http://logs.openstack.org/23/415523/2/check/gate-grenade-dsvm-ironic-ubuntu-xenial/29bdff9/logs/grenade.sh.txt.gz#_2017-01-09_16_24_24_824
17:38:59 <jroll> jlvillal: not yet: https://review.openstack.org/#/c/417406/
17:39:19 <jlvillal> Oh, yeah. We have to go ask for reviews
17:39:24 <lucasagomes> heh
17:40:51 <jlvillal> I did some begging over on #openstack-qa for that grenade patch
17:40:57 <jroll> cool
17:40:59 <jroll> anything else?
17:41:07 <phuongnh> Hi, for Additional capabilities discovery for iRMC driver feature, I have uploaded a spec here: https://review.openstack.org/#/c/409044/
17:41:25 <phuongnh> folks, if you have few minutes mind taking a look at it, thanks
17:41:54 <lucasagomes> phuongnh, I think Nisha_Agarwal just pointed me earlier on to a similar spec ?
17:42:00 <jroll> phuongnh: I'd love for you to work with Nisha_Agarwal and https://review.openstack.org/#/c/338138/
17:42:02 <lucasagomes> https://review.openstack.org/#/c/338138
17:42:06 <lucasagomes> yeah
17:42:07 <jroll> lucasagomes: ++
17:42:19 <phuongnh> thanks, I will do that
17:42:22 <Nisha_Agarwal> lucasagomes, jroll Thank you :)
17:42:30 <lucasagomes> we should try to make it as generic as possible
17:43:04 <Nisha_Agarwal> :) yes sure
17:43:07 <jroll> yep
17:43:13 <jroll> and nisha already covered some of these
17:43:48 <Nisha_Agarwal> jroll, now the spec is generic. I would love to see the comments from reviewers
17:44:18 <jroll> Nisha_Agarwal: agree, I meant to bring it up here actually
17:44:25 <Nisha_Agarwal> :)
17:44:25 <jroll> I think it's probably ready, I haven't reviewed in full though
17:44:26 * dtantsur was out of internet for a while
17:44:50 * Nisha_Agarwal also thinks the same :)
17:45:11 <jroll> dtantsur: do you have anything for open discussion?
17:45:52 <dtantsur> nope
17:45:57 <jroll> cool
17:46:01 <jroll> thanks y'all
17:46:03 <jroll> #endmeeting