17:00:20 <jroll> #startmeeting ironic
17:00:21 <openstack> Meeting started Mon Dec 21 17:00:20 2015 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:24 <openstack> The meeting name has been set to 'ironic'
17:00:26 <vdrok> o/
17:00:26 <dtantsur> o/
17:00:28 <mgould> o/
17:00:28 <jroll> is anyone actually here today?
17:00:37 <stendulker> o/
17:00:55 <jroll> hooray, we have people
17:01:01 <jroll> so as always the agenda is here:
17:01:03 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:01:09 <lucasagomes> :-)
17:01:11 <jroll> #topic Announcements and reminders
17:01:18 <jroll> I have nothing here; does anyone else?
17:01:19 <rloo> hi
17:01:31 <dtantsur> gate is still half-broken \o/
17:01:35 <jroll> /o\
17:01:36 <rloo> jroll: any status wrt gate?
17:01:49 <jroll> it isn't great.
17:01:51 <rloo> sigh. should we do 'recheck's or ?
17:01:52 <dtantsur> inspector gate is broken too, but by another cause
17:02:15 <rloo> jroll: is it due to cleaning or something else? (the ironic gate)
17:02:15 <jroll> here's the latest graph http://tinyurl.com/jqzpjl5
17:02:25 <jroll> it's due to nested virt being super slow
17:02:35 <lucasagomes> we've bumped the timeout to 900 but still very inconsistent
17:02:38 <mgould> wow, that's a lot of failures
17:02:44 <TheJulia> o/
17:03:05 <rloo> although it seems to be getting 'better' the past day...
17:03:06 <lucasagomes> maybe some immediate changes would be to disable some tests such as rebuild and/or cleaning
17:03:13 <lucasagomes> until we sort everything out
17:03:15 <dtantsur> lucasagomes, that was my thought too
17:03:29 <jroll> rloo: yeah, I think it's improved slightly
17:03:31 <lucasagomes> ofc it will lower or coverage
17:03:37 <lucasagomes> our*
17:03:40 <jroll> rebuild is probably the biggest win there
17:03:52 <lucasagomes> yeah
17:04:00 <jroll> I also have this to disable cleaning temporarily https://review.openstack.org/259046
17:04:02 <lucasagomes> because with rebuild we are basically deploying it twice
17:04:13 <dtantsur> should/can we move rebuild to a separate non-voting job?
17:04:23 <dtantsur> it's unlikely we'll break it too often
17:04:34 <jroll> we could yeah
17:04:44 <lucasagomes> yeah
17:04:52 <dtantsur> jroll, I'd say keep cleaning, but remove rebuild.. cause cleaning is something everyone uses
17:05:03 <lucasagomes> I wonder if we have a way to test those stuff more directly, like starting with a active node and rebuilding it
17:05:11 <lucasagomes> instead of going trhough the whole deploy + rebuild process
17:05:14 <lucasagomes> same for cleaning
17:05:15 <jroll> lucasagomes: ++
17:05:18 <lucasagomes> but that's fft
17:05:21 <jroll> and split those tests out
17:05:24 <lucasagomes> yes
17:05:24 <jroll> fft?
17:05:28 <lucasagomes> food for thought
17:05:32 <jroll> oh yeah
17:05:37 <jroll> it's a good idea
17:05:41 <dtantsur> yeah...
17:05:59 <jroll> we need TheJulia's feature here :)
17:06:08 <lucasagomes> ++
17:06:09 <jroll> https://review.openstack.org/#/c/238904/
17:06:13 <rloo> well, besides fft. I'm hungry; what do we do now-ish?
17:06:25 <lucasagomes> the tinyipa is also a good promess, but currently it's installing (cached) the IPA dependencies at boot time
17:06:32 <rloo> should we disable cleaning for now? jroll's patch?
17:06:32 <lucasagomes> and it's *very* slow in a nested VM
17:06:40 <lucasagomes> like took me 10 min on local tests
17:06:56 <TheJulia> jroll: I've been slack on revising it, I'll do the required rewrite at this point sometime tomorrow
17:07:00 * mgould was wondering what Fast Fourier Transforms had to do with this :-)
17:07:10 <dtantsur> mgould++
17:07:12 <lucasagomes> if we can install everything at image build time, and at boot time just activate the venv and run IPA I bet it would be real quick
17:07:15 <jroll> rloo: dtantsur: I think disabling rebuild might be the right thing to do here, however that's a tempest patch and might take time to get through during the holidays
17:07:37 <dtantsur> jroll, we can do both things and revert the cleaning patch asap
17:08:02 <jroll> dtantsur: sure, that works
17:08:02 <rloo> jroll, what dtantsur said ++
17:08:10 <lucasagomes> jroll, what if we add the tempest patch and some dummy patches in Ironic with depends-on
17:08:12 <jroll> ok, I'll un-wip that I guess
17:08:15 <lucasagomes> just to see if it will help out
17:08:23 <lucasagomes> like a couple of rechecks there to verify
17:08:28 <jroll> lucasagomes: sure, that doesn't help get tempest reviewers on it
17:08:45 <lucasagomes> yeah, but helps out with data
17:08:54 <jroll> mhm
17:09:02 <rloo> jroll: although jenkins didn't like your disable-cleaning patch :-(
17:09:11 <jroll> rloo: I just rebased it
17:09:20 <rloo> jroll: ok, here's hoping...
17:09:28 <jroll> rloo: it was the bashate thing
17:09:47 <jroll> dtantsur: can you do the tempest rebuild patch?
17:10:40 <dtantsur> jroll, sure.. just delete the code for now, right? or make a configuration defaulting to false?
17:10:51 <jroll> dtantsur: either way, I'm not opinionated
17:10:56 <jroll> we need to get that stuff in our tree
17:11:27 <rloo> if it is 'as easy', i'd say add a config. just in case we want it.
17:11:33 <Guest66263> sambetts: regarding #213262, do you have any link to the out of tree implementation of the functions you had mentioned?
17:11:39 <dtantsur> rloo++
17:11:46 * dtantsur clones tempest
17:11:46 <jroll> okay, any other announcements?
17:12:18 <jroll> moving on...
17:12:19 <rloo> jroll: do you want to mention rfe bugs or leave that to email?
17:12:38 <jroll> rloo: go for it
17:12:43 <rloo> forget it, i think it was going to be via email
17:12:46 <jroll> heh
17:12:56 <jroll> quick note, we're using RFE bugs instead of blueprints now
17:13:01 <jroll> read your email for more info :)
17:13:05 <rloo> oh, but vdrok moved all bps to rfe bugs so a big applause and thank you
17:13:12 <jroll> ++ thanks vdrok!
17:13:24 <vdrok> np :)
17:13:24 <jroll> #topic subteam status updates
17:13:26 <krotscheck> o/
17:13:33 <jroll> as always, these are here:
17:13:35 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:13:46 <mgould> vdrok++
17:14:15 <jroll> I'll give folks a moment to update^W look over those
17:14:59 <rloo> dtantsur: wishlist isn't necessarily rfe's, right?
17:15:14 <dtantsur> rloo, right, but it's much easier to implement
17:15:24 <dtantsur> so I decided it's close enough
17:15:31 <jroll> well, fixing a bug should never be a "wishlist" item
17:15:31 * dtantsur does not like launchpad API
17:15:37 <jroll> so all wishlist things should be features
17:15:39 <dtantsur> ++
17:16:00 <rloo> jroll: ok, but not all wishlists require specs :)
17:16:11 <dtantsur> not RFE's as well :)
17:16:21 <jroll> ^
17:16:59 <rloo> so they are features but not rfe's.
17:17:08 <rloo> not necessarily rfe's.
17:17:17 <jroll> not necessarily *tagged* as rfe
17:17:18 * krotscheck is back from vacation, so things are starting up again.
17:17:27 <jroll> but any feature request is a "request for enhancement"
17:17:29 <jroll> right?
17:17:44 <vdrok> I think it is
17:17:44 <rloo> so what should be tagged as rfe?
17:17:46 <lucasagomes> sounds like
17:18:02 <jroll> any bug that is a feature request
17:18:15 <rloo> what's the diff between a 'feature' and a 'feature request'?
17:18:26 <jroll> a feature is code?
17:18:36 <jroll> words are hard
17:18:53 <rloo> yeah, just want it to be somewhat clear so we know.
17:18:56 <jroll> when we're talking about a bug report, anything that is a feature request/submission, and not a bug, is a 'feature'
17:19:02 <vdrok> I guess we're moving to the next topic :)
17:19:03 <dtantsur> rloo, RFE is when a person asks for a feature, but does not want to implement it
17:19:12 <lucasagomes> vdrok, ++
17:19:22 <rloo> but there are lots of rfes where people want to implement it
17:19:34 <dtantsur> rloo, if a person wants to submit code right now, it's already not an RFE, but we also count them as RFE for simplicity
17:19:38 <dtantsur> that's how I understand it
17:19:40 <devananda> dtantsur: I would say, RFE includes when someone proposes code -- they're requesting that we accept the feature into mainline.
17:19:50 <jroll> it is an RFE, but they're also deciding to implement it themselves
17:19:57 <jroll> devananda++
17:20:04 <rloo> so what can be a 'feature' that isn't tagged as an rfe?
17:20:08 <devananda> so the "feature request" is the request they made, and the "implementation" of that RFE is the code they proposed
17:20:19 <jroll> rloo: nothing IMO
17:20:20 <dtantsur> rloo, looks like nothing
17:20:24 <devananda> rloo: something we already implemented and accepted into trunk?
17:20:38 <devananda> like "feature X" was included in the Kilo release
17:20:56 <dtantsur> well, something like "refactor the docs" might be wishlist, but not RFE
17:21:00 <rloo> so to go back to our bug tracking system, the features are indicated in the bug system as 'wishlist'.
17:21:02 <dtantsur> cause it's not a feature in ironic
17:21:04 <dtantsur> but dunno
17:21:12 <jroll> this is all a question of reporting, right?
17:21:22 <jroll> for now, wishlist is close enough to RFE for me.
17:21:29 <rloo> but we are distinguishing bugs - 'wishlist' as some being tagged with rfe and others not.
17:21:31 <jroll> in the future we can improve that
17:21:43 <jroll> it's a transition period
17:22:08 <rloo> if 'wishlist' should all be rfe's, then there's no need to tag them.
17:22:18 <lucasagomes> rloo, I tend to agree with ruby here
17:22:28 <rloo> or even prepend with 'RFE' ?
17:22:31 <lucasagomes> just use what it's already there
17:22:40 <vdrok> rloo, e.g. there is a bug about possibility to run tests under mac, it is a wishlist but not rfe
17:22:41 <dtantsur> as I said above, wishlist items not necessary feature in ironic, might be something like "refactor tests"
17:22:51 <jroll> well, look at my comments on the docs change
17:22:53 <devananda> dtantsur: ++
17:22:59 <jroll> I propose a 'rfe-approved' tag like neutron uses
17:23:07 <jroll> in which case the tags *are* useful
17:23:26 <rloo> jroll: so do all wishlists need a 'rfe-approved' tag?
17:23:37 <jroll> rloo: no.....
17:23:48 <rloo> we can take this discussion elsewhere, i'm just a bit confused probably
17:23:49 <jroll> all approved RFEs get that tag
17:23:56 <jroll> all unapproved get the 'rfe' tag
17:24:01 <vdrok> so here is what I concluded from discussions in doc patch and irc
17:24:09 <devananda> rloo: I think I'm confused too, fwiw
17:24:11 <vdrok> 1. create an rfe bug, in new state, wishlist priority, set assignee if possible;
17:24:11 <vdrok> 2. someone from ironic-drivers should move it to confirmed state to show the idea is valid (or change the tag to rfe-approved?);
17:24:11 <vdrok> 3. you can add code right away before waiting for approval, if a spec is needed, code will be -2'ed;
17:24:11 <vdrok> 4. if the feature is not needed a bug will be moved to won't fix and spec/code -2'ed.
17:24:17 <lucasagomes> rloo, same here
17:24:48 <rloo> but dtansur's example of a wishlist to 'refactor tests' is not a rfe? (i think it should be but if it isn't) how do folks now it isn't and doesn't require rfe-approved?
17:24:52 <vdrok> this is for feature requests^
17:25:23 <dtantsur> rloo, test refactoring is not a feature IMO
17:25:47 <rloo> dtantsur: seems like a feature of our infrastructure, but regardless, let's say it isn't a feature.
17:25:58 <rloo> dtantsur: but it is a 'wishlist' bug. so I see a patch that addresses that bug.
17:26:05 <mgould> "feature" usually implies "user-visible", IMO
17:26:10 <rloo> dtantsur: how do i know whether it needs a rfe-approved tag before +A'ing it?
17:26:24 <jroll> rloo: because the bug triager will tag it as 'rfe'
17:26:30 <mgould> "request for enhancement" could mean almost anything
17:27:17 <rloo> jroll: but what is the absence of a rfe tag mean? that the bug triager forgot to tag it? how do i know that it shouldn't be rfe?
17:27:42 <lucasagomes> mgould, yeah, I see it that way too
17:27:52 <jroll> rloo: well, you could decide that for yourself, or look at the history and see if it's been triaged, and ask
17:28:04 <jroll> rloo: common sense and such
17:28:14 <vdrok> jroll, ++
17:28:24 <rloo> it isn't really a new question. even with BPs, i've seen bugs in the past that seemed to be features in disguise.
17:28:45 <jroll> rloo: yep, this makes it easier to handle those features
17:29:04 <jroll> rloo: I've been trying to watch for those and ask for BPs instead, but didn't do a good job
17:29:09 <rloo> so 'common sense' to me meant asking whether it should be a bp/spec, but clearly it wasn't common sense to some others. or my common sense radar is off :)
17:29:17 <devananda> this is an ever-ongoing debate -- is X a bug or a feature? -- and we'll never have an answer that works for everyone, because it is subjective
17:29:53 <rloo> devananda: right. and now that we have them 'bundled' into the bugs/wishlist, i wonder if things will get muddier. i guess we'll see...
17:30:06 <devananda> rloo: but I would suggest you use this test: is the behavior being reported clearly NOT the intended behavior? if so, it's clearly a bug.
17:30:26 <dtantsur> things were like that already, people filed pretty a lot of wishlist items and bugs like "X does not support Y"
17:31:22 <devananda> and then we err on the side of caution and tag things which are in the grey zone as RFE's
17:31:47 <devananda> *and either we ...
17:31:55 <devananda> or we just leave them as wishlist items
17:33:49 <jroll> funny store, I just realized this was the one agenda item
17:33:54 <rloo> ok, if something is unclear, i'll bring it up. i'd actually prefer if the wishlist items had a comment saying 'rfe not needed' and they default to rfe, but anyway.
17:33:56 <lucasagomes> maybe we just need to say: bugs or enhancement... e.g If it's fixing something it's a bug. Anything else is an enhancement: adding a new feature, fixing docs, refactoring tests
17:34:07 <lucasagomes> and then in the ehancements we can say what need a spec and what not
17:34:22 <lucasagomes> like docs, tests refactor etc don't need one... but things affects multiple areas of the project does need it
17:35:05 <lucasagomes> then we can decide how to distinguish it in the bug tracker, either using the tags or wishlist
17:35:27 <dtantsur> well, wishlist == RFE gives us a simpler procedure
17:37:14 <lucasagomes> right
17:37:22 <vdrok> so, should we start with rfe/rfe-approved tags, or just wishlist bugs?
17:38:16 <lucasagomes> I think we first need to decide whether we are tracking: bugs, features and others enhancements... or just bugs and enhancements (if that makes sense)
17:38:18 <dtantsur> wishlist + [RFE] in title to help triagers to understand the intent?
17:38:20 <rloo> vdrok: i thought it was 'wishlist-no tags', 'wishlist-rfe tag' -> 'wishlist-rfe-approved tag'.
17:38:54 <rloo> does rfe-approved mean either spec is approved or no spec is needed, and description in bug is sufficient?
17:39:16 <mgould> rloo, +1 to that idea
17:39:40 <vdrok> I think rfe-approved means that idea is valid, if there needs to be a spec the code can just be -2ed
17:39:55 <vdrok> or it can be written in bug comments
17:40:09 <rloo> lucasagomes: i think we want to track enhancements, just that there seems to be 2? types; ones that need detailed (spec) description, others that don't?
17:40:52 <rloo> vdrok: OH. rfe-approved == 'this is approved to be classified as an rfe'?
17:41:22 <vdrok> rloo, thats what I thought initially, but it can be whatever we decide :)
17:41:24 <jroll> O_O
17:41:37 <jroll> rfe-approved == spec is approved, or no spec required
17:41:42 <jroll> 'ready to land the code'
17:41:51 <lucasagomes> rloo, right, but what confuses me is the tagged/non-tagged
17:42:05 <rloo> jroll: that's what I thought it should mean :)
17:42:06 <mgould> do we have to use these tags, or can we create "spec-needed" and "has-enough-spec" tags for clarity?
17:42:19 <jroll> so
17:42:24 <jroll> we're trying to mirror what neutron did
17:42:28 <jroll> because it works well for them
17:42:41 <jroll> I think we should start there and see how it goes
17:42:45 <jroll> and change things as needed
17:42:52 <vdrok> In either case (a spec being required or not), once the discussion has happened and there is positive consensus on the RFE, the report is ‘approved’, and its tag will move from ‘rfe’ to ‘rfe-approved’.
17:42:52 <mgould> OK
17:43:20 <vdrok> but yes, we can make it our own way
17:43:30 <jroll> that is here fwiw http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
17:43:32 <mgould> jroll, so the answer to "what does tag X mean" should be "whatever Neutron currently means by it" for now?
17:43:45 <jroll> mgould: well, we're working on documenting it in our docs
17:43:54 <jroll> but I'd like to model those from neutron's model
17:44:03 <rloo> vdrok: but how is there a discussion/positive consensus on an rfe if there is no spec/not clear that the bug/wishlist needs a discussion etc?
17:44:21 <jroll> minus the BP junk
17:44:50 <rloo> jroll: i'm a bit hesitant to 'just' do what neutron did if it isn't clear how it works. if it is clear to some of you then fine. if it isn't, then it seems better to think about it now, than to confuse us all later with more change.
17:45:05 <vdrok> rloo, someone from ironic-drivers decide that the idea is valid, it is a new feature indeed, and adds rfe-approved and says this requires a spec/can be implemented as is
17:45:13 <jroll> rloo: sure, we should be clear on it, and it shuold be agreed
17:45:20 <rloo> and the 'ironic-drivers' thing is another thing...
17:45:47 <jroll> rloo: I just don't like stalling for days while we're in the middle of a process change :|
17:45:49 <rloo> vdrok: but jroll just said rfe-approved == spec is approved
17:46:03 <jroll> rloo: yeah, reading again maybe I read that wrong :/
17:46:29 <rloo> i think mgould? mentioned 'spec-needed', 'spec-approved' might be clearer for me/us.
17:46:31 <vdrok> or maybe i did ^)
17:46:36 <devananda> rloo: ironic-drivers isn't the team which sets bug tags, priority, etc. that is ironic-bugs
17:46:57 <devananda> however, neutron uses a closed bug team and (so far) we do not
17:47:06 <devananda> so with this change, perhaps we should be
17:47:07 <rloo> devananda: yeah, i know. we can discuss that later. ironic-drivers to me means people resp for the drivers part of ironic!
17:47:34 <devananda> rloo: heh, well, that's not what it is.
17:47:47 <jroll> $project-drivers historically in openstack means the people driving the project direction
17:48:04 <jroll> and has always meant that for us, as well
17:48:08 <devananda> xxx-drivers are the launchpad teams which "own" projects, set milestones, create releases, and manage the projects' front page on LP
17:48:10 <rloo> jroll, devananda: OH. that explains it.
17:48:27 <jroll> :)
17:48:41 <rloo> drivers is overloaded. too much :-(
17:49:50 <rloo> so we need to agree on *how* to handle bug/wishlist stuff, and *who* can manage that process
17:50:03 <devananda> rloo: yes
17:50:05 <rloo> s/agree/describe/ :)
17:50:05 <jroll> yep
17:50:11 <jroll> let me write a clear proposal this week
17:50:14 <jroll> on the emails
17:50:18 <devananda> ++ to emails
17:50:23 <rloo> ok, action item for jroll! thx!
17:50:25 <lucasagomes> ML ++
17:50:44 * rloo looks at rest of subteam reports :)
17:50:52 <devananda> I'd suggest we not change the launchpad teams' membership or access rights too much until we're all clear on what the direction will be
17:51:30 <jroll> well, I've added specs cores to ironic-drivers
17:51:35 <jroll> which I think is accurate regardless
17:52:29 <rloo> jroll: i'm not sure of that. you trust me to set milestones and create releases? :D
17:52:37 <jroll> rloo: yep, deal with it :)
17:52:46 <jroll> rloo: oh, and manage blueprints, the best part
17:52:53 <lucasagomes> lol
17:52:55 <rloo> jroll: no worries. blueprints are DEAD!
17:52:59 <dtantsur> :D
17:52:59 <jroll> \o/
17:53:20 <rloo> i'm good with the rest of the subteam reports. sorry i digressed from that.
17:53:30 <jroll> it's okay, you covered the only topic we had ;)
17:53:56 <jroll> I don't see anything crazy there
17:54:07 * jroll moved topics
17:54:10 <jroll> #topic open discussion
17:55:58 <jroll> anyone have anything?
17:58:20 <mgould> any code reviews I could help with?
17:58:30 <dtantsur> mgould, all of them :D
17:58:30 <jroll> all of them!
17:58:34 <dtantsur> LOL
17:58:36 <mgould> curses
17:58:41 <rloo> thx mgould :D
17:58:43 <jroll> mgould: manual cleaning or network stuff are the big ones right now
17:59:01 <mgould> jroll, cool, I'll prioritise accordingly :-)
17:59:15 <jroll> THANK YOU for being awesome and wanting to review things :)
17:59:17 <rloo> mgould: our priorities in Mitaka: http://specs.openstack.org/openstack/ironic-specs/priorities/mitaka-priorities.html
17:59:47 <jroll> alright, time to shut this thing down
17:59:49 <mgould> jroll, I saw the stats this afternoon and noticed how few I'd done :-)
17:59:56 <vdrok> yep, thanks
17:59:58 <jroll> thanks everyone for the invigorating monday morning discussion :)
18:00:03 <jroll> #end,eeting
18:00:07 <jroll> #endmeeting