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