14:00:11 #startmeeting tripleo 14:00:17 Meeting started Tue May 3 14:00:11 2016 UTC and is due to finish in 60 minutes. The chair is shardy. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:21 The meeting name has been set to 'tripleo' 14:00:28 #topic rollcall 14:00:30 o/ 14:00:33 Hi all, who's around? 14:00:36 hey 14:00:36 o/ 14:00:39 hi 14:00:41 o/ 14:00:44 hello \o 14:00:56 o/ 14:01:09 hi 14:01:14 o/ 14:01:44 o/ 14:01:46 hi 14:02:14 Ok, lets get started :) 14:02:27 #topic agenda 14:02:40 #link https://wiki.openstack.org/wiki/Meetings/TripleO 14:02:51 Anyone have any one-off items to add? 14:03:04 I added one re summit sessions, and trown has one re puppet packages 14:03:19 shardy: I think sshnaidm added one about tempest as well 14:03:25 shardy: can you just go over the status of the subteams? - I don't recall a final decision 14:03:28 * shardy refreshes ;) 14:03:28 shardy, trown yes, right 14:04:09 jrist: I don't think there has been one, other than to say it's fine to organize temporary teams around features 14:04:09 * beagles kicks IRC client 14:04:14 o/ 14:04:18 shardy: sounds good. thanks 14:04:20 such as EmilienM has started for the composable roles work 14:04:26 (see openstack-dev thread) 14:04:51 #topic one off agenda items 14:05:08 #info (trown)Puppet modules from source or packages? (packages are now individual modules and work like every other dlrn package) 14:05:17 #link https://trunk.rdoproject.org/centos7-master/report.html 14:05:32 trown: so we can switch over from the source elements now? 14:05:36 we have puppet modules packaged individually now in our master trunk repo in RDO 14:05:38 trown: does that mean we can default to packages now? 14:05:48 shardy: slagle that is my question :) 14:05:50 or that's what you're asking :) 14:05:52 trown: will this only be for master/Newton ? 14:05:54 heh, yea, just realized that 14:06:05 shardy: ya and moving forward 14:06:12 +1 for switching, should save us some time building stuff in CI 14:06:19 i'd prefer to default to packages if we can, so it's consistent 14:06:23 we do still have the o-p-m issue for stable branches tho 14:06:32 I have a patch up for tripleo-quickstart to use puppet from source, but it is a bit obsolete by this 14:06:43 I proposed one fix for that, but it needs revisiting as there was a preference for a different approach 14:07:12 trown: where are the package sources? 14:07:14 trown: https://github.com/openstack-packages/ 14:08:17 shardy: it mightn't save us time building puppet modules, as we don't currently build any but +1 for consistency 14:08:22 dprince: hmm good question... everything in RDO moved to review.rdoproject.org and https://github.com/rdo-packages/ but I dont see puppet there 14:08:46 derekh: Yeah I meant all the dib stuff we do around modules 14:08:54 trown: before moving I would like to know where we push fixes, etc. given it would block us upstream potentially 14:08:57 shardy: ack 14:09:16 trown: also, while I like the consistency I would sort of like the puppet modules to pave the way for us here 14:09:32 trown: in other words... do we plan on doing the same for the puppet-* CI jobs as well? 14:09:33 yea, before we switch, we definitely want to prove we're testing proposed patches to the puppet modules 14:09:43 (building the test package via dlrn, etc) 14:10:04 Ok, should we follow up on this with some ML discussion, it sounds like we need to break it down into a few steps 14:10:07 ? 14:10:10 +1 14:10:16 shardy: yep, thanks 14:10:29 just wanted to get some feedback on if the direction made sense 14:10:44 or if there was some hard "we must use puppet from source" 14:10:55 #info direction to use puppet module packages agreed, more discussion re how to switch on ML pending 14:11:17 trown: the main hard requirement is to keep Depends-On: $puppet-module-change working 14:11:38 most of that should just work, but there's going to be some hacking on tripleo.sh at least 14:11:40 shardy: ya, and if we can build with dlrn that should be fine 14:11:58 #info (shardy)Summit session retrospective 14:12:13 So, this item was just a request for feedback on how folks thought the sessions went 14:12:21 in particular the number and type of sessions 14:12:31 (to help when we're asked what we want next summit) 14:13:10 Do folks feel we had about the right number of sessions this time, or too much/little? 14:13:33 i think it was about right imo 14:13:34 I felt it was about right myself - some projects had a lot more, but we covered most of the major topics 14:13:36 shardy: I was happy with it. we could probably do with one more session though 14:13:48 our fishbwols and working sessions felt like the same format though 14:14:06 slagle: fishbowls get you a bigger room though :) 14:14:07 so perhaps making our working sessions more about "doing work" next time 14:14:16 (if we find that valuable) 14:14:19 Yeah, I thought the same thing - all of them were open discussion, which is good, but I'm not sure the fishbowls really encouraged participation 14:14:34 next time I'll give you sessions from puppet, we did not used them all 14:14:58 + for more work sessions 14:15:19 +1 for more work sessions, yes 14:15:26 i guess our fishbowls felt kind of presentation-y and our work sessions were more like the traditional fishbowl 14:15:32 #info possbly more work sessions next summit, and consider a more granular agenda to enable "doing work" vs open discussion 14:15:35 I think it'd be nice for fishbowls to come up with actual questions in the etherpad 14:15:38 so however we address that :) 14:15:45 to which we try to find an answer before time runs out 14:15:53 slagle: I felt the same, but it was mostly due to the size of the rooms vs the content I think? 14:16:05 I wouldn't be opposed to tripleo getting it own room Tuesday/Wednesday to do some side work sessions while we are all in the same place 14:16:20 shardy: could be yea 14:16:29 #info investigate dedicated space for pre-meetup meetup 14:16:38 o/ 14:16:48 Ok, that's all good feedback, thanks - anything else before we move on? 14:17:11 shardy, specific questions in the pads, not topic too generic 14:17:24 or we end up with more confusion and not many action items 14:17:41 I noticed you were indeed trying to sum up the action items yourself in multiple occasions 14:17:43 #info attempt to get more focussed questions ahead of sessions, and clear topic definition 14:18:26 gfidente: Yeah, I was happy to do that though, assuming folks found it useful 14:18:40 Ok sshnaidm , you're up next: 14:18:45 #info (sshnaidm) tempest passed https://review.openstack.org/#/c/295844/ ... is tripleo-ci where the py code to generate tripleo.conf belongs to? 14:18:58 shardy, yes, thanks 14:19:35 My position is let's start from Ci to see hot it goes, then let's think how to do it in tripleo. What is good for CI is not always good for customer/developer, maybe we'll use completely different tools to configure tempest. So let's keep it in CI repo for now 14:19:47 gfidente, ? 14:19:51 So, the issue here is that there's not one common way to configure tempest, right? 14:19:59 shardy, yes 14:20:01 yeah and we seem to want tripleoclient to do that 14:20:13 because it already does dump some stuff, but that's clearly not enough 14:20:20 Can anyone explain why there isn't e.g puppet support for it? 14:20:33 so my point is that we *could* move that code in the tripleoclient 14:20:40 I personally would prefer we didn't hack all this into tripleoclient 14:20:41 (or even tripleo-common) 14:20:46 shardy: that would imply we wanted it installed on the undercloud (always) 14:20:48 yeah me as well 14:20:53 shardy: upstream puppet CI uses puppet-tempest. 14:20:56 shardy: I don't think of tempest as an undercloud only tool 14:20:58 dprince: well, you can run puppet elsewhere 14:21:01 shardy, I wrote about puppet in openstack-dev, it's not good solution 14:21:20 shardy: sure, but we aren't providing a way to do that 14:21:29 dprince: do we have to though? 14:21:37 EmilienM: that is not 100% accurate... upstream puppet CI uses puppet-tempest and a bunch of other steps to set it up 14:21:43 like, for CI purposes, and many operators, configuring it on the undercloud is OK 14:21:45 * dprince doesn't like the enable_tempest option in instack 14:22:06 trown: puppet-tempest has in charge of tempest.conf management 14:22:09 Folks are still free to configure it $somewhere_else via whatever method they like 14:22:19 right ^ 14:22:54 EmilienM: there is a very thorough exploration of using puppet-tempest on the ML by sshnaidm 14:23:08 shardy: for the same reasons I didn't want people going and adding Ansible dynamic discovery to the undercloud. Because once you put it there everyone just shells into the undercloud for everything 14:23:12 it is not so simple to use 14:23:20 trown: cool, so let's not use it, I don't mind; 14:23:36 :( 14:23:52 dprince: Ok, so perhaps we shouldn't configure tempest at all, and just implement a solution inside tripleo-ci? 14:24:14 let me please to summarize a little, there is a patch with configure_tempest.py in CI repo which configure tempest and run tests: https://review.openstack.org/#/c/295844/ , please look at it in your time, try it 14:24:18 that is what the existing submission dows fwiw, and it works well as well 14:24:22 shardy: that, or I'd prefer a more "client" based solution. Which makes it more clear that you can install it anywhere... 14:24:30 I am +1 to tripleo-ci in the short term, with the hope that tempest figures this out in the longer term 14:25:15 dprince: Ok, so you advocate the python client also acting as a local config generation tool 14:25:28 shardy: I think that would make sense 14:25:43 * derekh is also happy to go with a tripleo-ci solution in the short term 14:25:53 shardy: I'd almost say this sounds like a missing part of tempest 14:25:55 trown: I'm not sure it will happen, honestly 14:25:59 shardy: like a python-tempestclient or something 14:26:07 trown: this topic is on the table for very long time 14:26:09 personally I see this as pretty out-of-scope for python-tripleoclient, but it seems like a pretty non-tripleo-specific thing to have in our tripleo-centric client 14:26:21 shardy: I'd prefer a more animated name... but at least that would tell people what it did 14:26:23 EmilienM: ya, but that is clearly where it should be... 14:27:06 Ok, we may have to timebox this topic a little - can we vote on anything concrete here today, or does this need to continue on the ML? 14:27:43 let's vote? :) 14:27:43 I think there is general positivity towards sshnaidm patch to tripleo-ci in the short term 14:28:18 sshnaidm: vote on what exactly - that we're OK with adding this into tripleo-ci as a first step? 14:28:27 shardy, yep 14:28:54 I'm +1 on that, as I think the *client discussion is much harder, and we'll commit to interfaces if we do that 14:30:01 Ok, lets move on 14:30:05 +1 also 14:30:11 tripleo-ci is a great first step 14:30:15 #topic bugs 14:30:40 So I sent a ML message that I've started trying to clean up the bug backlog 14:31:24 I marked a lot of things incomplete which had been open a really long time without activity - but there's still a ton of old stuff in there we need to purge 14:32:02 Any help purging the remaining old and now not relevant stuff would be much appreciated 14:32:51 #link https://bugs.launchpad.net/tripleo 14:33:00 Anything else bug related folks want to raise? 14:33:06 shardy, for this you need the permissions, right? 14:33:32 sshnaidm: I created a tripleo-drivers group, which is currently only tripleo-core 14:33:41 shardy: so you want to to look through bugs a close what loks irrelevant? 14:33:42 shardy, ok 14:33:59 If non core folks want to help with bug triage that's fine, I can add you 14:34:25 derekh: Yes, I'm trying to purge really old things not relevant to our current implementation 14:34:27 shardy, I'd be happy 14:34:42 we had like 400 open bugs, and trying to targed what was relevent to Newton is basically impossible 14:34:45 * derekh will help out 14:34:57 There's something to be said for "close them all, if they're real someone will re-open them" 14:35:07 Maybe that's a bit extreme... 14:35:11 I'll pick at them as well... 14:35:20 hewbrocca: That's kind of what I did, with a script that set everything pre-liberty incomplete with a message 14:35:24 we don't require permissions to mark as incomplete though do we? 14:35:26 shardy: we could organize a sprint of triage 14:35:31 I did that with puppet team during summit 14:35:31 shardy: I closed a few the other day, its more time consuming then I thought but worth it 14:35:40 beagles: No, you don't, or even better invalid ;) 14:35:43 we splited the list of bugs, and did triage 14:35:49 shardy: ack 14:36:08 we also had nearly 300 bugs 14:36:27 now, we have less than 50 14:37:01 EmilienM: Yeah, that's the sort of progress I'm hoping we can make - perhaps an organized bug day would be good, but lets try with a few folks helping out for now 14:37:15 wasn't the bot posting about untriaged bugs at some point? would that help spread the triaging over time and avoid this situation in the future? 14:37:42 gfidente: It's not untriaged bugs, it's stuff that's been triaged then sat there for 2 years 14:38:05 oh from the non-puppet implementation as well then? 14:38:05 Also, I created newton milestones, so if folks can assign them to newton when triaging, that would be good: 14:38:08 https://launchpad.net/tripleo/+milestone/newton-1 14:38:22 that will make it easier to decide when is a good time to cut interim/milestone releases 14:38:29 shardy yeah totally +1 on that 14:38:30 gfidente: Yes, exactly 14:38:42 Ok, unless there's anything else on bugs, shall we move on? 14:39:06 #topic Projects releases or stable backports 14:39:47 So, slagle and I asked for some changes to the release tagging: 14:39:50 https://review.openstack.org/#/c/308236/ 14:40:00 https://review.openstack.org/#/c/308574 14:40:14 basically we'll be cycle-trailing to match what the puppet team is doing 14:40:31 and also assert that we follow stable branch policy, with interim releases 14:40:55 Feel free to add feedback on those if you'd like 14:41:10 Anything else release related to discuss? 14:42:31 #topic CI 14:42:52 derekh: did you want to give a summary of the plans wrt the CI racks etc? 14:42:52 We got bitten by new dependencies for paramiko on friday so CI was out for a few days, its mostly fixed now, but I think nodepool still wont be able to build is nightly F22 image, so that still needs looking at I think 14:43:04 shardy: sure can do 14:43:37 Basically the current plan is to move to RDO cloud before the rack move, 14:44:01 then let RDO cloud absorb our HW 14:44:25 I'm not sure yet exactly how much quota we'll get before they take over our HW 14:44:35 derekh: do we have any data re how that's likely to impact our recent performance/capacity issues? 14:44:47 but we'll probably have to reduce are usage for a time 14:45:01 Yeah, that's what I was worried about ;) 14:45:07 performance - don't know 14:45:28 We've had several discussions around optimizing for performance, e.g more memory, SSDs etc 14:45:35 capacity - reduced for a time, untill they redeploy our HW 14:45:37 My response on this FWIW was 14:45:47 leave the rack in place until RDO-cloud is really ready 14:46:01 it'd be good to ensure we'll at least maintain comparable CI runtimes on the new cloud 14:46:07 I am also working on tripleo-centos-7 replacement slave for tripleo-fedora-22: https://review.openstack.org/#/c/311721/ 14:46:27 image is uploaded to tripleo cloud, but failing to boot ATM (missing AFS mirror). Have a patch to fix that 14:46:40 pabelanger: sounds good, thanks! 14:46:43 https://review.openstack.org/#/c/312058/ 14:46:57 derekh: do we have a date for the rack move? 14:46:59 i also hope to investigate using multi-node jobs in nodepool directly. if anyone wants to help with this, lets sync up 14:47:13 trown: we've got options on the date 14:47:20 we can actually wait as long as next year 14:47:26 hewbrocca: yup, just seeing your mail now, no need to rush the move but we have a Hard deadline 14:47:32 trown: July 1st 14:47:50 hewbrocca: ya, didn't know that? 14:47:52 oh... then definitely +100 to not moving before we have at least some jobs running in RDO-cloud 14:48:02 hewbrocca: that changes things 14:48:48 as far as RAM and SSD upgrades , we're waiting on orders to arrive, so that should be happening soon 14:50:03 derekh: I guess my point was, if we do those upgrades, and the nodes are then added to RDO cloud, will we be able to get dedicated access to that pool of nodes 14:50:16 shardy: that would be the idea, yes 14:50:31 hewbrocca: ack, sounds good then, thanks for clarifying 14:50:50 Ok, anything else CI related before we move on? 14:51:10 pabelanger: ack, thanks 14:51:16 Periodic jobs failed last night has anybody looked into it? Once we get it passing we can start using a cached overcloud images. 14:51:40 derekh: not yet, but I will have a look afterwards 14:51:54 #topic Specs 14:52:08 So, perhaps we should change that topic to just "features" or something 14:52:21 dprince: derekh: likely related to static.o.o filesystem issue 14:52:42 pabelanger: ack, will keep that in mind 14:52:48 IMO we shouldn't enforce specs for all features this cycle, and we did agree a while back to try the spec-lite bug approach similar to how glance and other projects do it 14:52:53 https://bugs.launchpad.net/tripleo/+bugs?field.tag=spec-lite 14:53:12 I created the tag, so if you want to add a minor RFE, you can do it as a bug and tag it appropriately 14:53:28 in particular it'd be good to capture a laundry-list of usability issues via this method 14:53:43 if a spec-lite much different from a blueprint? 14:53:53 *is 14:53:56 slagle: Not really, other than it's easier to have a discussion in a bug 14:54:02 https://blueprints.launchpad.net/tripleo 14:54:25 blueprints are also still fine, and I've targetted most of those which weren't expired/obsolete to newton 14:54:53 tbh I don't really mind what method folks use provided it's tracked somewhere, and targetted to Newton 14:54:57 shardy: ok, i filed one i'd like to tackle in newton: https://blueprints.launchpad.net/tripleo/+spec/undercloud-elements 14:55:10 then we can reasonably see what's on the roadmap, and figure out how we're doing ref the backlog 14:55:12 hopefully that is uncontentious :) 14:55:42 Ok, 5mins - anything else spec/feature related, or shall we go to open discussion? 14:56:01 I added a bp to add dvr support last night 14:56:18 Ok, I'll trage the new BPs today, thanks! 14:56:22 triage even 14:56:42 #topic Open Discussion 14:56:48 but it's kind of segue into the open discussion 14:56:50 Anything folks want to raise? 14:57:00 one new tripleo.org thing 14:57:06 So I added a blogs page here 14:57:10 #link http://tripleo.org/blog-posts.html 14:57:18 I haven't finished any container specs yet. Will try and get them up soon 14:57:23 the idea being to highlight tripleo specific blogs 14:57:23 I've been asked about the composable roles changes and time estimates etc. 14:57:24 slagle: for that instack-undercloud bp would we get rid of the puppet element eventually too? and just call puppet apply? 14:57:38 seems a bit weird to use DIB for just that one element 14:57:43 dprince: Nice, I'm doing a session summary from Summit which I'll probably blog and post to openstack-dev 14:57:46 dprince: nice 14:57:49 trown: likely, yea 14:57:55 need to iterate on figuring out how to better integrate it w/ planet.openstack.org but this is a start: https://review.openstack.org/#/c/311910/ 14:57:56 cool 14:57:56 trown: a bit further down the road probably 14:58:04 trown: then instack-undercloud wouldnt use instack :) 14:58:12 and we can declare success 14:58:23 dprince: nice, should we come up with a list of potential blogging topics? 14:58:23 slagle: lol ya, that is what I was thinking... a bit odd :) 14:58:25 shardy: nice, this is a way to crack the blogging whip a bit. On myself included 14:58:40 derekh: yep, will do. Collaborative blogging man! 14:58:45 beagles: see the mail from EmilienM, there's a group of folks working on composable services, and I'm looking into ways to do fully composable roles via some template pre-processing 14:59:39 shardy: yup... generally I think we are going to need some idea of how to set expectations for new things like the DVR for newton 14:59:41 dprince: the text boxes formatting is messed up 14:59:53 beagles: OK, let's continue in #tripleo 14:59:57 shardy: and other services as well of course 14:59:58 slagle: sounds like a -1 to me :) 14:59:59 yup 15:00:01 Times up folks, thanks! 15:00:05 #endmeeting