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