17:00:00 #startmeeting ironic 17:00:00 Meeting started Mon Mar 20 17:00:00 2017 UTC and is due to finish in 60 minutes. The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:01 \o 17:00:02 \o 17:00:03 o/ 17:00:04 The meeting name has been set to 'ironic' 17:00:05 o/ 17:00:08 o/ 17:00:09 o/ 17:00:12 o/ 17:00:15 o/ 17:00:18 o/ 17:00:21 o/ 17:00:26 O/ 17:00:40 o/ 17:00:46 hi everyone! thanks for coming :) 17:00:47 O/ 17:00:56 our agenda as usual can be found here: 17:01:00 #link https://wiki.openstack.org/wiki/Meetings/Ironic 17:01:18 #topic Announcements / Reminders 17:01:31 #info ironic-{core, release} groups were added to sushy-{core, release} groups respectively 17:01:39 o/ 17:01:40 more raw fish for all of us :) 17:01:43 thanks lucasagomes! 17:01:45 o/ 17:01:48 o/ 17:01:49 \o/ 17:01:53 I don't think I have any announcements. anyone? 17:01:58 dtantsur: i just added stuff to the agenda 17:02:02 two announcements 17:02:11 rloo is retiring from subteam-status-report duty; rama_y (Ramamani Yeleswarapu) has kindly agreed to take over. Thanks rama_y! 17:02:18 #info rloo is retiring from subteam-status-report duty; rama_y (Ramamani Yeleswarapu) has kindly agreed to take over. Thanks rama_y! 17:02:21 thanks rama_y 17:02:21 * jroll has nothing 17:02:33 #info new ironic liaisons: JayF for i18n; Rushil Chugh for oslo; soliosg (Solio Sarabia) for logging working group 17:02:39 o/ 17:02:41 Thanks, rloo! 17:02:41 o/ 17:02:47 woot 17:02:48 thanks a lot! please don't forget to update the etherpad before meeting, if you have something to bring up 17:02:57 thanks for volunteering for liaison, JayF crushil soliosg 17:03:09 thanks rama_y, JayF, crushil, and soliosg! 17:03:16 o/ 17:03:25 o/ 17:03:27 o/ 17:03:33 np mariojv rloo 17:03:40 anything else? 17:03:41 o/ 17:03:44 o/ 17:04:09 #topic Review subteam status reports 17:04:21 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:04:30 starting with line 97 17:04:59 \o/ @ standalone tests 17:04:59 for the OSC API versioning, rescue mode, and specific fault support priorities, i updated to the best of my ability even though i was away last week 17:05:10 please feel free to correct anything that's inaccurate 17:05:25 jay's away at least part of this week iirc 17:05:26 vsaienk0: for standalone CI tests, is this the next patch that needs reviewing? https://review.openstack.org/#/c/437549 17:05:31 o/ 17:06:49 o/ 17:07:19 jlvillal: wrt multinode grenade testing. Yay! is there a description somewhere that describes what is being tested? 17:07:35 rloo: yes 17:08:12 vsaienk0: thx, i updated the etherpad :) 17:09:18 rloo: I don't think so. Basically it is iron 17:09:32 jlvillal: ok, will talk to you later about that 17:09:33 rloo: I don't think so. As far as docs 17:09:48 vsaienk0, sambetts_. what's the status wrt the network related stuff? 17:10:15 vsaienk0, sambetts_: post-deploy VIF attach/detach, pyhsical network awareness, routed networks support? 17:10:17 i'd be curious about that too rloo - specifically links to things to review on the whiteboard would be great 17:11:21 rloo: post-deploy VIF attach - need review https://review.openstack.org/#/c/424723/ 17:11:21 wrt the IPA versioning, i think the question was whether to use the ipa version, or add REST API versioning... 17:12:01 physnet awareness: I'm working on initial patch with devstack plugin/basic documentation to networking-baremetal 17:12:08 I don't know if we need to meet/decide on that or not (IPA versioning). maybe we can wait for sambetts_ to ask... 17:12:49 rloo: pass portgroup information to Neutron spec: https://review.openstack.org/#/c/415003/ code: https://review.openstack.org/446763 17:13:05 eeek, I forgot a small announcement 17:13:16 #info dtantsur is on PTO the next week (Mar 27 - Mar 31) 17:13:35 eeekkk, too late, dtantsur. you can't go on PTO :) 17:13:40 :D 17:13:48 :-) 17:13:51 can somebody please chair the meeting? 17:14:02 isn't there a spec for physical network? 17:14:29 rloo: I've seen one 17:14:36 * mariojv tries to find link 17:14:50 found it: https://review.openstack.org/#/c/435781/ 17:14:51 rloo: https://review.openstack.org/435781 17:14:54 ty 17:14:57 :'( 17:15:09 we're a bit past time for reviewing the status updates. how much time do folks still need? 17:15:21 dtantsur: i'm still reading/reviewing. too much stuff... 17:16:04 #info Please provides status updates on https://etherpad.openstack.org/p/IronicWhiteBoard *before*, not *during* the meeting 17:16:14 when we started doing subteams, I wasn't imagining this many subteams 17:16:32 this is totally too much for 10 minutes of meeting time 17:16:43 agreed 17:16:59 jroll: wrt nova. is it time to update our documentation about node.resource_class? :) 17:17:07 soliosg, I guess we should remove ironic-inspector-tempest-plugin, right? 17:17:14 (then again, I'm surprised we have so many priorities, too) 17:17:28 i hope you all saw that there is no need for i18n wrappers for log messages. 17:17:36 rloo: getting there yeah, I figure I'll get the upgrade path(s) approved and then write the docs all at once 17:18:03 jroll: great. the traits stuff will be interesting! 17:18:12 indeed :) 17:18:33 dtantsur: oh, so will we unify both tempest plugins (ironic and ironic-inspector) into the one in new repo? 17:18:35 dtantsur: can we discuss i18n now, or later? 17:19:02 dtantsur: wrt going forward, i want to make sure. we don't want i18n wrappers any more, so no _LE, _LW... 17:19:14 except for user-facing stuff 17:19:27 yeah, reading now, but let's move it to the discussion 17:19:32 dtantsur: ok 17:19:47 soliosg, yeah, that's the outcome from the PTG 17:20:15 dtantsur: ok, will add that to the whiteboard 17:20:33 jroll & rloo: how does traits handle backward compatibility? 17:20:35 ready to move on? 17:20:42 wanyen, let's please not discuss it here and now 17:20:51 * mariojv is ready to move on 17:20:52 wanyen: i think that's where the brainstorming comes into play. dunno. 17:20:53 ++ to move on 17:20:56 #topic Deciding on priorities for the coming week 17:21:08 we cleared 2 items 17:21:08 dtantsur: ok 17:21:24 for this, if any of rescue, fault support, or OSC API versioning are going to be prioritized, i'd recommend doing only 1 of them at a time for now 17:21:32 rescue's probably the most far along 17:21:52 Nice job getting two items from last week done :) 17:21:59 I'll update the cinder API patch today, I think it should remain on the list 17:22:00 mariojv, so, what would you suggest to take? 17:22:00 ++ gj 17:22:06 dtantsur: rescue 17:22:10 joanna, ++ for keeping BFV 17:22:21 as to redfish, I'd like to replace it with the spec update that lucasagomes posted 17:22:25 dtantsur: awesome 17:22:37 dtantsur, yeah sounds good to create consensus on that 17:22:40 i consolidated all the code links into a link to the topic 17:22:52 for any needing rebase/updates, i will update this week 17:22:53 now that we have some standalone tests, when do we remove those equivalent non-standalone tests? 17:23:32 I guess we want to watch them for a week or two, then remove 17:23:49 something like that.. also a topic for later discussion, I think 17:23:52 and make the standalone voting 17:24:04 vdrok: ok, so we want to get as many standalone tests working, so we can remove the others soon 17:24:12 yup 17:24:19 dtantsur: only asking to see if those patches or patch is a priority :) 17:24:40 ah 17:24:46 yeah, I think we should wait a bit 17:25:13 mariojv, what's the next rescue patch or a couple of patches we can pile on 17:25:14 ? 17:25:27 * mariojv looks 17:25:48 api isn't it? 17:25:54 dtantsur: https://review.openstack.org/#/c/350831/32 and https://review.openstack.org/#/c/353156/14 will be manageable 17:26:02 lucasagomes: yep 17:26:08 lucasagomes: the rescuewait timeout is a small change 17:26:10 if sambetts_ is not around, I'd kick IPA versioning probably... 17:26:11 * rloo is fine if there aren't many priorities of the week... 17:26:14 which is the 2nd one i suggested 17:26:15 mariojv, ++ 17:26:26 i'll move updating those up on my todo list 17:26:30 dtantsur: +1 17:27:10 feel free to remove /32 and /14 from those links 17:27:13 so it goes to the latest patch sets 17:27:17 mariojv, are we really ready to review API already? 17:27:51 dtantsur: imho yes, there are some things to update now that we had reviews last week 17:28:14 ok 17:28:19 had a +2 for a nice second there :) 17:28:28 last candidate: client changes for driver comp? 17:28:54 if they look ready +1 17:29:10 (or close to ready) 17:29:13 https://review.openstack.org/#/c/419274/ is close 17:29:14 * lucasagomes == jroll 17:29:21 #define lucasagomes jroll 17:29:23 need to get that out of the way 17:29:27 lol 17:29:33 poor lucasagomes :P 17:29:42 ok, 5 items. how does it look? 17:29:51 I mean, same opinion, if it looks ready I would include it 17:30:13 * dtantsur guessed, but still :) 17:30:13 dtantsur, lgtm 17:30:14 lgtm 17:30:15 I'm fine with it 17:30:23 LGTM 17:30:35 I hope we start getting networking things in there, so we don't rush them all in at the end 17:30:41 i'm glad we have the client patch since those get less attention in general 17:31:02 jroll++ 17:31:10 mariojv++ 17:31:12 :) 17:31:19 ok, I guess we can move on.. 17:31:29 #topic Appointing a bug liaison for the next week 17:31:49 mjturek, are you enjoying it? :) 17:31:56 any volunteers this time? 17:32:05 dtantsur: definitely! if someone wants to give it a go that's fine too 17:32:15 https://etherpad.openstack.org/p/ironic-bug-triage 17:32:34 #link https://etherpad.openstack.org/p/ironic-bug-triage the current bug triaging effort etherpad 17:32:49 thanks mjturek! I don't see other volunteers, soo :) 17:33:00 dtantsur: sure I'll do another week :) 17:33:03 #action mjturek to continue to look after our bug list 17:33:31 no discussion items, so I'm opening the floor 17:33:31 thank you mjturek :) 17:33:35 #topic Open discussion 17:33:40 np jroll :) 17:34:08 dtantsur: I had put an item here about a bug I saw 17:34:12 wanyen: to answer your question, the traits work won't happen until queens. there isn't a plan yet, we're still brainstorming. there will be an upgrade path that won't require downtime, but may require operator action. 17:34:24 #link https://bugs.launchpad.net/ironic/+bug/1672457 issue reported by Red Hat scale folks about ironic-conductor performance with time 17:34:24 Launchpad bug 1672457 in Ironic "Ironic Conductor performance trends down with uptime" [Medium,Confirmed] 17:34:32 I added an item there regarding a comment from JayF in the redfish driver (https://review.openstack.org/#/c/438982/11/ironic/drivers/modules/redfish/utils.py L48) 17:34:36 wanyen: (the operator action will likely be updating flavors) 17:35:02 I have 2 questions 17:35:02 current the spec as only 1 option for the SSL cert verification, TheJulia proposed having two 17:35:12 jroll: thanks! I have a few questions regarding traists. 17:35:29 but still... not sure how people would prefer that. So if you have a time to look at the comment and weight it would be great 17:35:34 * dtantsur is not sure we should discuss Queens traits now... 17:35:39 wanyen: sure, feel free to ask me in channel or send me an email 17:35:47 s/channel/ironic channel/ 17:35:48 lucasagomes, I'd stick with what python-requests accepts 17:36:00 cores, I'd like another review on https://review.openstack.org/#/c/386014/ it has one +2 and avoid oneview drivers to break due problems when allocating a node on oneview 17:36:01 dtantsur, right, and just document it better ? 17:36:02 but two options also sound good 17:36:03 :) 17:36:06 Which topic are we on? Did we finish with the performance one? 17:36:11 pas-ha added one thing to https://etherpad.openstack.org/p/ops-adopt-a-project-pike 17:36:12 lucasagomes, if people feel like 2 options are cleaner, I'm also fine 17:36:15 desired response code in case API is not available in specified version is 405, right? 17:36:22 dtantsur: i'm wondering if the perf issues can be reproduced with ocata, since those stats were from newton 17:36:22 dtantsur, right on 17:36:26 jlvillal: not yet, waiting for it to die down a bit 17:36:28 jlvillal, I think we mixed everything 17:36:29 jlvillal, that was just info, I don't think we can fix it here and now 17:36:31 also wondering if default config options for # periodic task workers was used 17:36:50 dtantsur: fair enough, was wondering if it's cause for concern 17:36:56 joanna: 406 or 404 17:36:58 joanna, whatever is NotAcceptable. except for new endpoints, we return 404 for them. 17:37:02 jlvillal, but the performance one seems interesting, justin works for RH and he's doing a lot of performance tests with ironic (and other projects) 17:37:16 vdrok, dtantsur: thanks! 17:37:21 mariojv, you may ask jkilpatr on #openstack-ironic 17:37:28 ok 17:37:35 Yeah. Just I was getting slightly confused as appeared three maybe four things being discussed at the same time. 17:37:36 yes, let's not debug performance issues in the meeting :P 17:37:53 #info please keep updating https://etherpad.openstack.org/p/ops-adopt-a-project-pike 17:37:54 I'd like to get some reviews on https://review.openstack.org/#/c/377106/ , I already answered vdrok questions 17:38:02 I was also wondering why do we keep sample config in the repo? 17:38:08 jroll: ok. Thanks! The nova os_traits said that it addresses the problem for host aggregate. However, based on my understanding host aggregate does not support Iornic yet. 17:38:10 dtantsur: are there some graphs related to memory? I saw only cpu there 17:38:12 vdrok: ++ for pas-ha's comments on that etherpad 17:38:21 joanna, just as a reference ? 17:38:28 vdrok, please ask jkilpatr in the channel 17:38:28 wanyen: let's not discuss in this meeting, we can talk in #openstack-ironic or email 17:38:39 I actually find it useful, specially when liking people about a certain config option 17:38:42 jroll: ok. 17:38:44 joanna: operator friendly reference 17:38:46 vdrok: i moved the convo to #openstack-ironic 17:38:56 joanna, but no big reason other than that *I think* 17:39:16 ++ 17:39:24 I thought it was because the people that like in-repo config won that game of rock paper scissors 17:39:24 ok. I'm just not used to keeping generated files in the repo as they're ususally hard to maintain 17:39:43 but I suppose it's good if an operator can look it up on github, right? 17:39:46 yeah, it's a trade-off 17:39:57 i personally find the sample config useful 17:39:58 yep, you can link to a specific line, etc 17:40:07 joanna, right 17:40:10 i don't think it is just on github; i thought those .sample files were packaged too 17:40:10 joanna: the main thing is that the tox target to generate it requires all dependencies. which means you need postgres dev headers, numpy, and all sorts of related crazy 17:40:12 it is a bit annoying when it's out of date, but to me that annoyance cost is outweighed by the benefits 17:40:19 dtantsur: Any news on Dell CI? I was reminded as I noticed it said -1 to my patch ;) 17:40:26 dtantsur, jroll , lucasagomes, TheJulia, mariojv: thanks 17:40:43 jlvillal, I did not get to chatting with folks. I remember it was not completely red, but I need to estimate it. 17:40:48 dtantsur: Thanks. 17:41:24 rloo, right, we do package them: https://github.com/rdo-packages/ironic-distgit/blob/rpm-master/openstack-ironic.spec#L122 17:41:44 dtantsur: i think that is the most value for generating it! 17:42:07 yep, it helps 17:42:09 jlvillal, dtantsur: I'm checking on the Dell CI. 17:42:14 re https://etherpad.openstack.org/p/ops-adopt-a-project-pike, the goal is I guess increasing "project maturity". one of the items there is number of SDKs, do we want to have more than 2? 17:42:21 rpioso: Awesome. Thanks :) 17:42:32 rpioso, thanks! please make sure to have an up-to-date HTTPS certificate, btw :) this is a common problem. 17:42:42 and if so, which ones are in more priority out of those listed on the sdk wiki 17:42:44 jlvillal: Which patch, please? 17:42:53 vdrok, how many of folks here have a pet SDK? :) (I have) 17:43:02 jroll: there are still a few resource provider and os_trait email chains that I would like to follow, so I will discuss this topic with you in a few days. 17:43:07 * jroll thinks the SDK metric is totally bogus 17:43:11 jroll++ 17:43:25 dtantsur: hah, just add it here https://wiki.openstack.org/wiki/SDKs, we'll get +1 :) 17:43:44 rpioso: Most of them ;) But here is one: https://review.openstack.org/445636 17:43:56 vdrok, no ironic yet, a barely started with compute :D 17:44:00 dtantsur: ty for the suggestion. 17:44:26 jlvillal: :-( Thank you! 17:44:36 rpioso: http://ci-watch.tintri.com/project?project=ironic&time=7+days I see a lot of red red red red red .... 17:45:25 HPE and Fujitsu appear to be in the same situation. 17:45:36 jlvillal: pkvmci is broken too 17:45:43 haven't had a ton of time to debug 17:45:45 jlvillal: We'll look into it. 17:45:52 Thanks 17:46:24 we should start improving our 3rdparty CI situation 17:46:24 wanyen: okay, please read and figure out what "traits" means, I suggest to start with: http://specs.openstack.org/openstack/nova-specs/specs/pike/approved/resource-provider-traits.html 17:46:39 wanyen: and realize that I don't have a solid plan yet, and I probably still won't have a plan when we talk :) 17:47:06 with percentage of false negative not an order of magnitude more than one of our regular CI :-/ 17:47:25 dtantsur: ++ 17:47:45 I'd even suggest to have some goal, and assess it by end of Pike 17:47:52 and maybe make some sad decisions ;) 17:48:03 jroll, I have read the spec that you mentioned that's why I have some questions. No rush since it's for Queen. 17:48:25 wanyen: cool, I'm ready to chat whenever you are, let me know :) 17:48:38 jroll: ok. Tx 17:48:54 * dtantsur hopes his comments on 3rdparty CI were noted 17:49:06 dtantsur: I noted them :P 17:49:10 could use an #info 17:49:17 dtantsur: # info it? 17:49:22 yeah, gimme a second 17:49:24 dtantsur: i was waiting to hear what the goals were first :) 17:49:37 rloo, I don't have them, but I will soon(ish) 17:50:11 dtantsur: okey dokey 17:50:14 #info we expect 3rdparty CI to be comparably reliable to our regular CI. dtantsur plans on assessing each CI performance by the end of Pike. 17:50:39 rloo, I'm still planning on a tool to get statistics out of gerrit 17:50:45 given numbers, I can make proposals 17:50:47 thank you dtantsur, that'll be useful 17:50:47 And if they aren't, they can be removed along with their driver. 17:50:50 dtantsur: please add to that, what we decided in previous cycle, about 3rd party CI expectations 17:50:59 sure, I need to review it 17:51:51 anything else? 17:52:24 * dtantsur waits a minute more 17:52:33 about ^^ ? no. did we want to discuss i18n of log msgs? I can discuss with you later if you want. 17:52:34 Did we discuss the i18n thing? 17:52:47 no, I forgot about it 17:53:01 rloo, so, is it official now? I could not figure out from the mail thread? 17:53:04 is there anything to discuss? 17:53:09 dtantsur: yeah it is official. 17:53:13 dtantsur: nova is removing them already, so yeah 17:53:14 two things to discuss i think. 17:53:14 jroll, rather to announce 17:53:36 1. starting now, should we remove/not approve any patches with i18n'd log msgs? 17:53:45 #info OpenStack stops translating logs. we will remove translation markers around them soon. 17:53:49 nova already deleted *.po files from their project 17:54:05 rloo: I guess not only logs but exceptions too? 17:54:15 vdrok, exceptions may propagate to users 17:54:17 2. someone (s) is bound to submit patches removing the i18n calls. i'm concerned about big patches, causing rebases of other patches. 17:54:23 i'd suggest that we only start refusing patches with _() after the removal happens 17:54:32 they disabled the hacking job's check for translations as well. Not sure if we have one too 17:54:34 vdrok: not clear about exceptions, they could be userfacing. 17:54:44 mariojv++ 17:54:44 We should be clear and emphasize that it is "log" messages. Not messages that the user will see. Which I think for us is most messages. 17:54:45 ok 17:54:51 rloo: we should get a volunteer now, and do it in small chunks 17:54:55 mariojv, yeah I was wondering if I should remove from the patches I have up in the queue now 17:55:28 #info please consider removing translation markers around *logs* in your patches to make our life easier 17:55:39 lucasagomes, if you have comments to address, certainly yes 17:55:49 if it's close to landing, I'd say land it and follow up 17:55:54 ok, so ok with translation markers for now. 17:55:56 dtantsur, right on 17:55:57 I would defer to keeping for exceptions as they could hit the user. Without clear guidance otherwise. 17:56:07 jlvillal: ++ 17:56:22 generally, _() stays, everything else goes away 17:56:32 unless we made a mistake and used a wrong marker 17:56:40 _() means "user visible" 17:56:48 oh, ok 17:56:53 so just remove _LE, _LW, etc? 17:57:20 mariojv, right. but double-check that they are actually not visible to a user (e.g. we don't do raise SomeError(_LE(..))) 17:57:32 ok 17:58:01 volunteers? :) 17:58:17 How do we want to partition it? 17:58:31 So is this a "Pike priority"? I mean when is it expected to be done? 17:58:43 no, not a priority. 17:58:49 rpioso, "use common sense" I guess.. 17:58:59 each driver separately, etc 17:59:01 we don't have to remove anything; nothing will be translated is all. 17:59:04 how to split the work would be importante, per file, folder, etc 17:59:04 agreed unless there's some openstack wide mandate that this has to be in by end of pike 17:59:20 there is not a mandate 17:59:20 I can take the API part if this helps? 17:59:26 it's just, "you can remove these now" 17:59:26 my only concern is inconsistency 17:59:27 rloo: Okay, good. 17:59:31 joanna: ++ 17:59:35 so either remove or not :) 17:59:44 joanna, thanks! 17:59:47 and we're out of time 17:59:50 dtantsur: this is a distributed system, eventual consistency ftw :) 17:59:53 dtantsur: I will volunteer for ironic-lib 17:59:55 thanks everyone, let's move to the channel! 17:59:56 dtantsur: noted :) 18:00:02 thanks jlvillal! 18:00:03 thanks all 18:00:05 #endmeeting