15:08:26 #startmeeting RDO packaging meeting (2015-04-29) 15:08:26 Meeting started Wed Apr 29 15:08:26 2015 UTC. The chair is apevec. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:08:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:08:33 #chair jruzicka aortega number80 rbowen 15:08:33 Current chairs: aortega apevec jruzicka number80 rbowen 15:08:39 #topic roll call 15:08:42 o/ 15:08:44 .oO( Present ) 15:08:46 o/ 15:08:50 o/ 15:09:22 o/ 15:09:26 apevec: o/ 15:10:18 #topic test day 15:10:29 * kashyap waves 15:10:34 so we have dates, May 5-6 next week 15:10:45 trello card tracking prep is https://trello.com/c/w1UkNChb/55-test-day-kilo-rc-ga 15:11:01 we'll have rdo-management too 15:11:27 and I should have properly signed RDO Kilo "core" repo by then 15:11:53 could we get doc few days ahead so we could help with rdo-management testing effectively ? 15:12:00 I've most CBS builds done, now checking dep updatets, repoclosure etc. 15:12:20 number80, I think rbowen got promised that 15:12:26 rbowen, do we have a link? 15:12:30 The RDO-manager docs are being actively worked on. hewbrocca is on that. 15:12:47 https://www.rdoproject.org/RDO_test_day_Kilo is the test day doc. I don't have a link to the rdo-manager docs yet, but it will be linked from that page soon. 15:12:52 rbowen, I think they also wanted subdomain under rdoproject.org 15:13:07 rbowen, jcoufal will probably ask you about it 15:13:11 Yes, I created docs.rdoproject.org which will have that content once there is some. 15:13:18 cool 15:13:26 Although, the name is kind of generic, so I'm not sure how well that works. 15:13:27 apevec: yup, already discussed 15:13:30 rbowen: thanks! 15:13:35 But we'll figure it out. :) 15:14:19 rbowen, right, site refactoring can part of site conversion to git 15:14:49 Yes. And that's scheduled for shortly after OpenStack Summit, when things are slightly quieter. 15:14:54 ack 15:15:07 back to test day prep: I propose to do quick big triage what was reported against RC2 snapshot 15:15:14 rbowen, did you mean https://www.rdoproject.org/Docs ? :) 15:15:22 very nice ;) 15:15:33 I've copied summaries to the etherpad 15:15:54 of what was reported on rdo-list 15:15:55 When I say "I created" I just mean I made a DNS record. It is pointing at the main site, so there's nothing different there than we've already had before. 15:16:35 #topic RC2 bug triage 15:16:37 #info "compute_nodes" in nova database appeared to be empty up on completion 15:16:56 ^ any Nova folks how can comment? 15:17:09 RC2 did pass CI so I'm not sure what happened 15:17:23 CI (packstack installation + tempest smoke testsuite) 15:17:26 apevec: Bug URL for that? 15:17:44 possibly ndipanov? ^ 15:17:48 kashyap, yeah, just noticed bz# is missing, it was only reported on rdo-list 15:17:53 lemme find thread 15:17:56 * kashyap looks 15:18:53 looks like compute doesn't get registered 15:19:03 mmagr: where did you write me about the rdo-management github? 15:19:08 I cannnot find your user 15:19:46 jcoufal, oh yes, sorry: paramite 15:19:54 apevec, there was some refactoring around that so not impossible that it got borked 15:20:00 got bz number? 15:20:29 mmagr: try now 15:20:39 kashyap, ndipanov - nope, all I have is https://www.redhat.com/archives/rdo-list/2015-April/msg00248.html 15:20:58 kashyap, can you reply there asking for details/bz ? 15:21:00 jcoufal, nope, still not there: https://github.com/orgs/rdo-management/people 15:21:10 apevec: Will do. 15:21:33 thanks 15:21:36 next: 15:21:39 #info Horizon permission denied error, old bug: https://bugzilla.redhat.com/show_bug.cgi?id=1150678 => mrunge cannot reproduce 15:21:41 ndipanov: I'll add you to CC to that bug. So you can take a look when you can. 15:21:49 mmagr: try your e-mail 15:21:54 mrunge, ^ still no news? 15:21:56 mmagr: you might need to accept the invitation 15:21:58 apevec, doesn't look good tbh 15:22:06 ah right 15:22:16 and might actually be a legit issue 15:22:28 ndipanov, this was rc2 - was there related fixes in rc3 ? 15:22:30 the right person to look at it would be sylvain 15:22:37 but he's not on this channel 15:22:54 mmagr: you are there 15:22:54 ndipanov, ok, we'll follow up in bz 15:23:08 jruzicka: btw, any progress with the backport? 15:23:25 apevec, bauzas is here 15:23:28 jcoufal, ok great, I'm there thanks, can you please create a team called 'puppet' for me with admin rights so I can create repos there? 15:23:34 mind re-pasting the bug details 15:23:38 ndipanov: apevec: aloha 15:24:07 bauzas, hi, sorry we don't have much details, it was only report on rdo-list https://www.redhat.com/archives/rdo-list/2015-April/msg00248.html 15:24:21 mmagr: there are puppeteers 15:24:23 can you be part of them? 15:24:38 bauzas, kashyap will followup and ask for details in BZ 15:24:40 apevec: I'm missing contrext 15:24:48 jcoufal, sure if members will be able to create repos :) 15:25:07 bauzas, with Kilo RC2, "compute_nodes" in nova database appeared to be empty up on completion 15:25:12 see that post 15:25:17 that's all we have ATM 15:25:20 apevec: yeah that's what I'm reading 15:25:29 mmagr: yup 15:25:41 mmagr: you should ask EmilienM though 15:25:48 he is lead of that group 15:26:07 bauzas, seems like your disconeect the service from compute node could have caused this 15:26:13 jcoufal, ack 15:26:28 bauzas, not sure details about their setup, we also know that RC2 passed CI so at least in some cases it does work... 15:26:36 ndipanov: yeah I'm just wondering why it breaks, because we fixed the bugs 15:26:56 well that and paul's hack 15:27:06 er refactoring 15:27:09 looking at the RT code 15:27:21 I'll refresh snapshot with RC3 once I get trunk.rdo unblocked 15:27:24 if we can't find the service based on the compute node lookup 15:27:29 derekh, ^ BTW no ssh again... 15:27:31 we bail and never create the record 15:27:37 how did that slip in :/ 15:28:24 apevec: ack, will ask dprince to see if he can find anything info on the console 15:28:30 ndipanov, so RC3 won't help? 15:28:52 ndipanov: that just means the service is not found when looking at the database by the host name 15:29:03 apevec: hmm, he isn't around, mailing 15:29:09 apevec, actually it might not be a bug for everyone 15:29:29 ndipanov: but self.host is given by the hypervisor 15:29:35 ndipanov, definitely the cases, as I said it work in CI setup 15:29:58 ndipanov: when the compute manager is starting 15:29:58 yeah - so taht guy gets a different hostname from libvirt and python 15:30:07 ndipanov: that's my thoughtds 15:30:07 man, much bad grammar 15:30:23 there was a bug around this before 15:30:24 ndipanov: but that's strange 15:30:39 ndipanov: because 'compute1' is the name 15:31:05 ndipanov: so I'm looking into objects.Service.get_by_compute_host 15:31:13 bauzas, that's the name Service gets 15:31:28 ndipanov, bauzas, ok, let's take it to BZ which kashyap will create, need to move on to other reported bugs 15:31:40 #info openstack-nova-novncproxy service fails to start: https://bugzilla.redhat.com/show_bug.cgi?id=1200701 => RDO Juno updated, Nova spec needs versioned dep 15:32:03 ndipanov: there is no reason that the DB shouldn't find the entry 15:32:06 apevec: I asked Boris to file one on the list, since he seems to have the env. 15:32:14 kashyap, thanks 15:32:26 bauzas, CONF.host is what it gets defaulted to 15:32:40 so if compute service gets something else - it can happen 15:33:14 ndipanov: mmm, it explicitely checks self.host, and the log says it's "compute1" 15:33:15 so websockify is updated in hte repo, we just need versioned dep in openstack-nova to ensure upgrade 15:33:30 last one: 15:33:33 # neutron-lbaas-agent fails to start 15:33:38 #info neutron-lbaas-agent fails to start 15:33:40 jruzicka: somewhere around? 15:33:48 #info fixed in Neutron RC3 15:34:11 that's all I've found reported on the list, was there anything else I missed? 15:34:15 itzikb, ^ 15:34:43 jcoufal, yeah but now is meeting. Unless it's relating to current topic, please wait till it's over. 15:34:53 jruzicka: ah, sorry 15:35:29 apevec: sorry was in a meeting 15:35:30 I think we're done with bug triage here, to be continued in BZ or later on irc 15:35:56 itzikb, np, just asking if there was more issues reported against RC2 after your post? 15:36:09 apevec: I need to send and update 15:36:14 itzikb, I summarized rdo-list reports inhttps://etherpad.openstack.org/p/RDO-Packaging 15:36:18 bauzas, yeah 15:36:23 seems like it should work 15:36:29 itzikb, ok, reply on your post 15:36:39 ndipanov: agreed, because the object is calling the conductor which checks DB 15:36:42 let's move to the next topic 15:36:42 apevec: ok will do 15:36:50 #topic distrepos @ rdoinfo 15:36:55 and the self.host is passed in my the service 15:37:00 so it's the same value 15:37:04 ndipanov: because RT runs on the compute side 15:37:07 jruzicka, ^ floor is yours, please explain yourself :) 15:37:17 ndipanov: but it passes the correct value 15:37:29 #link https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml#L29 15:38:01 jruzicka, what's the question about distrepos? 15:38:11 ndipanov: so the only way that is can't work is that db.sqla.service_get_by_compute_host() doesn't get a row 15:39:09 jruzicka, there? 15:40:40 oh, back 15:40:41 sorry 15:41:16 jruzicka, current info in rdo.yml looks good to me, is there some concern? 15:41:25 yeah so I need us to fill the distrepos 15:41:28 in RDO info 15:41:42 that defines what we assume is available in supported distros 15:41:50 and what will be tested in CI eventually 15:41:56 ah for Kilo? 15:42:09 that is all repos available on a system where ($dist,$release) RDO is installed 15:42:21 for all the the combinations :) 15:42:30 I figured out Fedora 20 hopefully 15:42:39 but then is fedore.next and I got confused 15:42:47 respectively lazy with centos :) 15:43:24 jruzicka, is it still the issue that you cannot use mirror url? 15:43:30 Just sayting that needs to be done in order for querying requirements.txt 15:43:56 dl.fedoraproject.org is probably not the fastest mirror for everybody 15:43:56 issue is I need to identify sets of repos for each supported (dist,release) 15:44:05 And fill rdoinfo with that information 15:44:05 apevec: I sent an email to the list 15:44:09 itzikb, thanks 15:44:18 apevec, and that problem with mirrorlist not working, yes 15:44:20 :-/ 15:44:51 mrunge: http://v3.sk/~social/evince/ 15:45:06 mrunge: no promises except it should not crash right away 15:45:25 jruzicka, ok, I'll take action to update distrepos 15:45:40 #action apevec to update distrepos in rdoinfo 15:45:55 best way I'm aware of would be to install the distros... and I don't have time for the new VM setup on lab machine now 15:45:56 jruzicka, where is limitation w/ mirrorlist is coming from? 15:46:02 I bet you can do it in like 1/10 of time 15:46:13 repoquery doesn't support it 15:46:16 jruzicka, no, it should be possible to query yum repos 15:46:22 dnf repoqeuery as well 15:46:30 yes, but explicit repos 15:46:31 hm, repoquery - shame on you 15:46:41 doesn't support the metalink 15:46:48 old and new one 15:47:02 I didn't figure that one out got closed in the box :) 15:47:23 jruzicka, but that's strange, isn't repoquery using yum backend? 15:47:33 and mirrors do work with yum... 15:47:38 or dnf 15:47:46 that's what I thought 15:48:38 well, if it can do it, I'm not worthy enough to figure out 15:48:39 apevec, jruzicka: dnf repoquery uses the same code as dnf, repoquery and yum share some code but not everything 15:49:11 yeah, but I didn't find a correct string that would make either of them do what I want. 15:49:33 ancients strings of power, forgotten in the sands of code 15:49:37 maybe they're just a legent 15:49:40 *legend 15:49:51 anyway, that's it for distrepos 15:49:55 we can look at it later 15:50:01 number80, jruzicka - ok, we can look at that later 15:50:08 moving on 15:50:14 #info rdopkg reqcheck available to help with requirements.txt management in rdopkg-0.27 15:50:23 jruzicka, ^ thanks! 15:50:28 I need to try it out 15:50:32 please do 15:50:42 re. borken with new milestone tags (ugh), use #patches_base=$TAG if needed 15:50:42 I found it uberusful even 15:50:48 with the dubmest possible reqs matching 15:50:54 (string comparison, huehuehue) 15:50:57 is that rpm-master merges I did, like http://pkgs.fedoraproject.org/cgit/openstack-heat.git/diff/openstack-heat.spec?id=b4f6dc65ec5bf62aa369e7f5af1666a2ea8a7e7b 15:50:58 ? 15:51:04 +Release: 0.1%{?milestone}%{?dist} 15:51:12 apevec, should work OK with that 15:51:13 why is that a problem? 15:51:18 no that's ok 15:51:26 problem is Version: not being string 15:51:28 but macro 15:51:29 which one is not? 15:51:40 rdopkg needs to figure out the git tag 15:51:40 ah, we're not going to do that 15:51:42 or all is lost 15:51:53 only in Delorean we'll have Version: XXX 15:51:58 it goes #patches_base (not used anymore) > Version: 15:51:59 because it's over-written 15:52:05 it detects XXX 15:52:14 and then uses ../$PROJECT/requirements.txt 15:52:18 so you can use it in delorean spec 15:52:22 also Delorean spec should not have any patches 15:52:29 as long as you add upstream repo 15:52:53 it must be "upstream" git remote ? 15:53:02 preferably 15:53:13 there's rdopkg RFE to set all that up automagically, right? 15:53:16 yes 15:53:24 many RFEs lately as people started using it ;) 15:53:40 it's gonna only get better with time ;) 15:53:47 anyway 15:53:54 if you hit incorrect requirement 15:53:58 jruzicka, ok, so openstack-keystone master is problematic, I'll fix it 15:54:17 I.E. something that didn't got translated wrong reqs.txt to package name 15:54:43 just fix rdopkg/actionmods/pymod2pkg.py or let me know 15:54:50 yep, send a patch! 15:54:58 apevec, so is neutron I think... I can also do this 15:55:08 if Version doesn't correspond to a git tag 15:55:17 try parse %upstream_version fro mspec 15:55:19 jruzicka, ok, I messed up with neutron too, will look at it 15:55:20 *from .spec 15:55:33 I can do that, but it seems like unnecessary automagic 15:55:49 well, you tell me, it can be done 15:55:56 yeah, too much automagic is not good 15:56:04 ok, we have only few minutes left, let's move on 15:56:07 jruzicka: rpm -P (rpm > 4.9) will expand the macro (could be useful) 15:56:08 also: grep Version *.spec 15:56:14 will actually give you version 15:56:17 the little things 15:56:24 #topic Packaging tests packages for openstack-components 15:56:25 like not needing to use librpm 15:57:01 -tests subpackages will be our next goal, for L-cycle 15:57:11 apevec, can we package test packages which are under txt-requirements.txt ? 15:57:14 it needs some thoughts how to do it properly, 15:57:25 project now include both unit and functional tests 15:57:46 chandankumar, sure, that's the requisite, to have all test deps available in buildroot 15:57:52 +1 15:57:53 so we run _unit_ tests in %check 15:57:55 nice 15:58:08 apevec, i will list all the test packages and package it. 15:58:11 b/c I don't think buildroot is the right env to run functional tests 15:58:23 chandankumar, excellent here comes your action 15:58:26 apevec: exactely 15:58:39 #action chandankumar will list all the test packages and package it 15:58:46 Thanks :) 15:58:49 chandankumar, please post the list to rdo-list when you have it 15:58:49 looking forward to the soothing feeling of passed tests 15:59:06 apevec, sure :) 15:59:30 jruzicka, well could actually be misleading :) http://pythontesting.net/strategy/why-most-unit-testing-is-waste/ 15:59:41 but let's not go there now 16:00:06 misleading but soothing nonetheless :-p 16:00:14 next 16:00:21 #info selinux enforcing jobs enabled for kilo 16:00:27 brace for AVCs! 16:00:48 plan is to collect them all and update openstack-selinux for Kilo 16:01:16 another CI update: 16:01:20 #info trystack is down atm w/ floating ip issues, public ci down 16:01:25 weshay, aortega ^ any hope? 16:01:52 ggilles and kosh are looking at it 16:02:01 ok, thanks for the update 16:02:21 Graeme made pretty good progress yesterday, and wfoster and kosh have taken over 16:02:30 #topic juno el6 in CBS 16:02:35 #info Enabling cloud6-openstack-juno-candidate and cloud6-openstack-common-candidate CBS repositories on CentOS 6 (No EPEL) you will be able to "yum install openstrack-nova openstack-ceilometer-*". 16:02:52 :) 16:02:54 Now how can we handle CI for Juno el6 ? (/me didn't follow any CI discussion so is clueless / Yesterday the team upgraded 3200 production nodes from ice6 -> juno6 so I have ongoing "validation tests" :) 16:02:55 excellent 16:03:23 alphacc, we can't beat that with our CI :) 16:03:47 alphacc, so you're upgraded only computes to EL6 Juno? 16:03:50 apevec: I wish I had found some issues in advances I could have still kept some hair. 16:03:58 alphacc, what were issues? 16:04:12 apevec: mainly python-* updates 16:04:13 alphacc, and which setup should we test in CI? 16:04:26 EL6 compute nodes + controller EL7 ? 16:04:32 weshay, ^ could we do that? 16:04:35 apevec: yes 16:04:36 weshay, it's RDO Juno 16:05:01 yes.. that is possible 16:05:17 rdo-juno w/ el6 compute and el7 for controllers 16:05:17 weshay, do we have any such job as an example? 16:05:20 no 16:06:01 weshay, do we have enough info/pointers for alphacc to add such job? 16:06:29 weshay, also do we have khaleesi-settings open up for external contributions? 16:07:24 anyway, ping me when I can help. 16:07:25 atm.. our up stream / downstream story for khaleesi-settings sucks.. 16:07:46 it would be available on any slave we use, but the github account lags 16:08:10 alphacc, number80 - BTW https://trello.com/c/L0X5bU5s/25-el6-juno-packages has Juno/EL6 neutron in the checklist 16:08:17 the change would I think only be for the settings/installer/packstack/topology 16:08:25 the os is mapped to each node 16:08:30 alphacc, are you actually interested in that? b/c EL6 and neutron might not be best match 16:08:44 alphacc, you're still on nova-net right? 16:08:45 apevec: yes neutron is coming tomorrow ;) 16:08:59 apevec, btw.. we have a new platform ci guy and he'll be taking some of this on hopefully 16:09:00 alphacc, so you migrated? 16:09:05 apevec: yes modified nova-net 16:09:12 apevec: no 16:09:27 packages are coming we are still putting a plan together 16:09:40 ok, so who actually would want EL6 Neuron? 16:10:17 alphacc, number80 - could we can say EL6 Juno is "done" with Nova + Ceilo + clients? 16:10:26 apevec: We likely need it for our upgrade path nova-net -> neutron el6/el7 16:11:35 apevec: I'll publish some neutron stuff anf let see if there is some interest from the community; I should send soemthing to the list 16:12:19 alphacc, ack 16:13:03 #action alphacc to post about EL6 neutron status on rdo-list, to gauge interest 16:13:17 number80, do you have anything for EL6 ? 16:13:46 ok, we're already over time 16:13:49 apevec: as for myself, we're providing an upgrade path 16:13:51 #topic open floor 16:13:59 alphacc: Would also be useful to have a doc for the RDO docs wiki, but perhaps that'll come out of that thread. 16:14:29 rbowen, yeah, let's not put too much new stuff into wiki before migration 16:14:54 rbowen: sure when we have the final repos I'll add it 16:15:03 The migration process is all scripted, and converts all content. Takes about 5 minutes, last time we tested. But, sure, before or after is fine. 16:15:43 rbowen, best part IMHO is that content updates will have proper history and reviews 16:15:48 +1 16:15:54 Very true 16:16:04 I'll make a list of people to bug post-update. :-) 16:16:12 rbowen, btw would we prefer to use gerrithub or github PRs for updates? 16:16:41 ok thanks all, I need to run. 16:16:43 not sure what folks writing docs prefer 16:16:46 alphacc, thanks you 16:16:46 I'm not sure. We should perhaps discuss that on the list. I'll get more details from Garrett on how this all works. 16:16:57 ok 16:17:17 So far, the oVirt guys have said that they don't want to use Gerrit for it, but that's just one opinion among many. 16:17:32 yeah 16:17:38 ok, if no other topics, I'll end meeting in 3 16:17:45 2 16:18:02 1 - thanks everyone! 16:18:06 #endmeeting