08:03:34 #startmeeting tripleo 08:03:35 Meeting started Wed Dec 10 08:03:34 2014 UTC and is due to finish in 60 minutes. The chair is tchaypo. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:03:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:03:38 The meeting name has been set to 'tripleo' 08:03:47 #topic agenda 08:03:47 * bugs 08:03:47 * reviews 08:03:47 * Projects needing releases 08:03:47 * CD Cloud status 08:03:47 * CI 08:03:47 * Tuskar 08:03:48 o/ 08:03:48 * Specs 08:03:48 * open discussion 08:03:49 Remember that anyone can use the link and info commands, not just the moderator - if you have something worth noting in the meeting minutes feel free to tag it 08:03:49 #topic bugs 08:04:20 * marios still falling behind in bug time 08:04:24 greetings harshada_kakad! 08:04:31 #topic bugs 08:04:56 I wanted to raise https://bugs.launchpad.net/tripleo/+bug/1188067 08:04:57 Launchpad bug 1188067 in tripleo "* listening services available on all addresses" [High,In progress] 08:05:19 I’ve suggested closing it; would like to get some feedback. No particular need for that to happen during the meeting though. 08:05:36 #link https://bugs.launchpad.net/tripleo/ 08:05:36 #link https://bugs.launchpad.net/diskimage-builder/ 08:05:36 #link https://bugs.launchpad.net/os-refresh-config 08:05:36 #link https://bugs.launchpad.net/os-apply-config 08:05:36 #link https://bugs.launchpad.net/os-collect-config 08:05:37 #link https://bugs.launchpad.net/os-cloud-config 08:05:37 #link https://bugs.launchpad.net/os-net-config 08:05:38 #link https://bugs.launchpad.net/tuskar 08:05:38 #link https://bugs.launchpad.net/python-tuskarclient 08:05:40 tchaypo: lol "that's all nice and good" 08:06:15 I’ve noticed the untriaged bot is quite chatty these days, but I keep failing to make enough time to deal with the things it’s talking about 08:06:18 tchaypo: didn't realise there was a review out, will have a look 08:07:27 https://bugs.launchpad.net/tripleo/ doesn’t show me any unassigned criticals though 08:07:37 We also said we were going to have a bugsquash day but I think we all forgot? 08:07:39 sorry, it does - https://bugs.launchpad.net/tripleo/+bug/1229849 08:07:40 Launchpad bug 1229849 in heat "In future native Heat templates, we should leave the image users alone on servers" [Wishlist,In progress] 08:08:59 We're actually expecting to remove instance_user from heat and just let the image defaults be used instead 08:09:09 greghaynes: could you send an email out and suggest a day for that? 08:09:39 reading https://bugs.launchpad.net/tripleo/+bug/1229849 i’m not entirely clear what we’d have to do to support this 08:09:40 Launchpad bug 1229849 in heat "In future native Heat templates, we should leave the image users alone on servers" [Wishlist,In progress] 08:09:50 Sure thing. Last week we suggested tuesday (which just ended). Ill suggest wed of next week so we can remind everyone in the meeting day before :0 08:10:05 it sounds like maybe we need to have Yet Another Map that maps distro -> username? 08:10:14 or a way to provide a map of instance -> username? 08:13:09 I’ll grab the bug for now, just so it’s assigned, and I’ll follow up in-channel to figure out what needs to be done 08:14:03 Based on Clint's comment, are we saying you'd prefer we didn't remove instance_user, but just flipped the default to not creating any user? 08:14:48 I can sync up with shadower about it - IIRC he proposed the instance_user deprecation in heat 08:15:11 I’m not sure I understand clint’s comment 08:16:03 oh wait -the “per-OS users” are coming from heat? 08:16:09 I think he's saying if we remove instance_user from heat, it will break tripleo 08:16:14 tchaypo: Yes 08:16:23 https://github.com/openstack/heat/blob/master/heat/common/config.py#L87 08:16:28 I think I know how we can work with that then 08:16:47 shadower proposed a deprecation/removal for Juno, but in the end it didn't actually get removed 08:17:05 but to clarify - in the phrase “per-OS user” is that “per operating system” or “per openstack”? 08:17:16 The users can just be created in the template instead of automagically by heat 08:17:36 tchaypo: It's a default user we create on every box deployed via heat (unless you use user_data_format=RAW) 08:18:06 Will we be able to query heat to find out what the username is? 08:18:27 tchaypo: Not at the moment, unless the user creation moves into the template 08:18:44 it sounds like heat must have the distro->username mapping somewhere; I think it would be nice if we didn’t have to recreate that 08:18:59 let 08:19:11 tchaypo: No, we just inject some cloud-init data which creates a user on every distro 08:19:26 perhaps we should follow up on the ML about this? 08:19:36 let’s talk about this after the meeting - I’m still trying to wrap my head around it and it doesn’t seem like a good use of meeting time 08:19:38 yes :) 08:19:45 any other bugs we want to talk about? 08:19:45 +1 08:21:40 #action tchaypo to follow up with shardy/shadower about how to handle instance_user deprecation 08:21:57 #topic reviews 08:22:03 #info There's a new dashboard linked from https://wiki.openstack.org/wiki/TripleO#Review_team - look for "TripleO Inbox Dashboard" 08:22:03 #link http://russellbryant.net/openstack-stats/tripleo-openreviews.html 08:22:03 #link http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt 08:22:03 #link http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt 08:23:32 We’re back up to 2 reviewers above the 3 reviews/day threshold; we’re at 6d3h42m/14d11h29m for the 2nd/3rd quartiles of "since the last revision without -1 or -2" 08:23:33 Queue growth in the last 30 days: 56 (1.9/day) 08:24:51 I don’t want to focus on the numbers, but it seems fairly clear the backlog is growing. It’s less clear whether that’s a problem; I know that I personally have a bunch of older reviews that are low-priority things that haven’t been updated because I’ve been focusing elsewhere 08:25:47 Five oldest reviews: 08:25:50 33 days, 14 hours, 48 minutes https://review.openstack.org/133094 (Specify a signal transport for the SwiftStorageDeployment) 08:25:50 28 days, 15 hours, 2 minutes https://review.openstack.org/133755 (Tuskar role components spec) 08:25:50 27 days, 14 hours, 58 minutes https://review.openstack.org/133554 (Add Overview subsection to Proposed Change section) 08:25:50 22 days, 16 hours, 42 minutes https://review.openstack.org/127988 (Add Neutron DVR configuration variables) 08:25:50 21 days, 16 hours, 15 minutes https://review.openstack.org/101237 (Introduce support for Cinder HA via Ceph) 08:27:27 Does anyone want to volunteer to shepherd any of those? 08:27:50 https://review.openstack.org/#/c/133094 has several +1s but hasn’t passed tests 08:28:05 tchaypo: neutron one is almost landed, will ping jan about that 08:28:45 https://review.openstack.org/#/c/133755/ is a spec that’s had no review in almost a month of being up 08:29:00 it depends on 133554.. 08:29:45 It's not clear to me if that will work on update until bug #1389178 is fixed.. 08:29:49 Launchpad bug 1389178 in heat "heat stack-update failure when scaling resource group due to deficient signal handling in o-r-c scripts" [High,Fix committed] https://launchpad.net/bugs/1389178 08:29:58 I've been meaning to look into that but not yet had time 08:30:06 but https://review.openstack.org/#/c/133554/ seems as though it’s no longer necessary, so 133755 should be able to be made un-dependant 08:30:08 I thought 101237 required other bits as well, like ceph 08:30:27 I’ll update 133755 to break the dependency 08:30:45 shardy: could you comment on it to say you don’t think it will work? 08:31:19 Because o-r-c only sends one deployment signal per instance on update, not one per deployment resource 08:31:45 which is why you have NO_SIGNAL everywhere other than the AllNodesDeployments, AFAICT 08:31:49 StevenK: yes, you seem to be right about 101237. I’ll talk to gfidente today to ask him to either mark that as WIP or see if we can get an update 08:32:43 Based on analysis by stevebaker in comment #14, we have fixes required to 99-refresh-completed 08:32:59 wheee 08:32:59 I'll try to take a look today or tomorrow 08:33:11 Shouldnt be hard to just do our same curl -XPOST thing for more than one resource 08:33:17 ah, yes 08:33:23 Okay, so in order to progress 133094 we need to look at the comments on bug #1389178 and fix those issues? 08:33:24 Launchpad bug 1389178 in heat "heat stack-update failure when scaling resource group due to deficient signal handling in o-r-c scripts" [High,Fix committed] https://launchpad.net/bugs/1389178 08:33:50 tchaypo: I'll take that bug, unless anyone else wants it, seeing as I've already fixed the heat related aspects 08:34:25 thanks shardy 08:35:54 so shady is working on bug #1389178 to progress review #133094; I’m talking to gfidente about what we can do to progress #101237 (or marking it as WIP if it can’t be acted on right now), I’ll chase #133554 as I think it can be abandoned and that should mean #133755 can be unbound from #133554… which just means it needs people to review it 08:35:57 Launchpad bug 1389178 in heat "heat stack-update failure when scaling resource group due to deficient signal handling in o-r-c scripts" [High,Fix committed] https://launchpad.net/bugs/1389178 08:37:06 #topic Projects needing releases 08:37:18 summary: some of them do. Do we have a volunteer? 08:37:30 StevenK: did you go through this yet? 08:37:46 He did 08:37:49 I can release this week 08:38:03 Sounds good 08:38:09 I have a couple dib things I want out :) 08:38:21 #action greghaynes to handle this week’s releases 08:38:29 #topic CI/CD 08:38:46 in line with what I’ve suggested on the list, I’m going to ignore these for now and work with derekh to get an email summary sent out 08:39:01 #topic tuskar 08:39:21 Suggests from list and other discussion are that we’re not sure why this topic even exists; unless anyone has anything to raise I’m moving right along 08:39:54 #topic specs 08:40:06 We already mentioned that https://review.openstack.org/#/c/133755/ has had no reviews in almost a month. 08:41:03 I’m going to be chasing that one; unless anyone has anything else they feel needs to be raised here rather than in channel or on the list I’ll move on 08:41:19 #topic open discussion 08:41:21 tchaypo: wrt meeting topics, based on current comments on list, except for reviews, bugs, releases (unless separate process/team put in place), everything else could become on-demand for the agenda 08:41:28 I need some help in launching instance in Ironic. I have launched instance using cirros and ubuntu image. I need to launch instance using centos and rhel image. As we need to create ramdisk and kernel image using diskimage-builder to launch any instance. I am facing problems in creating ramdisk and kernel image for centos and rhel. 08:41:56 has anyboby tested diskimage-builder with centos or rhel ? 08:42:03 marios: yeah, that’s what my understanding is too 08:42:16 harshada_kakad: half our team is employed by redhat, they’ve tested it quite a bit :) 08:42:31 sudo bin/ramdisk-image-create -a amd64 centos7 deploy-ironic -o /tmp/deploy-ramdisk-centos7 08:42:59 when i run this command i get errors as No package busybox available 08:43:03 I think this is probably better discussed in #tripleo rather than here - more people around who have probably used it 08:43:03 harshada_kakad: try #openstack-ironic 08:43:31 harshada_kakad: but may need a couple hours for more people to be around 08:43:33 What platform are you building on? I know that there are problems trying to build RHEL/Centos images on an ubuntu host, but I don’t know specifics 08:44:01 i m doing tht on ubuntu host only .. 08:44:20 so do u mean to say i should do this on cent/rhel host 08:44:20 ? 08:44:33 from what I’ve heard, that’s always going to fail. I believe you’ll need to get a CentOS system and do it from there 08:44:46 ohh ok .. 08:45:08 so same is for rhel as well ... 08:45:24 I don’t understand what the problem is though - so it may be unrelated to what you’re seeing, or maybe it’s been solved already. I just know that I’ve heard that building RHEL/Centos images has to be done on a centos (or RHEL) system 08:45:58 In a few hours once more people are around in #tripleo or #openstack-ironic, someone who actually knows what they’re talking about can probably give you a more useful answer :) 08:46:15 harshada_kakad: I think you need to use dracut-ramdisk for RAMDISK_ELEMENT 08:46:29 ok i was not knowing of that .. that it sholud be done on the same platform .. 08:46:56 yesp i have used it but on ubuntu platform and it also fails with on busybox ... 08:47:02 but we're pretty OT for this meeting now, as others have said, #openstack-ironic... 08:47:27 * marios intense stare tchaypo 08:48:09 * tchaypo withers 08:48:34 IF there’s nothing else it sounds like we can wrap up early 08:48:55 (although I’d point out that the current topic is “open discussion” so i don’t see how anything can be off-topic ;) 08:49:36 #endmeeting