19:00:54 <lifeless> #startmeeting tripleo 19:00:55 <openstack> Meeting started Tue Nov 12 19:00:54 2013 UTC and is due to finish in 60 minutes. The chair is lifeless. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:59 <openstack> The meeting name has been set to 'tripleo' 19:01:04 <lifeless> #topic agenda 19:01:09 <lifeless> bugs 19:01:09 <lifeless> reviews 19:01:10 <lifeless> Projects needing releases 19:01:10 <lifeless> CD Cloud status 19:01:10 <lifeless> CI virtualized testing progress 19:01:12 <lifeless> Insert one-off agenda items here 19:01:14 <lifeless> post HK wrapup 19:01:17 <lifeless> open discussion 19:01:21 <lifeless> #topic bugs 19:01:29 <lifeless> #link https://bugs.launchpad.net/tripleo/ 19:01:29 <lifeless> #link https://bugs.launchpad.net/diskimage-builder/ 19:01:29 <lifeless> #link https://bugs.launchpad.net/os-refresh-config 19:01:29 <lifeless> #link https://bugs.launchpad.net/os-apply-config 19:01:29 <lifeless> #link https://bugs.launchpad.net/os-collect-config 19:01:31 <lifeless> #link https://bugs.launchpad.net/tuskar 19:01:34 <lifeless> #link https://bugs.launchpad.net/tuskar-ui 19:01:36 <lifeless> #link https://bugs.launchpad.net/python-tuskarclient 19:01:51 <jprovazn> hi 19:02:03 <lsmola_> hello 19:02:15 <marios> evening all 19:02:30 <pleia2> o/ 19:02:34 <lifeless> and -this is a first- we have no bugs that haven't been triaged; *and* we have no bugs that are critical open. 19:02:37 <lifeless> congrats everyone! 19:02:54 <lsmola_> yaay 19:02:59 <slagle> nice 19:03:02 <lifeless> #info -this is a first- we have no bugs that haven't been triaged; *and* we have no bugs that are critical open. 19:03:27 <lifeless> Anyone have a pet bug they want to discuss ? 19:04:00 <dprince> well, my dog has fleas 19:04:09 <lsmola_> lol 19:04:27 <lifeless> moving right along :) 19:04:33 <lifeless> #topic reviews 19:04:46 <lifeless> http://russellbryant.net/openstack-stats/tripleo-openreviews.html 19:04:52 <lifeless> #link http://russellbryant.net/openstack-stats/tripleo-openreviews.html 19:05:00 <lifeless> 3rd quartile wait time: 0 days, 6 hours, 35 minutes 19:05:04 <lifeless> thats looking pretty hawt 19:05:25 <jog0> wow 19:05:26 <lifeless> especially since we just had massive teamwide travel disruption etc 19:06:03 <lifeless> #info reviews looking good - oldest review is < 7 hours 19:06:16 <lifeless> Anyone have stuff around reviews they want to discuss? 19:06:56 <slagle> you proposed to add me to core. did i pass the vote? :) 19:07:33 <SpamapS> I think we had massive teamwide busy-not-submitting-patches too.. but it is good to see we didn't let either side disrupt the other ;) 19:07:37 <lifeless> slagle: I don't know 19:07:51 <lifeless> slagle: lets see 19:08:23 <lifeless> slagle: noone disagreed, but we didn't get as many respondents as I would have liked. 19:08:26 <lifeless> slagle: so will add you 19:08:35 <lifeless> slagle: and urge folk to vote next month 19:08:50 <lsmola_> slagle, I have noticed only +1 19:09:30 <lsmola_> lifeless, I think I forgot to reply, so I give +1 to all :-) 19:09:55 <jomara> easy, tiger 19:10:01 <lsmola_> hehe 19:10:55 <lsmola_> lifeless, seemed to me like there was 100% agreement anyway :-) 19:11:31 <lifeless> let me action that now 19:12:17 <lifeless> #info slagle added to core 19:13:01 <SpamapS> \o/ 19:13:03 <SpamapS> moar core 19:13:22 <lifeless> #topic Projects needing releases 19:13:49 <lifeless> rpodolyaka1: around? 19:13:54 <rpodolyaka1> lifeless: yep 19:14:16 <rpodolyaka1> it seems that only tuskar and python-tuskarclient have bugs in 'Fix commited' state 19:14:21 <rpodolyaka1> since the last release 19:14:46 <rpodolyaka1> I could volunteer to make releases of those this week too :) 19:14:51 <lifeless> rpodolyaka1: I think we should go off of git, not off the bug tracker. 19:14:58 <lifeless> rpodolyaka1: as code can land without bugs existing 19:15:14 <rpodolyaka1> make sense 19:15:24 <lifeless> rpodolyaka1: and thanks! 19:15:28 <SpamapS> I started working on a launchpad script to translate git -> LP bugs 19:15:37 <lifeless> #info rpodolyaka1 to do another set of releases 19:15:42 <rpodolyaka1> ack 19:15:42 <lifeless> SpamapS: what does that mean? 19:15:47 <SpamapS> backburnered, but I can dig it out and get it up some where that everybody can use it. 19:16:06 <SpamapS> lifeless: git knows whether or not a bug fix has landed in a release.. 19:16:24 <lifeless> I have a prototype thing to report which projects need releases and help determine what version they need 19:16:30 <rpodolyaka1> btw, I made a wiki page to describe the release management process https://wiki.openstack.org/wiki/TripleO/ReleaseManagement 19:16:35 <lifeless> rpodolyaka1: I saw - awesome 19:16:39 <lifeless> #link https://wiki.openstack.org/wiki/TripleO/ReleaseManagement 19:16:41 <SpamapS> lifeless: we can scan fix committed bugs, find the review that landed, and move them to fix released. 19:16:58 <lifeless> SpamapS: won't that leave fix committed bugs w/o metadata open and stale? 19:17:01 <marios> rpodolyaka1: i can help too if you like - ah, was just about to say ï'll hassle you for info on how but you posted that wiki page 19:17:21 <SpamapS> lifeless: yes. 19:18:06 <lifeless> #topic CD Cloud status 19:18:14 <lifeless> It's up. THen it's down. THen it's up. 19:18:48 <lifeless> I think we need to forge ahead with state preservation, live upgrades and then circle back on reliablity 19:18:59 <lifeless> because we'll end up blocking the CI effort otherwise. 19:19:15 <marios> rpodolyaka1: so anyway, let me know if you need help 19:19:26 <SpamapS> agreed, also we can start ramping up instrumenting to help debug the reliability. 19:19:27 <rpodolyaka1> marios: sure 19:19:54 <lifeless> jog0: whats the status of the rebuild patches - they are now critical path in that we can't move ahead until they are done 19:19:55 <jog0> lifeless: make sense, but what are the reprocussions on CI if we cannot deploy reliably 19:20:06 * jog0 looks 19:20:23 <lifeless> jog0: thats what the rolling deploy story is about, so we don't take down a live node etc 19:20:39 <lifeless> jog0: CI won't start out gating, just silent queue, so we can iterate up 19:20:48 <jog0> lifeless: oh right 19:20:55 <jog0> lifeless: patches are in review 19:21:15 <jog0> both got comments today one -1 will look at that and work on the patch you handed me as well 19:22:03 <lifeless> jog0: so - https://trello.com/b/0jIoMrdo/tripleo 19:22:06 <jog0> https://review.openstack.org/#/c/51735/ https://review.openstack.org/#/c/52704/ https://review.openstack.org/#/c/54308/ 19:22:32 <lifeless> jog0: we need nova rebuild for baremetal, we need rebuild preserving ephemeral for baremetal and we need baremetal ephemeral support 19:22:41 <lifeless> jog0: I believe only the latter one is in review 19:23:19 <lifeless> jog0: this worries me as I think atm only you have picked up the cards for this set of work 19:23:35 <lifeless> Can anyone else dive in and help with these changes? 19:23:52 <jog0> ack, will get patches out this afternoon (after I file expense reports :/) 19:24:09 <lifeless> yeah, tell me about that :) 19:24:55 * dprince filed his 19:25:31 <jog0> dprince: did you just volunteer to help with the nova changes? 19:26:06 <dprince> jog0: I can, certainly if we need it 19:26:18 <dprince> jog0: but I was referring to filing my expense report :) 19:26:35 <dprince> jog0: happy to help though w/ Nova too 19:27:04 <jog0> dprince: being this is the MVP help is good 19:27:16 <lifeless> SpamapS: can you ? 19:27:37 <rpodolyaka1> I'm willing to help too :) 19:28:34 <lifeless> rpodolyaka1: awesome 19:29:03 <lifeless> ok, so - the top two cards in the trello I linked, under 'current MVP' - they link to an etherpad with details 19:29:17 <SpamapS> lifeless: yes I can, currently just playing with the other side (element changes to support /mnt/state) 19:29:30 <lifeless> please ask me/jog0 if you have any questions about whats needed in nova 19:29:41 <lifeless> SpamapS: I suspect latency on the nova side is going to dominate 19:30:02 <rpodolyaka1> lifeless: ack 19:30:27 <SpamapS> lifeless: agreed 19:30:38 <jog0> lifeless: yeah, although I can use up some of my karma on this once we have all the patches in place 19:30:53 <lifeless> ok 19:31:03 <lifeless> #topic CI virtualized testing progress 19:32:04 <lifeless> pleia2: ^ 19:32:17 <pleia2> got to meet up with dprince and derekh at summit about this, so they're going to help out 19:32:28 <pleia2> we all need to get on the same page with a lifeless chat though 19:33:29 <dprince> pleia2: sure. The extra trello for tripleo-ci efforts is meant to help out here. 19:35:03 <pleia2> dprince: do you want to sync up with lifeless after meeting, or plan something when derekh can attend (maybe tomorrow?) 19:35:24 <dprince> pleia2: lets sync up ASAP 19:35:30 <pleia2> ok good 19:35:36 <lifeless> pleia2: cool; is there anything we should touch on team wide about this? 19:35:42 <pleia2> lifeless: I don't think so 19:35:45 <lifeless> ok 19:36:00 <lifeless> #topic post HK wrapup 19:36:10 <lifeless> so I need to go through all the blueprints, set administrivia state etc 19:36:57 <lifeless> can everyone that submitted a session make sure you've captured action items in the etherpads: any pad with no action items I'm going to presume to be historical record and close the blueprint that pointed at it:) 19:37:34 <lifeless> I'm not likely to get this done until next week or even the week after, so no need to panic - OTOH doing it while fresh helps prevent memory decay 19:38:01 <lifeless> I thought our sessions were fairly effective, though one thing stood out to me 19:38:15 <slagle> there wasn't a bp open for the session i proposed. should i just open one in that case? 19:38:26 <lifeless> We're not communicating clearly that we embrace diversity - e.g. the ceph vs glusterfs discussion 19:38:30 <lifeless> slagle: no, please don't :) 19:38:49 <slagle> ok 19:38:56 <lifeless> In my head we totally want both things to be installable. 19:39:00 <mordred> lifeless: I'm only lurking here, butI'd agree with that 19:39:11 <lifeless> And -if- there are sufficient resources we should gate on both setups working 19:39:17 <mordred> I constantly have to communicate to people that tripleo is open 19:39:50 <lifeless> If there aren't sufficient resources, or if neither is working at all, then we have a triage problem vs an openness problem. 19:41:03 <lifeless> Same for o*c/puppet/chef - we should totally support what users will want; we deliberately designed to be neutral on the enterprise-CM front by having a super light weight layer that noone can confuse for chef/puppet/salt/ansible etc etc etc 19:41:32 <lifeless> mordred: thanks for the feedback 19:41:55 <lifeless> Does anyone disagree with what I'm saying? THis is an idea time to discuss... 19:42:36 <mordred> one clarifying thing, just so that we don't get in a wad later 19:42:44 <mordred> I agree with what you said 19:42:46 <mordred> except 19:42:56 <mordred> if you combine this sentence: 19:42:58 <mordred> And -if- there are sufficient resources we should gate on both setups working 19:43:00 <mordred> with this one: 19:43:06 <mordred> Same for o*c/puppet/chef - we should totally support what users will want 19:43:19 <mordred> it might lead people to believe that if we had resources we might gate on puppet or chef 19:43:21 <mordred> which is not the case 19:43:26 <lifeless> isn't it? 19:43:28 <mordred> no 19:43:31 <mordred> categorically not 19:43:31 <lifeless> why not? 19:43:41 <mordred> bcause those aren't about having enough resources 19:43:49 <mordred> they're about developer segmentation 19:44:12 <mordred> we want any openstack developer to have a reasonable expectation to be able to debug an issue that pops up in the gate 19:44:44 <lifeless> So thats not currently touched on in the stuff I wrote up for review in the infra docs 19:44:46 <mordred> gating on chef or puppet or salt increases teh surface area to an unreasonable amount of material each developer would need to grok 19:44:49 <lifeless> about requirements to have things gated 19:45:02 <clarkb> lifeless: right thats the bits I was talking about needing more 'why' 19:45:10 <mordred> I think it's a different thing 19:45:13 <lifeless> I don't disagree with you, but thats a infra constraint, not a tripleo constraint 19:45:18 <mordred> or a different aspect of the same 19:45:21 <mordred> it's neither 19:45:24 <mordred> it's a project constraint 19:45:33 <mordred> well, scuse me - said that wrong 19:45:35 <lifeless> we're about to rathole; but 19:45:48 <mordred> it's not an infra constraint either- we can and do run puppet/chef 19:45:50 <mordred> but yes 19:45:51 <slagle> what's the way forward on getting the work we did for the puppet based elements as "part of tripleo"? 19:45:54 <mordred> just wantedot clarify yourlanguage 19:46:01 <slagle> should we propose for stackforge or something? 19:46:13 <lifeless> openstack as a whole is very wide already - I doubt any single developer truely understands cinder + neutron + tempest + nova + all the clients + devstack + d-g + jenkins + nodepool sufficiently well to debug any arbitrary gate failure 19:46:26 <ccrouch> lifeless: +1 19:46:31 <dprince> lifeless: I do 19:46:33 <lifeless> mordred: so what you're saying isn't actually making sense to me 19:46:37 * dprince :) 19:46:43 <mordred> d-g + jenkins + nodepool 19:46:48 <mordred> are not required for the dev to understand 19:46:51 <mordred> they are not relevant 19:47:09 <mordred> they dev DOES need to understand and be able to reproduce devstack + clients + their code 19:47:12 <mordred> adn they can do that right now 19:47:16 <lifeless> mordred: d-g and jenkins are; nodepool you are right 19:47:22 <mordred> no, they are not 19:47:31 <lifeless> mordred: hang on, you just massively reduced the scope by saying 'their code', not 'all of openstack' 19:47:34 <mordred> it is totally possible for a dev to reproduce a failure without jenkins 19:47:41 <mordred> ok 19:47:45 <mordred> back to the beginning 19:47:48 <mordred> because we're in the middle 19:47:51 <lifeless> mordred: but you're assessing whether gating on e.g. chef would make sense for part of tripleo by 'any openstack developer', not by 'tripleo devs' 19:47:56 <lifeless> thats inconsistent 19:48:18 <mordred> ok. we are talking about two different thigns 19:48:25 <mordred> let's finish talking about hte first one 19:48:34 <dprince> As someone who has run quite a bit of puppet/chef upstream in the past I'm quite used to the idea of them being considered 3rd party. 19:48:38 <lifeless> slagle: the puppet stuff needs to meet the technical aspects - decoupling the things it conflates - then its fine to come in 19:48:56 <dprince> Having them upstream might be a good feedback loop however. 19:49:07 <mordred> the point of any of this is that a developer who uploads a change should have a reasonable expectation of being able to locally test the change as the gate tests it 19:49:12 <mordred> so that if the gate fails their change 19:49:15 <lifeless> So it may be moot, as I'm confident we don't have test resources yet. 19:49:23 <mordred> they have a reasonable expectation that they can debug the problem 19:49:48 <mordred> that's a design tenant for the gate and always has been 19:50:02 <slagle> lifeless: not sure i follow. you mean seperating the element that enables puppet support vs the ones that are puppet based? 19:50:24 <mordred> lifeless: does that part make sense? 19:50:40 <lifeless> slagle: supporting package based install vs supporting puppet for CM in the deployed image vs actual puppet details of CM 19:51:13 <lifeless> mordred: sure 19:51:23 <slagle> yea, ok, makes sense. i think we were going to try an split that stuff up 19:51:27 <mordred> great. so that's the general integrated gate 19:52:06 <mordred> now, as for having a tripleo specific gating test that gates on things all the way including running puppet in node ... honestly that's a new scenario that I don't think we've well defined yet 19:52:11 <mordred> I would be opposed to gating nova on that 19:52:33 <mordred> but I think an argument could be made that a tripleo gate containing that could be in-game 19:53:08 <lifeless> I think of the same way as things like postgresql - and yes I know we have headaches with that :) 19:53:41 <lifeless> which is that where there is a pluggable layer with significant community interest, and we have resources [provided by said community], gating on it is beneficial to keeping it intact. 19:53:47 <dprince> mordred: if we don't gate Nova on it too then it'll just end up broken, no? 19:53:50 <lifeless> And it will have the same headaches if the level of interest is too low. 19:53:59 <mordred> dprince: it's possible 19:54:11 <lifeless> so I think we need to be very clear about the commitment needed to add extra backends to the gate 19:54:15 <mordred> dprince: but I do not think that the puppet/chef rule changes just because we're doing tripleo and not devstack 19:54:21 <dprince> I see this whole space as 3rd party 19:54:34 <dprince> And very valuable all the same. 19:54:38 <lifeless> ok, I'm going to timebox this now 19:54:41 <mordred> kk 19:54:42 <lifeless> since we have 6 minutes 19:54:43 <dprince> People get all worked up about gates sometimes. 19:54:46 <mordred> sorry for the diversion 19:54:49 <lifeless> #topic open discussion 19:55:04 <lifeless> now of course, if y'all want 6 minutes of gate discussion, go to town 19:55:58 <marios> has anyone given thought to the whole merge.py/tripleo-heat-templates long term? 19:56:15 <lifeless> marios: yes, that should be entirely HOT 19:56:20 <marios> i ask because we're trying to get tuskar using that (merge.py) 19:56:55 <stevebaker> there needs to be some kind of client-side inclusion mechanism 19:56:58 <lifeless> marios: a small number of highly parameterisable templates, they should live in tripleo-heat-templates (as they should be directly usable) and tuskar shouldn't need to do any mangling of them at all. 19:56:58 <marios> so one thing... could we make merge.py have a'main' so i canimport and call, vs something fugly like subprocess 19:57:09 <lifeless> marios: totally - just add it 19:57:25 <slagle> that came up in a design session. the plan is to clearly identify why merge.py exists and how we use it, and submit as enhancements to Heat 19:57:29 <marios> lifeless: ack, kinda working on that on my local branch but wanted to sanity check 19:57:32 <marios> thanks 19:58:16 <marios> slagle: i'll ping you about that tomrorrow - would like to hear more 19:58:19 <lifeless> in general, tuskar needs to lean /much/ more heavily on nova and neutron - we need to stop manually scheduling stuff and depend on nova/heat to get it right 19:58:27 <stevebaker> It might be that only individual resource properties need an inclusion mechanism 19:58:53 <lifeless> I have on my todo to review where we are at and describe clearly whats in my head for getting long term reuse 19:58:56 <marios> lifeless: yes... that whole business of the 'bash script in heat meatdata to create flavors' etc... (as one example) is one of the things we need to resolve this next sprint 19:59:07 <lifeless> marios: interestingly, I was chatting with mikal 19:59:21 <lifeless> marios: and he did not understand *at all* why flavor creation was at all interesting for tuskar. 19:59:47 <lifeless> marios: so - one thing I think we might want to do is validate that vs deployer needs. 19:59:58 <marios> lifeless: yeah. i guess the hk demo wasn't demonstrating that since there was only one compute class created 20:00:05 <lifeless> marios: not even that 20:00:12 <lifeless> marios: I went through it with him on sunday 20:00:33 <lifeless> marios: and he just didn't get the value, even if you have multiple different hardware profiles like racksapce does. 20:00:45 <lifeless> marios: I am worried we're solving a problem that we only think deployers have. 20:01:01 <lifeless> ok, sorry to cut this short, but EOM. 20:01:03 <lifeless> #endmeeting