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