17:00:01 #startmeeting ironic 17:00:02 Meeting started Mon Jul 31 17:00:01 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:03 o/ 17:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:06 The meeting name has been set to 'ironic' 17:00:20 \o 17:00:21 o/ 17:00:21 who's up for having some ironic meeting on the last day of July? :) 17:00:23 o/ 17:00:28 o/\/ 17:00:31 o/ 17:00:32 o/ 17:00:33 o/ 17:00:36 o/ 17:00:36 o/ 17:00:40 o/ 17:00:47 o/ 17:00:48 o/ 17:00:50 o/ 17:00:52 o/ 17:00:53 o/ 17:00:58 o/ 17:01:07 although not having a meeting today would be nice too :) 17:01:23 nope ;) 17:01:32 o/ 17:01:35 o/ 17:01:35 hi and welcome everyone, who wants and who does not want a meeting :) 17:01:40 our agenda as usual can be found at 17:01:42 #link https://wiki.openstack.org/wiki/Meetings/Ironic 17:01:43 o/ 17:02:04 o/ 17:02:08 #topic Announcements / Reminder 17:02:13 we have some today! 17:02:23 #info Soft feature freeze starting tomorrow, Aug 1st 17:02:56 this is probably the most important one. starting tomorrow, we should concentrate on priorities and small vendor features, as well as, obviously, bug fixes and documentation improvements 17:03:14 (see my email to openstack-dev a couple of weeks ago for details) 17:03:39 #info Pike branches created for all library projects 17:03:45 o/ 17:04:04 sushy, ironic-lib, python-{ironic,ironic-inspector-}client now have stable/pike. no new features will go to Pike for these projects 17:04:26 #info We're about to remove the SSH drivers: https://review.openstack.org/#/c/481688/ 17:04:33 you saw this one coming, right? ;) 17:04:43 :( 17:05:15 and the last but not the least: 17:05:20 #info PTL nominations start tomorrow - don't forget to nominate yourself 17:05:29 is it already there, or is someone planning on adding ssh driver to that other project that i always forget the name of? 17:05:44 tagging drivers 17:05:44 ironic-staging-drivers? 17:05:47 nope 17:05:51 yeah, that one 17:05:53 we have a libvirt-based driver there, dunno if we want another one 17:05:56 *Staging 17:06:07 I'm definitely not planning on it 17:06:20 just asking/mentioning, in case someone wants it still 17:06:27 that's all from me. other announcements/reminders? questions? 17:06:54 dtantsur: next week is rc1 target week - doesn't apply to us, right 17:07:07 what's the ironic dates on the ptg planning etherpad? 17:07:10 I *think* it does not 17:07:10 dtantsur: and Hard StringFreeze -- that affects exception strings? 17:07:13 is it wed-fri? 17:07:21 rloo: all translated strings 17:07:23 vdrok: yes 17:07:39 rloo: we can be a bit relaxed about it, given that we've never had any serious translations 17:07:49 but yes, it affects everything within _() 17:07:54 dtantsur: ok 17:08:33 dtantsur: we should decide? on a date before week of Aug21, for feature freeze or whatever? 17:08:49 sorry? 17:08:57 dtantsur: that's the 'final rcs and intermediary releases week' 17:09:12 yep, so that week is our target 17:09:34 we should probably slow down active feature development a week before, which leaves not so much time for features, really 17:09:57 dtantsur: yes, that's what i wanted to know ^^. at least 1 week before :) 17:10:25 this is now a hard promise, just let's try not to rush everything in on the last day :) 17:10:48 keep in mind that the gate load will keep increasing 17:10:55 anything else? 17:10:58 And the gate isn't reliable right now :( 17:11:01 well, vdrok reminded me: 17:11:06 #link https://etherpad.openstack.org/p/ironic-queens-ptg 17:11:58 #topic Review subteam status reports (capped at ten minutes) 17:12:10 #link https://etherpad.openstack.org/p/IronicWhiteBoard starting with line 124 17:13:32 congrats to BFV folks for getting the nova patch landed! hip hip hurray! 17:13:35 \o/ 17:13:39 good job, really! 17:13:55 rloo: is https://review.openstack.org/#/c/408556/ the last big code patch for rolling upgrades? 17:14:13 FYI: I'm working on a little script that I can watch specific patches and keep doing recheck if Jenkins fails. 17:14:14 dtantsur: yes, that's the plan. unless someone proves otherwise! 17:14:28 jlvillal: Recheck-as-a-Service! 17:14:35 lol 17:14:36 * rloo sad that jlvillal has to write a script for that 17:14:46 this is actually quite sad :( at least make sure to use elastic recheck messages wisely 17:14:47 dtantsur: heh. Well I kept watching patches during the weekend and thought there had to be a better way 17:14:57 yeah, me too 17:15:01 thx jlvillal! 17:16:22 dtantsur: if i understand correctly, the only stuff we *have* to get done wrt driver comp, are docs? 17:16:29 dtantsur: for Pike I mean 17:16:39 rloo: this is correct 17:16:50 rloo, dtantsur: drac h/w type, too. 17:17:04 I put it a bit later on agenda, but I guess I'll mention it now: what about adding as-ha's client refactoring to the priorities list? https://review.openstack.org/#/q/topic:bug/1699547 17:17:22 dtantsur: and for OSC default API version change. we're done for PIke, can remove that item. How are we tracking the actual switch in Queens? Is it in ptg etherpad as a priority or something? 17:17:29 dtantsur: yup, I'm all for it 17:17:29 rpioso: this is really nice to have (as well as other hardware types), but that's not a critical priority (release blocker, so to say :) 17:17:36 the sooner we do this the better 17:17:55 dtantsur: Got it 17:17:57 rloo: this is exactly what I was thinking a minute ago: how to track it. I guess I'll add it to the etherpad 17:18:05 dtantsur: i view pas-ha's stuff as bug-related, since our gate broke cuz of that before. 17:18:20 dtantsur: and/or add a bug too 17:18:28 rloo: it is, just a lot of code 17:18:34 I'm in a middle of rebase + adding some goodies from fresh KSA Monty was telling us. Hopefully by the tomorrow's evening will get the series working 17:18:48 vdrok: yeah, you can review it, i know you can :) 17:19:07 but we'd need to pull this requirements sync too https://review.openstack.org/#/c/488117/ 17:19:09 rloo: it's a big chain, so I'd track it anyway on our list 17:19:26 :) I'll update the client change too, according to pas-ha suggestions 17:19:35 pas-ha: recheck all the things \o/ 17:19:51 ok: objections to putting that patch chain to the priorities list? 17:19:52 oh, we can't update client for pike any more 17:19:54 done 5min ago :) 17:20:00 rloo: yeah, I know. 17:20:12 maybe we should discuss offline then 17:20:15 just want to get it done as soon as possible in the cycle 17:20:28 *next cycle 17:20:31 * dtantsur recorded no objections so far 17:20:39 yep, but I'd suggest to make the next client release a major version bump (deprecating ironic CLI ans such) 17:20:54 so what's left to do for physical network awareness? there are related things but those are only 'related' 17:20:57 deprecating anything does not require a major version bump, removing does 17:21:43 dtantsur: removing hard-dependency on OSC might warrant the bump (as it changes what's installed by default) 17:21:44 pas-ha: added an item on line 248 17:21:48 thanks 17:22:00 pas-ha: yes, I bumped the major version of the inspector client due to that 17:22:13 also, changing the OSC default version requires a major version bump IMO 17:23:01 seems like a lot of major version bumps for the next release :) 17:23:06 dtantsur: it does? major version bump to what? 17:23:31 rloo: to indicate possibly breaking behaviour? 17:23:42 vdrok: sorry, i mean version bump to what version? 17:23:46 rloo: ironicclient; if we remove the dependency on OSC, people doing 'pip install python-ironicclient' will stop receiving 'openstack baremetal' commands 17:24:20 dtantsur: oh, we're talking about the version of python-ironicclient package? 17:24:24 yep 17:24:24 yup 17:24:29 that's fine with me :) 17:24:32 :) 17:24:42 everyone done with statuses? we're past 10 minutes IIRC 17:24:56 well, i wanted to know what was left to do for physical network awareness 17:25:00 * dtantsur sees 3 patches merging, nice! 17:25:13 i mean, 'priority' patches, not related patches. 17:25:55 mjturek or anyone: the BFV tempest test has merged, feel free to propose moving the job to the check queue 17:26:08 rloo: none I think 17:26:15 dtantsur: sounds good 17:26:21 rloo: one of the rolling upgrade bits still goes through the gate 17:26:24 everything else seems optional 17:26:31 vdrok: ok thx. let me know if there are any other network-related patches that ought to be reviewed 17:26:53 dtantsur: you lost me there wrt rolling upgrade bits 17:27:07 rloo: rolling upgrade for create_port 17:27:20 #link https://review.openstack.org/#/c/485773 17:27:21 dtantsur: oh, you mean the physical network aware thing. yeah. no need for reviews, just 'recheck' :-( 17:27:31 yeah, another dozen of rechecks 17:27:55 it has almost gotten through :) just grenade remaining 17:27:59 moving on? 17:28:12 +1 17:28:23 #topic Deciding on priorities for the coming week 17:28:42 still some docs left 17:28:50 but everything has had quite a progress! 17:29:11 dtantsur: oh, wrt docs, we need the config page: https://review.openstack.org/#/c/486934/ 17:29:16 right 17:29:25 that's an easy review ^ 17:29:31 also easy to bikeshed :-( 17:29:36 of course! :) 17:29:50 mjturek: do we have anything urgent for BFV to put on the prio list 17:29:52 ? 17:30:27 dtantsur: checking - there were some patches in the meeting that need reviews 17:30:50 as to physnet awareness, we have a refactoring chain: https://review.openstack.org/#/q/topic:refactor-vif-attach-mixin 17:31:21 nvm - those were the tempest tests :) 17:31:26 yep :) 17:31:48 dtantsur: is the refactoring chain important? 17:32:01 rloo: I think it enables some additional testing in the CI 17:32:11 like, having real VIF plugging/unplugging in tempest API tests 17:32:16 but nothing deadly critical 17:32:16 dtantsur: actually this one is this weeks priority list and hasn't merged. Reviews would be appreciated https://review.openstack.org/#/c/473717/ 17:32:26 dtantsur: i think we want that testing, don't wek? 17:32:33 we do 17:32:35 dtantsur: oh if it does it would be good to have 17:32:48 oh nice, mjturek! and now I remember that we also have api-ref for volume API 17:32:56 yeah, then we should get the refactoring done 17:34:18 does the list look good? 17:34:30 I can also offer you some awesome upgrade docs for hw types, if you're up for some long read ;) 17:34:57 should we add pas-ha's stuff? or is that premature 17:35:08 rloo: he needs to rework it, let's add it next week, I guess.. 17:35:14 also there's sambett's ipa thing... 17:35:16 but IPA API is a good candiadate 17:35:17 right 17:35:26 https://review.openstack.org/#/c/364834/ 17:35:58 ok, the docs can wait :) does the list look good now? 17:36:04 +1 17:36:26 +1 17:36:50 okay, let's have some flame war finally :) 17:36:54 #topic Adding API interop assert tag to ironic: https://review.openstack.org/#/c/482759/ 17:37:18 this raised some contentions. and I don't want to approve this thing on behalf of the team without even asking the team 17:37:48 the technical side of the tag is that we agree to follow microversioning and to have branchless tempest. we do both already. 17:38:14 some people, myself included, don't quite understand, what the end users/operators should derive from these tags 17:38:29 so I'd like to hear more opinions, from whatever standpoint 17:39:32 dtantsur: what is the 'ironic deliverable'? 17:39:45 rloo: whatever is in openstack/ironic repo 17:39:56 in this context, ironic-api 17:39:59 dtantsur: just ironic repo then, not the other ironic-related projects 17:40:09 yeah, that caused me some confusion as well 17:40:20 only ironic itself, not e.g. inspector 17:40:50 dtantsur: i'm fine with it, except it isn't clear whether ironic follows the api interop guidelines. 17:40:57 maybe it does show some level of 'maturity'? should be a good thing 17:41:02 techinically, it does 17:41:29 if ironic technically satisfies the requirements for having this tag, then i am ok with it. 17:41:38 vdrok: well, this is actually a difficult point. we're inventing the definitions of maturity, based on the practices we already do, not based on what people want (??) or what standard practices are (??) 17:42:01 (things marked (??) are not necessary true, I just haven't seen enough proof to get convinced) 17:42:04 ^^ yeah, i think we have to decide based on a list of requirements, not 'maturity' (too vague) 17:42:05 AFAIU that's for consumers to be sure an upgrade will not break users (if they use the same old still supported API microversion) 17:42:26 pas-ha: well, except that nobody can claim that, there may be a bug in the versioning itself 17:42:33 dtantsur: I'm more thinking about https://www.openstack.org/software/releases/ocata/components/nova, if people look at those 17:42:43 and put this way, it requires integration tests for every microversion, which nobody does 17:42:50 dtantsur: one cannot claim anything then, cuz there can be bugs in anything 17:43:05 vdrok: I don't think it's the same, but I may be wrong 17:43:22 rloo: well, screwing up microversions is not too hard, testing all of them is hard 17:43:38 dtantsur: we write perfect code. no need to test ;) 17:43:39 dtantsur: at least 'follows standard deprecation' is there which is also a tag iirc 17:43:44 * dtantsur playing devil's advocate mostly 17:43:54 vdrok: right 17:44:15 dtantsur: we test some combination of versions, don't we? grenade, grenade multi, nova+ironic. 17:44:18 so, it seems that the folks are in favour of this idea, right? can I hear more voices please? ;) 17:44:30 rloo: these are mostly testing at release cycle boundaries 17:44:47 barely anybody is going to test e.g. 1.30, outside of functional tests 17:44:51 dtantsur: right, which is most likely when it will be of most importance 17:44:59 this is not quite true 17:45:09 dtantsur: ? 17:45:13 the idea of microversioning is to pick the version you need 17:45:24 I'd like to get understanding of how dtantsur comment re free-form schema-less fields is playing here 17:45:26 which, in our reality, indeed turns into "pick the Pike version" or something 17:45:45 pas-ha: this is even more important for us specifically 17:45:59 we change behavior based on driver_info and properties (hello, boot_mode) 17:46:15 these are mostly driver-provided and are not versioned 17:46:25 exactly. If the driver changes in-between, the same request with the same API version *will* fail after upgrade 17:46:34 personally, i don't care about this tag. i get the feeling dtantsur is being devil's advocate very strongly, so let's not do it. i think it woudl be good for dtantsur to comment in the patch, the reasons why ironic may not conform to it. 17:46:37 we don't even (IIRC) provide a way to get a list of capabilities (for example) that change ironic's behavior 17:46:57 we (or some of us) know how much dtantsur loves the microversioning in ironic 17:47:04 rloo: I'm mostly expaining why I did not +1 it with an easy heart, don't take it as a principal position :) 17:47:39 dtantsur: those are valid reasons, if they are requirements for this tag. 17:47:56 dtantsur: i still don't know the requirements for the tag... (i mean, details by which to decide) 17:48:03 rloo: http://docs-draft.openstack.org/59/482759/1/check/gate-governance-docs-ubuntu-xenial/29826eb//doc/build/html/reference/tags/assert_supports-api-interoperability.html#requirements 17:48:45 and this is the api-wg spec behind it: http://specs.openstack.org/openstack/api-wg/guidelines/api_interoperability.html 17:48:49 dtantsur: thx. is everything discoverable now? it wasn't before. 17:49:05 pas-ha: I think other projects do have the same problem. eg nova will migrate flavors from usual ones to the custom resource classes, by setting an extra spec. so if extra spec with such name was used for something else, the api interoperability is broken 17:49:21 tags: https://governance.openstack.org/tc/reference/tags/index.html 17:49:21 dtantsur: i think we shoudl take this offline. maybe someone can spend some time reading those requirements and report back? 17:49:43 rloo: I suggest everyone reads all the links, and +/- the patch in question 17:49:57 then I'll make my final decision based on what I hear from you 17:50:01 dang, i was hoping that we only needed one person to investigate :) 17:50:13 it's a buy-in from the whole team.. 17:50:24 we're committing to following some rules, when changing the API 17:50:35 how do we write/review changes without knowing these rules for sure? 17:50:51 dtantsur: if we are already following those rules, then i am fine :) 17:51:13 not precisely, as it seems to me.. anyway, please come to the patch with your review 17:51:35 #action everyone please put your thoughts on https://review.openstack.org/#/c/482759/ 17:51:42 ok. i see this as a lower/lowest priority amongst everything we have on our plates now. wrt pike release. 17:51:58 it's not urgent at all, but it's not going to take too much time as well 17:52:32 any other comments or thoughts? 17:53:07 * dtantsur thinks that it's too hot outside 17:53:11 #topic RFE review 17:53:30 #link https://bugs.launchpad.net/ironic/+bug/1700071 Make DIB-build IPA fully supported 17:53:30 Launchpad bug 1700071 in Ironic "[RFE] Make DIB-build IPA fully supported" [Wishlist,Confirmed] - Assigned to Dmitry Tantsur (divius) 17:53:43 we more or less agreed on it on the PTG, just bringing to your attention 17:54:31 dtantsur: it just needs to be approved? maybe add link to PTG etherpad? 17:54:45 I'm fine with just approving it, and yeah, I need to find a link 17:54:51 +1 17:55:09 if noone will complain about the number of jobs on ipa :) 17:55:19 +1 17:55:21 #link https://etherpad.openstack.org/p/ironic-pike-ptg-ci-testing 17:55:22 vdrok: shhhh, we won't tell anyone... 17:55:35 vdrok: welll... 17:55:37 +1 17:55:49 we should really work on standalone tests for IPA 17:56:01 okay, I'm marking this one as approved 17:56:40 #topic Open discussion 17:56:47 4 minutes :) 17:57:20 crickets 17:57:33 mmm, we can save a couple of minutes of our life I guess :) 17:57:38 thanks everyone! 17:57:41 thanks :) 17:57:54 #endmeeting