14:00:08 <kashyap> #startmeeting
14:00:08 <zodbot> Meeting started Wed Jan 15 14:00:08 2014 UTC.  The chair is kashyap. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:11 * mburned here
14:00:26 <kashyap> #meetingname RDOBugTriage
14:00:26 <zodbot> The meeting name has been set to 'rdobugtriage'
14:00:43 <kashyap> #link https://etherpad.openstack.org/p/RDO-BugTriage
14:01:10 <kashyap> #link  List of un-triaged bugs (NEW state) -- http://goo.gl/NqW2LN
14:01:20 <kashyap> mburned, Heya!
14:01:49 <kashyap> So, looking at the number of untriaged bugs, we have 75. Let's see how many we can go through in ~hour
14:01:57 <weshay> nice
14:02:14 <mburned> kashyap: i see 61...
14:02:35 <mburned> counts i see 61, 31, 11
14:02:36 <larsks> Hello all.  Just catching up...
14:02:47 <mburned> for new/assigned/on_qa
14:03:00 <kashyap> mburned, IIRC, it has a different view for folks w/ @redhat.com -- CVEs, and other related issues?
14:03:05 * kashyap waves at larsks
14:03:31 <kashyap> Ok, sorting by ID, does everyone see 957408 at the top?
14:03:33 <weshay> must be more than just @redhat.com, I see 61
14:03:41 * mburned is @redhat.com
14:03:43 <weshay> ack 957408
14:03:50 <mburned> yes 957408
14:03:55 <kashyap> Cool.
14:04:15 <kashyap> We don't just yet have a well defined bugzilla process for RDO bugs
14:04:32 <weshay> does anyone other than rhel :)
14:04:40 <kashyap> :-)
14:05:08 <kashyap> # Keyword that can be used 'Triaged' to indicate if a bug has been fully triaged
14:05:37 <kashyap> Ok, 957408 --
14:06:00 <weshay> guess its firefox only
14:06:02 <ndipanov> kashyap, there is one bug I reported for iscsi-initiator-utils
14:06:05 <larsks> kashyap: Should "triaged" also come with "assign" or "closed" status?
14:06:11 <kashyap> The user just mentions 'yes' without further info as to what he has tested with, should this be set to NEEDINFO again?
14:06:15 <ndipanov> kashyap, is there a trick to pick it up by this query?
14:06:38 <kashyap> larsks, Yeah, I'm wondering - we can't just arbitrarily assign, as folks are all busy w/ bugs of shifting prioroties
14:06:48 <kashyap> ndipanov, Sorry, pick 'what' up?
14:07:13 <mburned> ndipanov: looks like criteria is in Community/RDO, NEW state and assignee=rhos-maint@redhat.com
14:07:27 <kashyap> larsks, pixelb may have a better answer for your question
14:07:33 <ndipanov> mburned, hmm ok let me go find the bug
14:07:36 <mburned> and doesn't have "Triaged" in keywords
14:07:57 <kashyap> ndipanov, Ah, just read your previous question
14:08:54 <weshay> imho.. looks like the reporter indicates firefox is still an issue as of dec 13.
14:09:06 <weshay> er 20
14:09:12 * kashyap sets 957408 to NEEDINFO based on my previous note - reporter hasn't provided enough info on *what* exactly he's tested with
14:09:28 <kashyap> weshay, On 957408?
14:09:35 <mburned> kashyap: there are some details in the forum linked in comment 2
14:09:41 <weshay> the above issue occurs with firefox but google chrome will work. havent tested with konqueror
14:09:46 <mburned> packstack allinone
14:10:01 <kashyap> mburned, Thanks, I just scrolled down to last two comments
14:11:27 <weshay> is there anyone in charge off checking horizon on multiple browsers?
14:11:44 <kashyap> weshay, mrunge/jpich [Horizon folks] are not here to comment on it
14:11:53 <weshay> k
14:11:54 <larsks> 1052311 is a request for an update python-neutronclient.  Seems like a legitimate RFE...what to do?
14:12:05 <mburned> live image runs packstack and launches firefox
14:12:06 <larsks> ...for RFEs in general?
14:12:21 <weshay> mburned, ah tru
14:12:35 <mburned> weshay: and you reported the issue with 127.0.0.1
14:12:37 <kashyap> larsks, RFEs sometime just linger around
14:12:39 <mburned> not loading
14:12:54 <mburned> but localhost or <ip-address> works with latest havana packages
14:12:56 <mburned> on centos 6.5
14:13:16 <larsks> kashyap: So, leave them alone, mark them triaged but otherwise ignore...?
14:13:35 <weshay> mburned, is that a question? I only sent feedback to you, I did not open a bz. I can though :)
14:13:40 <kashyap> larsks, Mark it as [RFE], and add 'Triaged' keywod?
14:13:41 <mburned> oh, wait...that's just loading horizon, not the console of an instance
14:13:48 <larsks> kashyap: Done and done.
14:13:54 <mburned> weshay: no component for bz yet
14:14:04 <weshay> k
14:14:06 <mburned> i fixed it already, just haven't uploaded a new image
14:14:17 <weshay> component for the live image? +1
14:14:34 <mburned> weshay: i need to request the component
14:14:39 * mburned will after this meeting
14:15:16 <kashyap> larsks, You said Done, is that for 1052311 Or did you update a different bug?
14:16:17 <larsks> That was for 1052311, yes.
14:16:19 <kashyap> ndipanov, Hi, I tried to reproduce this once (can't find my notes), and looks like a legitimate - https://bugzilla.redhat.com/show_bug.cgi?id=958411
14:16:36 <mburned> kashyap: larsks:  shouldn't the bug be assigned to someone who can make a decision on whether to fix it?
14:16:46 <mburned> seems wrong to mark triaged without assigning to someone
14:17:03 <weshay> +1
14:17:04 <larsks> mburned: Assign to package maintainer, maybe?
14:17:06 <kashyap> mburned, Right,
14:17:13 <weshay> is 958411 next?
14:17:20 <kashyap> But can we you arbitrarily pick Neutron developers?
14:17:22 <mburned> that would make sense (package maintainer)
14:17:40 <kashyap> Yep
14:17:43 <larsks> mburned: How do I find maintainer for a specific package?
14:17:47 <kashyap> weshay, Yeah,
14:17:57 <kashyap> #info http://openstack.redhat.com/DeveloperTips
14:18:06 <kashyap> larsks, You can run $ pkgdb-cli acl openstack-neutron
14:18:11 <kashyap> To see ACLs for a package
14:18:26 <kashyap> First,  $ yum install packagedb-cli -y
14:18:37 <larsks> kashyap: Yup, have that already.  Thanks for the command!
14:19:19 <mburned> that's useful
14:19:33 <mburned> i only knew the command to ask the internal bots about who owns a package
14:19:38 <kashyap> Yeah, I find it very handy w/o having to resort to a bulky browser
14:19:47 <mburned> fwiw, python-neutronclient is owned by jruzicka
14:20:07 <larsks> mburned: ...who isn't even on the acl list returned by pkgdb-cli :/
14:20:22 <mburned> larsks: for openstack-neutron
14:20:31 <mburned> bug is filed against python-neutronclient
14:20:36 <larsks> Right.
14:20:45 <jruzicka> mburned, are you interested abou8t neutronclient?
14:20:51 <mburned> so i ran pkgdb-cli acl python-neutronclient
14:20:58 <mburned> jruzicka: we're looking at bug 1052311
14:21:04 <kashyap> larsks, mburned is correct
14:21:11 <jruzicka> mburned, I packaged latest python-neutronclient, CI is just running on it
14:21:19 <larsks> jruzicka: Then you get this bz :)
14:21:21 * jruzicka looking
14:21:23 <kashyap> larsks, You might have missed the 'devel owner' at the top? :-)
14:21:39 <larsks> kashyap: Yes.  Looking...
14:21:55 <jruzicka> I'm maintaining all *client packages
14:21:59 <larsks> jruzicka: Thanks!
14:22:06 <jruzicka> but I'm not listed as owner in koji/bodhi
14:22:21 <jruzicka> secret maintainer, I guess :)
14:22:37 <mburned> ok, so just to close the loop on 1052311, we'll assign to jruzicka and mark triaged, then we can move on
14:22:43 * pixelb assigned/closed the two openstack-utils bugs
14:22:46 <larsks> mburned: Yup, done.
14:23:06 <mburned> #info bug 1052311 assigned to jruzicka and marked triaged
14:23:13 <mburned> now back to the list...
14:23:18 <mburned> kashyap: what's next?
14:23:23 <kashyap> mburned, https://bugzilla.redhat.com/show_bug.cgi?id=958411
14:23:28 <ndipanov> kashyap, yeah - probably - check if there's an upstream bug for that
14:23:31 <kashyap> I was looking at that
14:23:38 <ndipanov> I seem to remeber there being some talk about it
14:24:03 * kashyap quickly searches LP
14:24:28 <weshay> ordered by date of action, +1
14:24:47 <larsks> kashyap: https://blueprints.launchpad.net/python-novaclient/+spec/instance-action-list-output
14:25:26 <kashyap> larsks, Thanks, it says, already fixed?
14:25:49 <larsks> Yeah, the gerrit page says "merged"
14:25:56 <larsks> https://review.openstack.org/#/c/27251/
14:26:50 <kashyap> The bug was filed /after/ the above review, so a regression?
14:27:11 <larsks> Did fix make it into our packages?
14:27:36 <kashyap> Good point
14:27:47 <larsks> Hmmm, merged in April 2013.
14:28:27 <kashyap> Yeah, I was about to add a comment to that effect & set NEEDINFO on reporter to try w/ newer version?
14:28:29 <kashyap> Is that fair?
14:28:37 <weshay> y
14:29:31 <kashyap> Done.
14:30:05 <kashyap> But I'm not sure if we should mark such bugs as Triaged (as it's not assigned, and is in a ping-pong mode)
14:30:12 <larsks> kashyap: Fix is in python-novaclient-2.15.0-1.fc20.noarch
14:30:23 <larsks> (which is what's installed on my system right now)
14:30:36 <mburned> #info bug 958411 has patch merged in https://review.openstack.org/#/c/27251/
14:30:47 <mburned> #info asked reported to try with latest packages
14:31:10 <kashyap> larsks, mburned, This can be moved to POST state.
14:31:24 <kashyap> Since the fix is already available/committed.
14:31:37 <kashyap> If either of you doing it, please go ahead, don't want to step on toes.
14:31:44 <larsks> Not it.
14:31:51 <mburned> kashyap: to mark triaged, we should assign it to someone from the nova team, i would think
14:31:56 * mburned not making changes in bugzilla
14:32:20 <mburned> and if it's fixed in a package already, why POST and not ON_QA?
14:32:22 * kashyap runs $ bodhi -L python-novaclient to see what's the latest
14:32:24 <kashyap> available
14:32:44 <kashyap> mburned, Confirming if it's in package or not for EPEL
14:33:16 <kashyap> Ok, it's in dist-6E-epel-testing-candidate  python-novaclient-2.15.0-1.el6
14:33:50 <mburned> kashyap: 2.15.0-1.el6 is also posted to the repos.fedorapeople.org/repos/openstack yum repo
14:33:59 <mburned> http://repos.fedorapeople.org/repos/openstack/openstack-havana/epel-6/
14:34:28 <mburned> kashyap: we should also link the openstack gerrit fix
14:34:37 <mburned> and the launchpad bug as well
14:34:47 <kashyap> Yes, as external tracker, I'm doing it, and noting larsks for the URL credit :-)
14:35:07 <mburned> ack
14:36:29 <kashyap> Done.
14:36:52 <kashyap> Next - https://bugzilla.redhat.com/show_bug.cgi?id=960024
14:37:43 <kashyap> Oh, it's already is on NEEDINFO I set a month ago
14:38:14 <kashyap> Movoing to next -- https://bugzilla.redhat.com/show_bug.cgi?id=966050
14:38:14 <larsks> But needinfo on rhos-maint...maybe set that to russel explicitly or something?
14:38:32 <mburned> sounds like there is a bug regardless that we're returning 500
14:38:41 <larsks> Right, that too.
14:38:41 <mburned> and need info on the scenarios in comment 2...
14:38:45 <kashyap> larsks, Yeah, I thought I'd wiat to give rhos-maint a chance to triage in their triage meetings
14:39:32 <russellb> sounds like a config issue to me
14:39:35 <russellb> but guess i'd have to try it
14:40:02 <russellb> oh, i see, you're saying that there's no way to disable it because of how the init script works
14:40:29 <russellb> (talking about logging one)
14:40:42 <russellb> agreed we should never return 500
14:41:04 <russellb> heh, and i said that on the bug a long time ago
14:41:05 <russellb> :)
14:41:29 <russellb> for something like that, sounds like the response should be to open a bug in launchpad
14:42:14 <kashyap> russellb, Can I request you please add that comment w/ any related esoteric info you know of, & set needinfo on reporter?
14:42:33 <russellb> nothing really to add right now
14:42:49 <russellb> just saying that in general, when it's clear that there's a bug in nova, i would open a bug in launchpad
14:43:12 <russellb> since it's not a distribution problem, it's an upstream problem
14:43:17 <kashyap> Ok, I'll ask the reporter to open it there. That should be the default attitude, but we slip. . .
14:43:37 <mburned> does it make sense to maintain the RDO bug too?
14:43:52 <mburned> (with the link between the 2?)
14:43:56 <mburned> or just close it?
14:44:10 <kashyap> Can be closed, IMO, otherwise they just go stale
14:44:30 <larsks> Should it closed *after* opening an upstream bug (and linking it)?
14:44:32 <kashyap> (Can be closed *once* the LP bug is fixed & is noted in this RDO bug)
14:44:46 <larsks> Yeah, that :)
14:44:54 <kashyap> larsks, Yes, I thought I'd write it before you got to it :-) But, glad you caught me!
14:45:21 <mburned> so open LP bug, link to RDO bug, close rdo bug?
14:45:34 <mburned> or should step 3 be "wait for LP bug to be fixed"
14:46:34 <kashyap> mburned, Close the RDO bug, if downstreams want to backport, they can reference LP bug in git
14:46:43 <mburned> agreed
14:46:54 <mburned> kashyap: i have to drop for a bit, but i'll read the summary...
14:46:59 <kashyap> Sure.
14:47:06 <kashyap> Meeting wraps in 13 minutes anway
14:48:27 <kashyap> Next - https://bugzilla.redhat.com/show_bug.cgi?id=966050
14:48:58 <larsks> kashyap: I would call it an RFE, but a reasonable one.  The logging generates a lot of chatter in syslog.
14:49:00 * kashyap remembers reading the above bugzilla previously, but didn't chase it down fully
14:49:06 <weshay> I think we should get paid twice for this feature
14:49:34 <larsks> Assign to package maintainer and move on?
14:49:45 <larsks> (Mark as RFE?)
14:49:54 <kashyap> larsks, The reporter just  didn't clone it & mark it as RFE
14:50:04 <kashyap> larsks, Yes, please, if you're in the flow :-)
14:50:24 <larsks> Okay.  Marking as RFE and triaged and assigning...
14:50:34 <kashyap> Thanks.
14:50:50 * kashyap notes - In 10 minutes it'll be an hour. . .
14:51:33 <kashyap> Next - https://bugzilla.redhat.com/show_bug.cgi?id=980292
14:52:29 <kashyap> I think the reporter needs to try w/ newer versions
14:52:31 <larsks> I think this is Not A Bug.  The ovs-cleanup service is a one-shot service.
14:52:33 <kashyap> And, F18 is EOL
14:52:46 <larsks> Right?  That is, it's not something that needs to be stopped because it only runs at boot...
14:52:53 <kashyap> EOL (End Of Life)
14:53:01 <kashyap> larsks, Yes, I remember you educating me on it
14:53:15 <kashyap> larsks, Can you please note that and maybe even close as NOTABUG?
14:53:24 <larsks> Yes, noting.
14:53:27 <larsks> And closing.
14:53:33 <kashyap> Thanks.
14:54:43 <larsks> 980591...
14:55:01 <pixelb> # info 1023673 set to assigned (libguestfs-mount dependency is no longer required)
14:55:16 <kashyap> larsks, It's a security tracking bug, we can leave it as is
14:55:23 <larsks> Yay.
14:56:04 <kashyap> That bug is for QE consumption
14:56:35 <kashyap> And, whoever tests it is responsible for closing (modifying its state - if a new pkg is needed)
14:56:44 <kashyap> pixelb, Nice
14:57:55 <kashyap> pixelb, Are you also marking it as Triaged? Or would you like me to?
14:58:54 <larsks> 995570 is an RFE and already marked as such, but is still assigned to rhos-maint. Assign to mmagr and mark triaged?
14:59:18 <pixelb> kashyap, is Triaged not implicit in states other than NEW ?
14:59:20 <kashyap> https://bugzilla.redhat.com/show_bug.cgi?id=995570 is an RFE from pixelb
14:59:39 <larsks> Yes.
14:59:53 <kashyap> pixelb, Well, yeah. Just making it consistent for querying based on keywords later on
15:00:11 <kashyap> larsks, 995570 is marked as FutureFeature
15:00:26 <kashyap> Can be marked as Triaged, maybe? pixelb is that sensible?
15:00:40 <pixelb> Yep mark that as Triaged
15:00:48 <larsks> Marked.
15:01:08 * kashyap notes it's already top of the hour, we'll wrap in 2 minutes?
15:01:23 <kashyap> larsks, Nice.
15:01:49 * kashyap is updating with all the bugs triaged just for meeting minutes - https://etherpad.openstack.org/p/RDO-BugTriage
15:02:27 <weshay> nice
15:02:33 <kashyap> Or maybe we can continue to triage for some more time if folks have time
15:02:49 <larsks> I'm happy to keep at it a bit more.
15:02:49 <kashyap> It's nicer to triage with some folks around :-)
15:03:23 <kashyap> Cool, let's try a few more
15:04:14 <larsks> 997023: probably needs to be set needinfo on the reporter to see if it's still an issue.
15:04:58 <larsks> Do we set triaged in this case?
15:05:13 <kashyap> Not yet
15:05:28 <larsks> Okay.  Leaving a comment and marking needinfo on reporter.
15:05:30 <kashyap> (I think I know what you're wondering - bug we've spent /time/ on it?)
15:05:56 * kashyap is looking at - https://bugzilla.redhat.com/show_bug.cgi?id=997948
15:06:46 <kashyap> 997948: Reporter doesn't mention versions tested with
15:07:12 <kashyap> Leaving a comment & setting NEEDINFO
15:07:18 <larsks> Yeah, that was my thought.
15:07:28 <larsks> Could be a packaging issue.
15:08:09 <larsks> I am assigning 10000572 to myself.
15:08:42 <larsks> Err, 1000572.
15:08:49 <larsks> Got carried away with the 0 there.
15:09:50 * kashyap hands larsks a cookie
15:10:28 <weshay> the description on https://bugzilla.redhat.com/show_bug.cgi?id=1000851 should probably change to include horizon
15:11:10 <larsks> Well, it says "openstack", which seems to cover everything, right?  This is our whole packstack-doesn't-understand-firewalld issue.
15:11:13 <kashyap> weshay, Feel free to edit? :-)
15:11:27 <weshay> ya.. double checking w/ an install that just came up for me
15:11:59 <larsks> weshay: This is totally still a problem. I brought it up internally just last week...
15:12:15 <weshay> k
15:12:33 <larsks> Also https://bugzilla.redhat.com/show_bug.cgi?id=981583
15:13:11 <larsks> That's opened against fedora, and is assigned to mmagr.  Can we mark 1000851 a dupe of this one?
15:13:35 <kashyap> Is it really a Fedora issue? /me clicks on the bug, first
15:13:54 <larsks> It's a packstack issue that only happens on Fedora because firewalld replaced old iptables service.
15:14:06 <larsks> It will also happen on RHEL7 :).
15:14:37 <larsks> I would still mark 1000851 a dupe, and we can fix the product on 981583 if people think it's necessary.
15:15:34 <kashyap> Please go ahead
15:15:35 <weshay> crud.. will make sure ci tests the fw and access issues
15:15:55 <larsks> weshay: do our ci tests generally involve a reboot?  flushes out all sorts of persistence problems.
15:16:47 <weshay> ya.. we are rebooting after the install
15:16:47 <weshay> http://jenkins.rhev.lab.eng.brq.redhat.com:8080/view/RDO-Havana/job/packstack-rdo-havana-neutron-rhel-production/121/consoleFull
15:17:16 <weshay> but not sure if we're checking for this kind of issue, but we should. Adding to our tasks
15:17:22 <weshay> crud
15:17:25 <weshay> sry
15:17:33 <larsks> kashyap: closed 100851 as dupe:981583.
15:17:56 <kashyap> Thanks.
15:18:46 <kashyap> #chair larsks
15:18:46 <zodbot> Current chairs: kashyap larsks
15:19:06 <weshay> link should have been.. https://prod-rdojenkins.rhcloud.com/view/RDO-Havana/job/packstack-rdo-havana-neutron-rhel-production/111/consoleText
15:19:07 <larsks> ULTIMATE COSMIC POWER
15:19:36 <kashyap> #chair weshay
15:19:36 <zodbot> Current chairs: kashyap larsks weshay
15:19:47 <kashyap> #link https://prod-rdojenkins.rhcloud.com/view/RDO-Havana/job/packstack-rdo-havana-neutron-rhel-production/111/consoleText
15:20:16 <larsks> 1002622 is an RFE for baremetal support.
15:20:56 * kashyap is looking at two identical bugs named -- "Unable to launch an instance" -- 1006518, 1007578
15:21:41 * larsks is still not quite sure what to do with RFEs.
15:22:03 <larsks> Mark traiged, leave assigned to rhos-maint? Or give it to openstack-nova package maintainer?
15:22:10 <larsks> Or triaged, even.
15:23:03 <kashyap> larsks, We cannot mark it as Triaged as it's not really agreed that it needs to be implemented, fair?
15:23:29 <larsks> Okay.  So in general for RFEs, mark them as RFE and otherwise leave them alone?
15:23:54 <kashyap> larsks, Yeah. Or they need to be brought up upstream if they're not packaging specific
15:24:10 <larsks> Okay.  This one is definately packaging specific. Marking as RFE and moving on.
15:24:52 <kashyap> Cool.
15:25:25 <kashyap> Arrgh, the "Unable to launch an instance" issues are woefully short of info & taking a lot more time to parse! That's expected in 'cloudy' environments I guess
15:26:31 <larsks> We've released new packages since they were reported, right?  Mark them as needinfo and see if the issue is still relevant?
15:26:37 <xqueralt> kashyap, re. both "unable to launch an instance"
15:26:39 <weshay> kashyap, ya.. we would need to see more logs, plus their config
15:26:53 <xqueralt> I remember they were related to running packstack several times
15:27:03 <weshay> need info w/ a request for config, all logs etc
15:27:09 <xqueralt> and some of the components not being properly configured
15:27:13 <kashyap> Ok, xqueralt can you mark them so & set NEEDINFO on asignee? Asking you since you have the previous context
15:27:30 <kashyap> Sorry, on reporter, I mean.
15:27:47 <xqueralt> kashyap, OK, I'll take them both and set needinfo
15:28:04 <kashyap> Thank you, Xavier
15:28:58 <larsks> 1006241: rdo-release-havana installs invalid yum repositories on i386 (foreman yum repositories do not have i386 support).
15:29:07 <larsks> Do we support i386 installs for havana?
15:29:57 <kashyap> pixelb, ^
15:30:36 <pixelb> kashyap, larsks Just commenting on that now :)
15:31:41 <larsks> pixelb: Okay, leaving that to  you and moving on :)
15:32:04 <larsks> I am looking at 1008126.
15:32:30 <weshay> bcrochet, fyi https://bugzilla.redhat.com/show_bug.cgi?id=1006241
15:33:10 <kashyap> larsks, Yeah, I remember looking at it, xqueralt already marked it as LOW prio
15:33:27 <larsks> Should it be CLOSED NOTABUG?
15:33:59 <larsks> It's just debug messages caused by debug=True.
15:34:40 <kashyap> Yeah, that seems reasonable to me
15:35:17 <xqueralt> and nova-manage is deprecated, see the last comment in the linked bug: https://bugzilla.redhat.com/show_bug.cgi?id=976327#c2
15:36:13 <larsks> xqueralt: This bug is not about nova-manage (at least not directly -- reporter was running openstack-status).
15:36:26 <larsks> If openstack-status is calling nova-manage, should we fix that?
15:36:43 <larsks> It does not appear to be doing that.
15:36:53 <kashyap> Maybe he's using an older version?
15:37:20 <larsks> Maybe.  Closing as a NOTABUG anyway since they were just debug messages.
15:38:21 <bcrochet> weshay: k
15:38:30 <xqueralt> kashyap, the latest version of openstack-status in github uses nova cli
15:38:53 <larsks> xqueralt: In fact I think that's true for openstack-status in our current packages.
15:39:53 <xqueralt> larsks, in RHOS 4.0 it is still using nova-manage, i don't have any RDO install nearby to check it there
15:40:29 <larsks> xqueralt: Okay.  I have RDO packages installed on F19 and it does not call nova-manage.
15:41:27 <larsks> 1008127: reporter complains about periodic logging of sudo commands from neutron filling up logs.
15:41:51 <weshay> xqueralt, I can check.. in and out of the conversation though..
15:42:10 <larsks> 1008127...Closing as a NOTABUG?  These log messages are expected when using sudo.
15:42:15 <kashyap> larsks, Yeah!
15:44:16 <kashyap> 1013923: is set on NEEDINFO reporter
15:44:19 <weshay> xqueralt, afaict openstack-status is not useing nova-manage
15:45:45 <kashyap> Next -- https://bugzilla.redhat.com/show_bug.cgi?id=1014547: Firewall rules can not be updated in a firewall policy after firewall policy creation
15:45:47 <larsks> 1008127 closed notabug
15:46:50 <kashyap> 1014547: Looks legitimate to me, but firewall experts can confirm
15:46:59 <larsks> kashyap: Should be an upstream bug though, right?
15:47:33 * kashyap runs $ bodhi -L openstack-neutron to see if there's a newer version in repositories
15:48:12 <kashyap> Yes: dist-6E-epel-testing-candidate  openstack-neutron-2014.1-0.2.b1.el6
15:48:21 <kashyap> Reporter tested with: openstack-neutron-2013.2-0.4.b3.el6
15:48:44 <kashyap> (But it may still be a bug)
15:48:51 <larsks> Isn't 2014.1 icehouse?
15:49:11 <kashyap> Yeah
15:49:18 <larsks> ...so not actually released as a package yet.
15:50:03 <kashyap> Ok, comment to report it upstream?
15:50:09 <larsks> Yeah.
15:50:29 <larsks> Or: do whatever it is we did with the previous upstream bug.
15:50:46 <kashyap> Yeah,
15:50:53 <kashyap> I'm using this verbiage: "Hi, please report this issue upstream, and link the respective bug as external tracker, and close this bug."
15:51:00 <larsks> Sounds good.
15:51:15 <larsks> Although note that the reporter is gone and will not see the comment.
15:51:32 <kashyap> Yeah, saw that
15:52:00 <kashyap> Bugs like these are sometimes closed with INSUFFICIENT_DATA
15:52:11 <kashyap> If reporter doesn't respond for a long time, etc
15:52:14 <larsks> Yeah, I was going to suggest that.
15:54:21 <kashyap> Done.
15:54:29 <larsks> https://bugzilla.redhat.com/show_bug.cgi?id=1014627 is also an upstream bug.  I'm going to reuse your verbage...
15:55:02 <larsks> Whoops, also the same reporter.
15:55:06 <kashyap> Sure.
15:56:32 <larsks> kashyap: So, in 1014547, to whom are you addressing your comment?  Since the reporter isn't going to see it...are you assuming rhos-maint will take care of it?
15:57:14 <kashyap> larsks, Was wondering the same, I thought let it wait for this triage cycle, and get back to it on the next cycle?
15:57:26 <larsks> kashyap: Okay.  I'll do the same on 1014627 then.
15:57:29 <kashyap> If you have other options I'm all ears
15:57:55 <larsks> Alhtough the bug should in that case be CLOSED UPSTREAM rather than CLOSED INSUFFICIENT_DATA.
15:58:09 <larsks> (Ie., the suggested end state in the comment)
15:58:26 <kashyap> Agreed.
15:58:42 <larsks> 1014627 marked needinfo:reporter
15:58:55 <kashyap> Cool.
15:59:16 * kashyap is flipping between too many bugs, getting a bit distracted
15:59:19 <larsks> Doing the same for 1015076.
15:59:23 <larsks> Do one at a time! :)
15:59:40 * kashyap slaps himself on the wrist to show discipline.
16:00:07 <larsks> And also 1015164 (both have the same reporter as the previous two)
16:00:30 <kashyap> Ya, noticed it
16:01:19 <larsks> 1015164 needinfo:reporter
16:01:33 <larsks> 1015076 needinfo:reporter
16:02:22 <larsks> Maybe a couple more than time for a break.
16:02:30 <kashyap> Yeah
16:02:36 <kashyap> It's 2 hours already
16:02:53 <larsks> I've got 1019487.  Grab one more yourself and we'll call it done :)
16:03:27 <kashyap> 1023673 is already assigned, /me moves to next
16:05:33 <larsks> 1019487 needinfo:reporter
16:06:00 <larsks> \o/
16:06:03 <kashyap> 1024763: /me already marked it as RFE, and it's LOW prio IMO
16:06:40 <kashyap> Ok, ending this meet in 2 seconds
16:06:43 <larsks> So that's...what, about 1/3 of the bugs?
16:06:44 <kashyap> 2. .
16:07:02 <kashyap> larsks, Yeah, I tried to paste them all here - https://etherpad.openstack.org/p/RDO-BugTriage
16:07:11 <kashyap> Maybe more than 1/3rd
16:07:16 <larsks> Figure we could close the meeting with a count :)
16:07:46 <larsks> So, 23 out of 61 bugs addressed it looks like.
16:07:46 <kashyap> 23
16:07:53 <larsks> Woo, go us.
16:07:54 <kashyap> #info  23 out of 61 bugs addressed
16:08:02 <kashyap> Thanks larsks and everyone else.
16:08:24 <kashyap> #idea We can have a rotating volunteers to keep notes/run the zodbot commands?
16:08:53 <larsks> Did we settle on once/month or twice/month for now?
16:09:32 <kashyap> Once a month is what mburned suggested
16:09:46 <kashyap> I think we could do twice a month.
16:10:06 <kashyap> larsks, You have a pref?
16:10:36 <larsks> I guess I don't have a strong preference one way or the other.
16:11:14 <larsks> I have to step away from the computer for a bit. Follow up on list re: scheduling?
16:11:21 <mburned> kashyap: maybe go twice/month
16:11:32 <mburned> and scale back if/when we get bugs under control
16:11:52 <kashyap> Ok, noted.
16:12:13 <kashyap> Thanks all!
16:12:23 <kashyap> #endmeeting