17:00:31 <dtantsur> #startmeeting ironic
17:00:32 <openstack> Meeting started Mon Jun 27 17:00:31 2016 UTC and is due to finish in 60 minutes.  The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:36 <openstack> The meeting name has been set to 'ironic'
17:00:36 <devananda> o/
17:00:38 <lucasagomes> o/
17:00:38 <jlvillal> o/
17:00:39 <JayF> o/
17:00:40 <dtantsur> #chair devananda rloo
17:00:40 <rpioso> o/
17:00:41 <mat128> o/
17:00:41 <openstack> Current chairs: devananda dtantsur rloo
17:00:43 <rama_y> o/
17:00:46 <alineb> o/
17:01:01 <rloo> o/
17:01:04 <TheJulia> o/
17:01:13 <mgould> o/
17:01:14 <dtantsur> welcome everyone! our agenda as usual is on:
17:01:17 <dtantsur> #link https://wiki.openstack.org/wiki/Meetings/Ironic
17:01:36 <dtantsur> #topic Announcements / Reminders
17:01:49 <dtantsur> First of all, the next Monday is a holiday in the US
17:02:08 <dtantsur> Will anyone feel sorry if we skip it?
17:02:14 <dtantsur> it = the meeting
17:02:30 * devananda supports skipping the July 4th meetings
17:02:33 <lucasagomes> fine to me
17:02:34 <sambetts> o/
17:02:35 <TheJulia> no objections to cancelling next week's meeting
17:02:37 <mariojv> \o
17:02:44 <JayF> ++
17:02:44 <sambetts> no objections here
17:02:46 <rloo> skip, skip, skip to ...
17:02:57 <mat128> skip
17:03:02 <thiagop> skip
17:03:10 <jlvillal> +1 for skip
17:03:17 <mat128> #startvote Skip July 4th meeting?
17:03:18 <openstack> Only the meeting chair may start a vote.
17:03:25 <dtantsur> awesome, then
17:03:26 <dtantsur> #agreed We'll skip the next meeting (July 4th) due to the US holiday
17:03:40 <jlvillal> #info No meeting on July 4th
17:03:44 <dtantsur> don't think we need a format vote on it, even though I find it tempting to try chatbot commands :)
17:04:00 <[1]cdearborn> o/
17:04:17 <dtantsur> Second announcement:
17:04:22 <dtantsur> #info We've made a release of all supported branches due to a CVE
17:04:31 * dtantsur tries to find a link
17:04:54 <mat128> #link https://bugs.launchpad.net/ironic/+bug/1572796
17:04:54 <openstack> Launchpad bug 1572796 in Ironic "Node information including credentials exposed to unathenticated users (CVE-2016-4985)" [High,Fix released] - Assigned to Devananda van der Veen (devananda)
17:05:07 <dtantsur> thanks!
17:05:28 <dtantsur> any more announcements/reminders?
17:06:18 <dtantsur> I take it as no :)
17:06:21 <rloo> great mid-cycle!
17:06:28 <dtantsur> oh yeah!
17:06:39 <dtantsur> #info We had a great virtual midcycle \o/
17:06:43 <dtantsur> now
17:06:48 <lucasagomes> and thanks mat128 for the summary :-)
17:06:57 <JayF> There was also a pretty nasty IPA bug fixed; https://bugs.launchpad.net/ironic-python-agent/+bug/1592163 -- deployers should rebuild ramdisks with this fix
17:06:57 <openstack> Launchpad bug 1592163 in ironic-python-agent mitaka "IPA may unexpectedly stop in a CoreOS-based ramdisk in certain circumstances" [High,Fix committed] - Assigned to Jay Faulkner (jason-oldos)
17:06:57 <dtantsur> #link https://etherpad.openstack.org/p/ironic-newton-midcycle midcycle etherpad
17:07:03 <lucasagomes> (in the ML for those wondering)
17:07:07 <JayF> it's in all branches and ramdisks were updated on merge as is usual
17:07:13 <JayF> (stable branches)
17:07:24 <dtantsur> #info Deployers using the coreos IPA should rebuild their images due to https://bugs.launchpad.net/ironic-python-agent/+bug/1592163
17:07:49 <dtantsur> anything else?
17:07:57 <mat128> lucasagomes: thanks :)
17:08:17 <dtantsur> ok, moving on
17:08:21 <dtantsur> #topic Review subteam status reports
17:08:33 <dtantsur> the status reports are on the whiteboard:
17:08:37 <dtantsur> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:08:47 <dtantsur> starting line 78
17:10:20 <dtantsur> devananda, do you feel you could remove your -2 from the first network patch, so that we start merging them?
17:10:22 <_milan_> o/
17:11:40 <dtantsur> devananda, this is https://review.openstack.org/206244 and it no longer involves portgroups, as agreed on the summit
17:12:18 <rloo> dtantsur, devananda: agreed at the midcycle
17:12:25 <devananda> dtantsur: I'll take a look right now
17:12:31 <dtantsur> thanks rloo, my bad :)
17:12:33 <dtantsur> devananda, thanks
17:12:44 <devananda> dtantsur: my block was on the first API change, so that we did not merge any visible REST API changes until we were sure
17:12:49 <dtantsur> lucasagomes, is it possible to add virtual console support to vbmc?
17:12:59 <devananda> we've already allowed some of the internal changes in, so I"m happy to allow more of thsoe in
17:13:03 <dtantsur> devananda, yeah, I know. it feels like The Time Has Come
17:13:07 <devananda> awesome
17:13:29 <devananda> dtantsur, sambetts: who all has been able to verify these patches on Real Hardware (tm) ?
17:13:31 <lucasagomes> dtantsur, yes, it seems possible
17:13:35 <mat128> dtantsur: SoL?
17:13:49 <dtantsur> mat128, yep. see line 152
17:13:53 <devananda> it's unfortunate but in the last month or so, I haven't had time to get this running in my lab again
17:14:09 <dtantsur> devananda, I'm waiting to get this Real Hardware :(
17:14:27 <mat128> dtantsur: thanks :)
17:14:36 <lucasagomes> dtantsur, I will add a bug on virtualbmc about it (wishlist)
17:14:49 <dtantsur> lucasagomes, thanks! please link it on the whiteboard under line 152
17:14:55 <lucasagomes> dtantsur, ack
17:15:10 <dtantsur> krotscheck_dcm, betherly, any updates on the webclient?
17:15:16 <krotscheck_dcm> None
17:15:17 <lucasagomes> it may involve having to add the abstraction in pyghmi as well, anyway, will add to the bug
17:15:30 <devananda> do we have tempest API coverage for the new API endpoints? I do not see it in this patch.
17:15:44 <krotscheck_dcm> Well, not directly related anyway. We're abotu to move the Ironic API into the OpenStack JavaScript SDK
17:15:46 <dtantsur> lucasagomes, please update line 164 if you don't mind
17:16:09 <dtantsur> vdrok, vsaienko, see devananda's question above ^^^
17:16:33 <dtantsur> krotscheck_dcm, OpenStack JavaScript SDK? is there a thing? :)
17:16:34 <betherly> dtantsur: in process of developing edit node functionality and state machine changes
17:16:56 <TheJulia> betherly: That is for the horizon plugin?
17:17:01 <krotscheck_dcm> dtantsur: openstack/js-openstack-lib and openstack-infra/js-generator-openstack
17:17:04 <mat128> TheJulia: webclient
17:17:04 <betherly> TheJulia: yep
17:17:04 <krotscheck_dcm> So yes
17:17:12 <mat128> ^w
17:17:13 <lucasagomes> done
17:17:18 <dtantsur> krotscheck_dcm, thanks, I didn't know about it
17:17:25 <dtantsur> thanks for updates, betherly, lucasagomes, krotscheck_dcm
17:17:29 <krotscheck_dcm> dtantsur: It's 3 weeks old
17:17:34 <dtantsur> hah :)
17:17:40 <betherly> mat128: I work on the ironic horizon plugin, krotscheck_dcm on the webclient :)
17:17:42 <devananda> dtantsur: the patches are not ready for me to remove that -2
17:17:55 <dtantsur> devananda, I thought we prefer -1 when patches are not ready
17:18:05 <devananda> dtantsur: the process we agreed on was that I will unblock the chain as a whole, once everything else is 2x +2'd and ready to land
17:18:18 * dtantsur didn't agree on such process, but believes devananda..
17:18:37 <dtantsur> for the record: I don't think it's the right approach. but we won't be arguing on it in this section :)
17:18:54 <dtantsur> anything else on the status? we have one topic, then we can have a flame war(s)
17:19:44 <dtantsur> #topic make functional tests be voting for IPA
17:19:48 <dtantsur> jlvillal, your turn ;)
17:19:56 <jlvillal> Hey, maybe a bit premature on this
17:20:02 <jlvillal> I thought it had been running in the gate longer.
17:20:11 <lucasagomes> jlvillal, the tests were added last week
17:20:18 <jlvillal> But we did have these tests get broken.
17:20:19 <lucasagomes> I would give it a lil more time and then no objections
17:20:36 <jlvillal> Agreed. Defer for now. Maybe next week?
17:20:47 <lucasagomes> could be
17:20:55 <lucasagomes> one a note, we should improve the funcitonal tests in IPA
17:20:57 <jlvillal> So far everything seems good from looking at test results
17:20:58 <lucasagomes> there's very little there
17:21:07 <dtantsur> yeah, the next week, if we don't see excessive random failures
17:21:09 <dtantsur> lucasagomes++
17:21:24 <jlvillal> lucasagomes, Agreed. And hopefully if it is a voting test, maybe more interest from people to add...
17:21:39 <lucasagomes> yeah, I think we do have a bug about it
17:21:40 * lucasagomes checks
17:21:47 <jlvillal> I could believe people didn't even know about it.
17:21:47 <dtantsur> we do
17:22:05 <dtantsur> jlvillal++ I'd prefer to add things to a voting (or at least running) test
17:22:20 <lucasagomes> #link https://bugs.launchpad.net/ironic-python-agent/+bug/1492036
17:22:20 <openstack> Launchpad bug 1492036 in ironic-python-agent "IPA does not have functional testing" [Low,In progress] - Assigned to Mario Villaplana (mario-villaplana-j)
17:22:21 <jlvillal> The ironic-pythong-agent got added to a 'ci watch' system that someone is running.
17:22:39 <dtantsur> cool
17:22:40 <jlvillal> I put a link to it on the whiteboard under the gate status. The IP address one. It just started today
17:22:46 <dtantsur> thanks jlvillal
17:22:47 <jlvillal> So it will take some time to build up history
17:22:54 <jlvillal> That's all from me
17:23:04 <dtantsur> so do we agree that we'll make it voting the next week if everything is alright?
17:23:10 <jlvillal> +1 from me.
17:23:15 <lucasagomes> ++
17:23:23 <rloo> ++, end of next week?
17:23:34 <dtantsur> rloo, when people are around, I guess :)
17:23:37 <rloo> maybe midweek.
17:23:39 <lucasagomes> I would vote for mid :-)
17:23:39 * jlvillal would vote for no later than Thursday
17:23:40 <lucasagomes> yeah
17:23:50 <jlvillal> Does not want a Friday change :)
17:23:51 <lucasagomes> making it vote on friday is scary heh
17:24:03 <TheJulia> ++ to not friday
17:24:03 <dtantsur> #agreed Make the IPA functional tests job voting the next week, if we don't see problems with it
17:24:14 <dtantsur> I think we can figure out the exact day outside of the meeting :)
17:24:21 <dtantsur> moving on?
17:24:27 <jlvillal> Yes please
17:24:34 <dtantsur> #topic RFE review
17:24:51 <dtantsur> in this section we do a brief sanity check of a couple of RFEs and decide if they need a spec
17:24:59 <dtantsur> I didn't prepare many in advance, but here are some:
17:25:14 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1595625 Ability to run manual cleaning with automated clean steps
17:25:14 <openstack> Launchpad bug 1595625 in Ironic "[RFE] Ability to run manual cleaning with automated clean steps" [Wishlist,Confirmed]
17:25:31 <dtantsur> giving folks a couple of minutes to read the description and the comments
17:26:22 <dtantsur> on one hand it's an easy change; on the other hand it's an API change and there is a contention already (see the comments)
17:26:33 <lucasagomes> this is just about running all steps if no steps is specified?
17:26:40 <dtantsur> lucasagomes, all "automated" steps
17:26:47 <rloo> lucasagomes: running all automated steps, in a manual clean.
17:27:10 <vdrok> devananda: the first patch does not contain new endpoints now, the one that contains does not add tempest tests, it's in the end of chain. Will add those
17:27:16 <lucasagomes> automated == priority > 0, right?
17:27:24 <rloo> lucasagomes: right.
17:27:25 <dtantsur> lucasagomes, right
17:27:29 <lucasagomes> seems alright to be
17:27:38 <dtantsur> thanks vdrok, lets get back to in in the open discussion
17:27:42 <devananda> vdrok: first patch adds new fields, which do not do anything until later patches
17:28:10 <dtantsur> so, while a bit uncertain, I think this RFE could use a spec. wdyt?
17:28:23 <devananda> vdrok: I do not want to land a visible change in the API that doesn't _do_ anything, until we're very sure that all the subsequent changes (that enable that API) are going to land too
17:28:28 <rloo> dtantsur: i'm fine either way. as long as i get answers to my questions :)
17:28:50 <dtantsur> devananda++ but lets postpone it until the open discussion, we'll get back to it, I promise ;)
17:29:12 <devananda> dtantsur: sorry. just responding to vdrok.
17:29:31 <rloo> dtantsur: if you think it needs a spec, then let's ask for a spec.
17:29:37 <TheJulia> dtantsur: this seems like a minimal change to me, I don't think a spec is really necessary, but we may all look at code and change our minds.  I think this is a case where seeing some code, would make it very easy to decide which way
17:29:38 <dtantsur> other opinions on https://bugs.launchpad.net/ironic/+bug/1595625 ? does everyone feels ok with it *without* a spec as long as rloo's comments are resolved?
17:29:38 <openstack> Launchpad bug 1595625 in Ironic "[RFE] Ability to run manual cleaning with automated clean steps" [Wishlist,Confirmed]
17:29:39 * jlvillal finds title confusing compared to content
17:29:53 <mat128> dtantsur: I feel ok
17:30:15 <mat128> jlvillal: We could say "Optionally run automated clean steps during manual cleaning"
17:30:32 <dtantsur> do we need a format vote?
17:30:37 <jlvillal> mat128, That makes it clearer to me.
17:30:56 <mat128> https://bugs.launchpad.net/ironic/+bug/1595625
17:30:56 <openstack> Launchpad bug 1595625 in Ironic "[RFE] Optionally run automated clean steps during manual cleaning" [Wishlist,Confirmed]
17:30:57 <mat128> updated
17:31:07 <dtantsur> thanks mat128
17:31:15 <rloo> dtantsur: it seems to me that if someone asks for a spec and has good reason for asking, then they should do a spec. not sure we need to vote on it?
17:31:25 <devananda> that change in the title clarifies the RFE a lot for me, thanks
17:31:35 <dtantsur> I'm not sure, I'm fine with figuring out on the patch
17:31:48 <dtantsur> it seems like we have a consensus. the last chance to object
17:31:51 <lucasagomes> I think it's ok to just have the RFE, but I would like to see the authors answers for rloo's questions
17:32:01 <lucasagomes> before approving it
17:32:18 <rloo> lucasagomes: yup
17:32:20 <dtantsur> #agreed https://bugs.launchpad.net/ironic/+bug/1595625 does not need a spec, but the question in the comments have to be addressed
17:32:20 <openstack> Launchpad bug 1595625 in Ironic "[RFE] Optionally run automated clean steps during manual cleaning" [Wishlist,Confirmed]
17:32:25 <dtantsur> moving on
17:32:41 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1595172 Add names for ports
17:32:41 <openstack> Launchpad bug 1595172 in Ironic "[RFE] Add names for ports" [Wishlist,Confirmed] - Assigned to Sharat Sharma (sharat-sharma)
17:32:47 <dtantsur> devananda, I remember you had objections ^^^
17:32:51 <lucasagomes> that needs a spec
17:33:09 <devananda> heh, indeed
17:33:24 <lucasagomes> we already had problems with names of nodes colliding with subcontrollers and so on
17:33:26 <mat128> dtantsur: the spec you were looking for is https://review.openstack.org/#/c/295082/
17:33:26 <dtantsur> it seems to me we had a spec...
17:33:30 <rloo> ++ to spec. i thought someone had already asked for that but don't remember.
17:33:33 <lucasagomes> I also, fail to see the real use case for naming ports
17:33:35 <dtantsur> aha!
17:33:41 <dtantsur> thanks mat128, you're so fast today :)
17:33:59 <rloo> mat128 is *always* fast with the links!
17:34:00 <devananda> the only case for naming ports that I have seen was "I want to name the NICs so that I can search for them easily"
17:34:13 <mat128> heh :blush:
17:34:15 <devananda> which boiled down to someone not wanting to use "--node-port-list"
17:34:32 <devananda> I haven't read that spec .... /me goes and reads it real quick
17:34:37 <rloo> i dunno. we allow names for nodes, and even then, some folks didn't see the usefulness of it.
17:34:40 <devananda> *in a while
17:34:46 <dtantsur> I've marked the RFE in question as a duplicate, cause we already had an RFE matching the spec
17:35:02 <dtantsur> rloo, I see *great* usefulness for node names; not so much for port names
17:35:07 <devananda> what is the current rationale for wanting to name ports?
17:35:39 <dtantsur> devananda, I don't believe there's strong one; anyway, lets bring it to the spec, you've already -1ed it, and I agree with you
17:35:40 <devananda> cause this RFE looks like the same thing
17:35:50 <devananda> "MAC address is too hard to remember, and I dont want to use --node-port-list"
17:35:58 <devananda> k
17:36:13 <dtantsur> moving to the last one I've prepared
17:36:17 <lucasagomes> yeah, seems very little compelling, +1 to keep the conversation in the spec
17:36:32 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1594668 Allow creating a port providing node name instead of UUID
17:36:32 <openstack> Launchpad bug 1594668 in Ironic "[RFE] Allow creating a port providing node name instead of UUID" [Wishlist,Confirmed] - Assigned to Sharat Sharma (sharat-sharma)
17:36:42 <dtantsur> I like it
17:36:59 <mat128> notice it's by the same user
17:37:00 <mat128> =)
17:37:05 <lucasagomes> seems like a good UX
17:37:07 <dtantsur> well, things happen :)
17:37:09 <vdrok> Yeah, why not
17:37:25 <lucasagomes> now, I would like a spec due the impact on the CLI and API
17:37:27 <dtantsur> imagine (s)he just started using ironic and got hit by a few problems
17:37:34 <thiagop> I'd like to name a port after the port on the node (aka eth0, eth1...) to make it easy to my brain to work
17:37:46 <dtantsur> thiagop, that's a fair call, lets bring it to the spec
17:37:52 <rloo> I'm not sure, I think we had some funky code that made it a bit difficult to implement this. Seems like someone tried to do it before but I don't recall what happened with it. But I'm fine with it.
17:37:55 <mat128> I don't have any strong objection to ^, but tats's previous spec
17:37:57 * NobodyCam joins super late :(
17:37:58 <thiagop> sure dtantsur
17:38:08 <dtantsur> ok, lucasagomes wants a spec and I don't see reasons to object :)
17:38:14 <lucasagomes> rloo, yup, therefore a spec would be good
17:39:02 <dtantsur> objections?
17:39:03 <rloo> i'm not sure a spec is needed. it is just one API change?
17:39:27 <dtantsur> we've screwed up adding names to nodes; I'm not sure a spec will help though
17:39:31 <rloo> i think the devil (or whatever) is in the implementation details.
17:39:57 <lucasagomes> rloo, and CLI, I wonder also if the author will propose doing POST v1/nodes/foo/ports
17:40:00 <lucasagomes> and things like that
17:40:06 <devananda> thiagop: you could use extra.dev_name='eth0' today to do that
17:40:19 <devananda> thiagop: also, in many OS, it is non-deterministic. and it is certainly not consistent across OS's
17:40:45 <lucasagomes> rloo, another confusing thing, the CLI for port-create supports --node and --node_uuid
17:40:47 <dtantsur> rloo, do you object to having a spec?
17:40:48 <devananda> as far as "ironic port-create -a .... -n node_name" goes, I would definitely be in support of htat
17:40:50 <rloo> lucasagomes: so if they update the rfe to indicate exactly what the CLI/API are, would that be sufficient?
17:40:53 <lucasagomes> but both requires the UUID
17:41:11 <devananda> the current requirement to create ports with a node UUID, when most other commands accept a name is poor UX
17:41:25 <dtantsur> devananda, +100 I got hit by it when reviewing the OSC patches
17:41:26 <vdrok> I've seen some rfe to add a description to ports, maybe it's just a matter of what is printed on port show
17:41:27 <rloo> dtantsur: oh, i don't object to having a spec if lucasagomes wants it.
17:41:29 <devananda> it's easy enough to work around, but I find it frustrating when I forget it
17:41:39 <dtantsur> devananda, yeah, the question is whether we want a spec for it
17:41:46 <dtantsur> I think we all agree that's a sane call
17:41:51 <dtantsur> (to have this feature)
17:41:56 <vdrok> Err, port list
17:42:07 <devananda> dtantsur: we could do port-create with node name entirely in the client even. no REST API changes
17:42:17 <rloo> vdrok: that rfe you mentioned, was associated with the code to have port names... that we just discussed above.
17:42:20 <dtantsur> devananda, but should we? all our API support names
17:42:31 <devananda> right - we could do that too
17:42:38 <devananda> if we change the REST API, I would like a spec
17:42:54 <vdrok> rloo: huh, I'm from phone, so might have missed things :)
17:43:00 <rloo> vdrok: no worries :)
17:43:05 <dtantsur> ok, we can't agree on it for some time, I think it's a good reason to have a spec, right? :)
17:43:08 <rloo> ok, devananda and lucasagomes want a spec, so lets ask for it.
17:43:18 <devananda> fwiw, if someone just wanted to make a UX improvement to the CLI, I would be fine without a spec
17:43:33 <lucasagomes> doesn't need to be a big one, but it's mostly about user experience and involves the client and API
17:43:41 <lucasagomes> so I tend to think we need a spec for it
17:43:42 <devananda> (not suggesting that, just clarifying the cases where I do or do not want a spec)
17:43:47 <dtantsur> #agreed https://bugs.launchpad.net/ironic/+bug/1594668 will need a short spec
17:43:47 <openstack> Launchpad bug 1594668 in Ironic "[RFE] Allow creating a port providing node name instead of UUID" [Wishlist,Confirmed] - Assigned to Sharat Sharma (sharat-sharma)
17:44:10 <dtantsur> sorry, I just saw one more thing:
17:44:17 <dtantsur> #link https://bugs.launchpad.net/ironic/+bug/1585595 Handling SIGHUP on Ironic services
17:44:17 <openstack> Launchpad bug 1585595 in Ironic "[RFE] Handling SIGHUP on Ironic services" [Wishlist,In progress] - Assigned to Lucas Alvares Gomes (lucasagomes)
17:44:20 <dtantsur> lucasagomes, yours one ^^^
17:44:31 <dtantsur> I think we should Just Do It (tm). wdyt?
17:44:39 <lucasagomes> oh, I started that because it was needed for the rolling release
17:44:43 <devananda> oooh
17:44:43 <lucasagomes> it seems it's not needed anymore, but still
17:44:48 <lucasagomes> it's a feature own it's own
17:45:19 <lucasagomes> oslo.service already supports handling SIGHUP and oslo.config already supports marking options as "multable" that will be reloaded upon receiving that signal
17:45:43 <devananda> lucasagomes: do you have a list of the impplicitly mutable options? your RFE mentions debug - are there others?
17:45:45 <lucasagomes> I just need to update my patch upstream... I don't think it needs a spec, but it's up to you guys
17:46:03 <rloo> lucasagomes: so someone needs to decide which configs are mutable?
17:46:04 <devananda> lucasagomes: also, do you have a list of the ironic-specific options you'd want to reload on SIGHUP?
17:46:09 <vdrok> So we need to decide which do we allow to reload?
17:46:23 <vdrok> Heh
17:46:28 <lucasagomes> devananda, probably there are, I've to go through the list of configurations and see what would make sense to be reloaded
17:46:35 <dtantsur> vdrok, right now we decide: 1. whether it's a sane request; 2. whether it needs a spec
17:46:38 * devananda thinks more on this...
17:46:44 <dtantsur> we don't need to figure out all the details right now and here
17:47:13 <devananda> it's going to be confusing to operators if some options reload, and some do not, unless we very clearly indicate (or detect) this on reload
17:47:15 <vdrok> It's same but seems that there will be discussion around the list of options
17:47:22 <vdrok> *sane
17:47:29 <rloo> i am fine w/o a spec, but would like to see the list of mutable configs, and some sort of criteria as to which/why, for future configs.
17:47:42 <devananda> like - we should LOG.warning() if a config was changed which we can not re-initialize
17:47:47 <lucasagomes> devananda, yeah, I find it strange from oslo.config as well to have to explicitly mark which ones you want to reload
17:48:13 <dtantsur> lucasagomes++ a user would expect everything to be reloaded
17:48:23 <rloo> so it needs more work. a spec or not?
17:48:24 <dtantsur> so, a spec?
17:48:25 <devananda> and how will we test this in the gate?
17:48:28 <lucasagomes> but I understand things weren't engineered to support reloading everything in the first place (e.g timeout passed to the periodic tasks at construction time)
17:48:42 <dtantsur> ok, I see enough questions to warrant a spec, lets not solve them all here
17:48:43 <rloo> i think it needs a spec. given the questions brought up so far :)
17:48:43 <lucasagomes> devananda, no clue
17:48:49 <devananda> lucasagomes: wouldn't we recreate the threads/workers?
17:48:53 <dtantsur> agreed?
17:48:59 <devananda> dtantsur: ++
17:48:59 <rloo> dtantsur: agreed.
17:49:00 <lucasagomes> devananda, I don't think we should?
17:49:20 <dtantsur> #agreed https://bugs.launchpad.net/ironic/+bug/1585595 will need a spec as there are enough unclear parts
17:49:20 <openstack> Launchpad bug 1585595 in Ironic "[RFE] Handling SIGHUP on Ironic services" [Wishlist,In progress] - Assigned to Lucas Alvares Gomes (lucasagomes)
17:49:22 <lucasagomes> my solution for that would be to have a function reference when getting the timeout in the periodic task (it's out of the scope of the spec)
17:49:32 <lucasagomes> e.g periodic(interval=func_ref)
17:49:36 <lucasagomes> instead of the value itself
17:49:41 <lucasagomes> that would allow us to reload it
17:49:51 <lucasagomes> but anyway, outside the scope of ironic/spec, should be an oslo thing
17:50:05 <dtantsur> thanks folks, I'm ready to open the floor. lets discuss the details on the spec
17:50:16 <dtantsur> #topic Open discussion
17:50:36 <rloo> let's get back to https://review.openstack.org/#/c/206244/, vdrok, devananda?
17:50:37 <dtantsur> vdrok, devananda, wanna discuss conditions of removing -2 (at least replacing with -1) from that network patch?
17:50:44 <devananda> :)
17:50:54 <vdrok> So, re multitenancy, I can move first patch one further down the chain
17:51:07 <devananda> afaik, we were following the approach nova has repeatedly used with long feature patch chains
17:51:17 <vdrok> And add tempest tests for API to the second one
17:51:26 <devananda> which is that all non-API changes are landed first and iterated in -tree
17:51:42 <devananda> and then the REST API changes and all the things that depend on them are done in patches, reviewed, +2'd, etc
17:51:46 <dtantsur> I fully support landing API the last
17:52:07 <rloo> i think that makes sense. The problem was that the API patch was first in the chain.
17:52:08 <vdrok> Ah, yeah, seems possible too
17:52:13 <devananda> when the whole chain is done (enough) and has tests (passing well enough, maybe not 100%) then the PTL removes the -2 at the head of the chain
17:52:19 <rloo> so if vdrok can move the API changes to later in the chain... ?
17:52:22 <devananda> and we massage if needed to land it all pretty quickly
17:52:25 <vdrok> It's a leftover of the old chain
17:52:52 <rloo> devananda: or does it matter whether the API patch is at the front or end of the chain. Should the first patch be -2 until the entire feature is 'ready'?
17:52:55 <devananda> yea - I'm fine with landing DB and RPC changes and the like. we already did some of those (months ago)
17:53:07 <vdrok> devananda: well, there is an experimental job on the very last patch
17:53:24 <devananda> rloo: first API-affecting patch is -2'd until whole feature is ready
17:53:24 <vdrok> I try to retrigger it every time
17:53:40 <devananda> vdrok: perfect! I looked at the first patch and didn't see it. my bad
17:53:42 <vdrok> But I'm fine with adding tempest API tests to
17:53:44 <rloo> devananda: ok, got it.
17:53:45 <dtantsur> I'm +0 for -2ing the first *API* patch
17:54:05 <dtantsur> -0 for -2ing the first patch touching internals (just to clarify, seems like nobody implies that)
17:54:18 <devananda> dtantsur: agreed, and that is what we did so far :)
17:54:23 <devananda> several internal patches already landed
17:54:39 <vdrok> Devananda it's complicated :) last one being https://review.openstack.org/#/c/296432/
17:54:54 <vdrok> It's not shown in related changes
17:54:59 <devananda> vdrok: yea ... and there were many rebases and refactorings over the last few weeks, whicih, honestly, I didn't follow closely
17:55:11 <devananda> vdrok: not shown? they should all have the same gerrit topic, no?
17:55:33 <dtantsur> vdrok, why do you need ironicclient there?
17:55:37 <vdrok> Yeah, but they are not on top of each other
17:55:46 <vdrok> There is a depends on
17:55:56 <vdrok> Topic is the same I think
17:55:59 <devananda> dtantsur: I suspect that's for devstack, so it can define the new things
17:56:08 <vdrok> devananda: correct
17:56:11 <devananda> vdrok: ah. I see
17:56:29 <dtantsur> devananda, vdrok, in inspector with temporary switch to CURL to avoid such situations
17:56:36 <dtantsur> I know it does not sound cool.. but it does the job
17:56:57 <devananda> this is also what tempst API testing is good for
17:57:03 <thiagop> 2min warning
17:57:04 <devananda> it does not rely on any python-*client libs
17:57:20 <dtantsur> devananda++ I don't get why we need to depend on ironiccleint
17:57:28 <vdrok> Well, it's all already there, so if there is some serious rain I'd keep it with one temp patch :)
17:57:37 <dtantsur> anyway, do we agree to use -2 only on the 1st API-touching patch?
17:57:43 <vdrok> *reason
17:57:50 <devananda> also, to note, the experimental job IS passing! :)
17:57:54 <devananda> http://logs.openstack.org/32/296432/51/experimental/gate-tempest-dsvm-ironic-multitenant-network-nv/c0aefa1/
17:57:55 <dtantsur> \o/
17:57:59 <vdrok> ++++ :)
17:58:06 <devananda> dtantsur: WFM
17:58:20 <dtantsur> 2 minutes and I want to have actions items :)
17:58:23 <dtantsur> so, lemme try
17:58:31 <devananda> dtantsur: do we agree that I'll remove that -2 once everything after that patch is +2'd and ready to land?
17:58:43 <vdrok> I'm OK with that
17:58:52 <dtantsur> #action vdrok and others to move API-changing patches further to the end of the chain
17:59:00 <dtantsur> right ^^^?
17:59:24 <vdrok> Yup
17:59:42 <dtantsur> #action devananda will remove his -2 for the 1st API-changing patch as soon as the patches are +2ed and ready for land
17:59:55 <dtantsur> and we don't have time left :)
18:00:01 <NobodyCam> Thank you all .. and Great job running the meeting dtantsur!
18:00:06 <dtantsur> thanks all!
18:00:10 <dtantsur> #endmeeting ironic