14:00:37 <dprince> #startmeeting tripleo 14:00:38 <openstack> Meeting started Tue Dec 1 14:00:37 2015 UTC and is due to finish in 60 minutes. The chair is dprince. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:42 <openstack> The meeting name has been set to 'tripleo' 14:00:52 <eggmaster> o/ 14:00:54 <akrivoka> hi \o 14:00:58 <dprince> o/ 14:00:59 <marios> o/ 14:01:19 <gfidente> o/ 14:01:35 <weshay> \o 14:01:38 <hrybacki> o/ 14:02:04 <slagle> hi 14:02:23 <dprince> #topic agenda 14:02:24 <dprince> * bugs 14:02:24 <dprince> * Projects releases or stable backports 14:02:24 <dprince> * CI 14:02:24 <dprince> * Specs 14:02:26 <dprince> * Review Priorities: https://etherpad.openstack.org/p/tripleo-review-priorities 14:02:29 <dprince> * one off agenda items 14:02:31 <dprince> * open discussion 14:02:37 <adarazs> o/ 14:02:41 <shardy> o/ 14:03:01 <dprince> anything to add to our agenda this week? 14:03:38 <jistr> o/ 14:05:47 <tremble> I guess the general Zuul/CI issues we've been seeing will be covered in the CI topic :) 14:05:49 <rbrady> o/ 14:05:56 <dprince> tremble: yep. 14:06:02 <dprince> lets move on then 14:06:13 <dprince> #topic bugs 14:07:08 <shardy> dtantsur posted a revised workaround for bug #1507738 which has now been approved in ironic 14:07:08 <openstack> bug 1507738 in Ironic "ipxe fails on Centos 7 (inc: command not found)" [High,In progress] https://launchpad.net/bugs/1507738 - Assigned to Dmitry Tantsur (divius) 14:07:16 <shardy> I tested it locally and it seems to work OK 14:07:18 <trown> I have one bug to call out: https://bugzilla.redhat.com/show_bug.cgi?id=1272572 patch: https://review.openstack.org/#/c/239109/2 14:07:18 <openstack> bugzilla.redhat.com bug 1272572 in openstack-tripleo-heat-templates "Error: Unable to retrieve volume limit information when accessing System Defaults in Horizon" [High,Post] - Assigned to jtrowbri 14:07:43 <trown> I should have probably made a LP bug for it, but I kept putting it off... 14:07:58 <dprince> shardy: nice, thanks for pointing that out 14:07:59 <trown> it was brought up last week on the #rdo meeting though 14:08:07 <shardy> #link https://review.openstack.org/#/c/250745/ 14:08:52 <trown> it shows that we are missing any validation of horizon in the overcloud... which is true for RDO CI as well 14:09:06 <shardy> trown: we should really raise LP bugs then link them from the BZ, vs putting bz links into upstream commit messages 14:09:15 <dprince> #link https://review.openstack.org/#/c/239109/ 14:09:17 <shardy> it's a minor thing, but a good habit to get in to IMHO 14:09:17 <gfidente> trown, do you know if tempest has any test for the horizon UI? 14:09:32 <dprince> shardy: agree, LP bugs help us track things upstream better 14:10:13 <shardy> trown: we're missing any validation of *anything* aren't we? 14:10:19 <trown> shardy: ya, I just kept putting that part off, and then it got brought up on #rdo meeting... I am definitely happy to file a LP bug if that is the only thing missing from the patch 14:10:22 <shardy> beyond deploying an overcloud that doesn't fail? 14:10:30 <trown> shardy: ah for tripleoci that is true ya 14:10:31 <gfidente> shardy, yeah this came up last week, currently we are 14:10:39 <trown> rdo we run tempest smoke 14:10:55 <shardy> trown: I've been looking at reinstating something, maybe instack-test-overcloud or some similar smoke test 14:11:23 <trown> shardy: cool, I really liked the idea from summit of using a heat stack 14:11:33 <trown> but we are a bit off the bug topic 14:11:42 <shardy> trown: Yeah, that would be nice actually, doesn't solve the horizon issue tho ;) 14:11:45 <slagle> marios has a patch for that 14:11:46 <slagle> #link https://review.openstack.org/#/c/241167/ 14:11:48 <shardy> trown: yeah, sorry 14:12:14 <shardy> slagle: nice! 14:13:28 <shardy> if we did that via heat, it'd hardly any extra time, and we'd cover another service 14:13:44 <shardy> we go ahead with this approach for now tho 14:13:57 <dprince> Since it was brought up: is it worth -1'ing upstream reviews that link to Bugzilla's instead of LPs? 14:14:14 <trown> dprince: I am ok with that policy 14:14:17 <marios> slagle: yeah, so i started poking at that (rewriting as heat template) -someone was asking me about it in channel last week (they wanted to have a go at doing the heat version) 14:14:18 <jdob> i think so, just to make sure they are filed 14:14:23 <shardy> dprince: I've taken to commenting but not downvoting, but maybe it's time to get stricter 14:14:39 <marios> shardy: comment above about heat template sorry was meant for you 14:15:03 <shardy> marios: will do, let me know if I can help out at all, shouldn't be too hard 14:15:17 <slagle> dprince: i don't like -1'ing for bz links 14:15:35 <slagle> unless the policy is that we must have an associated LP bug for anything that is a bug 14:15:48 <slagle> absent that, the bz link is just extra information 14:15:54 <slagle> helpful information at that 14:15:54 <dprince> slagle: it just makes things harder to track upstream 14:15:56 <shardy> slagle: the problem is, we shouldn't be tracking things *only* downstream 14:16:16 <shardy> because then we don't have any record of the fixes as they land in the upstream repos, other than the commit logs 14:16:30 <slagle> if you -1 someone on a bz link, are you : asking for a LP bug to be filed, or asking them to remove the bz link? 14:16:34 <dprince> slagle: I suppose I'm fine w/ the BZ link being there too, it is just the missing LP upstream that is the problem 14:16:49 <slagle> dprince: ok. so what your'e really saying is that all bug fixes must have a LP bug filed 14:16:50 <shardy> slagle: just to raise a LP, it's fine to *also* have a bz if folks want to 14:17:22 <slagle> ok, this is a pretty big shift in the way we've handled bugfixes in the past, so i just want to be clear 14:17:27 <shardy> slagle: although we already have a perfectly good means to associate the LP with bz (external trackers), so having the bz link isn't strictly needed anymore 14:17:39 <slagle> it really does sound like you're asking that any bugfix have an associated LP bug 14:17:56 <slagle> and we -1 if it doesn't 14:18:00 <dprince> slagle: my preference would be that, yes. Unless the bug is really trivially simple 14:18:15 <jistr> slagle: i wouldn't like to enforce 'every bugfix must have LP bug' 14:18:18 <slagle> otherwise, if someone -1's me for a bz link, i'm just going to remove the link from the commit msg 14:18:20 <jistr> but perhaps 14:18:30 <shardy> slagle: AFAIK it's the way most other projects do it - any non-cosmetic patch should really have either a bug or a blueprint associated with it 14:18:39 <shardy> *but* we don't do "a release" upstream 14:18:44 <shardy> so it's less of an issue 14:19:05 <jistr> "if the bug is serious/complex enough that it warrants a link to a bug tracking tool, make sure that the bug tracking tool is LP, and if you want to add a BZ link too, feel free" 14:19:07 <shardy> imagine if e.g heat released Mitaka, and we said there were zero bugs fixed or whatever, vs ~300 14:19:07 <slagle> shardy: yea, i know. i've also encountered feedback, albeit antecdotal, that a lot of people hate that 14:19:09 <jistr> ^ how does that sound 14:19:14 <slagle> "-1, please file a bug" 14:19:18 <slagle> this is just so pedantic 14:19:31 <derekh> slagle: +1 14:19:34 <shardy> jistr: +1 14:19:38 <jaosorior> jistr: +1 14:19:41 <jistr> yea i don't like "-1, please file a bug" either 14:19:59 <tremble> jistr: +1 14:20:11 <dprince> jistr: +1, that is the idea 14:20:21 <dprince> okay, lets move to CI then 14:20:24 <dprince> #topic CI 14:20:32 <slagle> or just remove the bz link i guess 14:20:42 <shardy> slagle: do you disagree that it's not all that cool from a community building perspective to *only* track thinks in the downstream bug tracker? 14:20:56 <slagle> nope 14:21:04 <shardy> Maybe it is pedantic, but it's about perception of the community, and how we work 14:21:12 <jistr> slagle: if the commit message itself carries enough info for the patch to make sense, removing the BZ link is fine too i guess 14:21:19 <slagle> shardy: i disagree that providing additional info warrants a -1, when we have no official policy on when bugs should be filed 14:21:33 <gfidente> to be honest, I don't consider BZ that much of a downstream thing 14:21:38 <slagle> "if there's a downstream bug" isn't a policy on when to file an upstream bug 14:21:40 <trown> I would prefer if someone was going to -1 to at least give feedback on the technical merit of the patch at the same time 14:21:50 <tremble> shardy: As someone trying to figure out what was involved, having *both* links can be useful, but the LP bug should have a good explanation attached... 14:22:01 <shardy> slagle: Ok, maybe we agree to try to not do it and just comment then, that's what I'm already doing fwiw 14:22:14 <gfidente> I understand we shouldn't use the Closes: shortcut for BZ bugs 14:22:17 <dprince> slagle: right, but that there is an upstream patch fixing a bug, does warrent an LP bug IMO 14:22:23 <dprince> slagle: so lets make an official policy then 14:22:29 <gfidente> but I am totally fine linking to BZ reports if that is there the bug report comes from 14:22:35 <gfidente> cause BZ is not downstream IMHO 14:22:46 <shardy> gfidente: it's not the upstream bug tracking tool, so it is by definition a downstream thing 14:22:49 <slagle> dprince: that's exactly what i'm tryign to clarify. "an upstream patch fixing a bug" 14:22:58 <slagle> dprince: sounds like you want a LP bug for that? 14:23:10 <jdob> gfidente: i think it is; even if anyone can make an account, its not part of upstream itself 14:23:18 <slagle> it's totally irrelevant if there's a bz already filed or not 14:23:18 <jdob> its open, but that doesnt mean upstream 14:23:19 <dprince> slagle: exactly, what jistr said 14:23:41 <gfidente> so to support further what jistr said 14:23:42 <trown> I think we probably need to move this to the ML 14:23:51 <trown> sorry for opening a can of worms 14:23:55 <gfidente> I think links to BZ are totally fine 14:24:04 <dprince> yeah, unless you all would like to cancel the second half of this meeting time to move on I think 14:24:12 <dprince> topic is CI... 14:24:18 <slagle> let's come up with a policy on when a LP bug is required, totally independent of whether or not red hat has decided to open a bug in bugzilla 14:24:27 <shardy> FWIW, we had this *exact* discussion in the heat community $years ago, and settled on saying non-cosmetic fixes should have LP bugs 14:24:41 <shardy> One compelling reason is it's *much* easier to track stable backports 14:24:57 <shardy> e.g you tag the bug as liberty-backport-potential in LP, which is impossible if it's not in LP 14:25:14 <slagle> shardy: that's the exact discussion i'd like to see vs "just open one if there's one in bz already" 14:25:28 <dprince> derekh: want to give a CI update 14:25:35 <derekh> dprince: nope 14:25:36 <shardy> slagle: the bz doesn't help us at all in terms of tracking upstream backports 14:25:40 <derekh> ;-) 14:25:54 <derekh> so we had about 5 days of now CI jobs 14:26:13 <derekh> nodepool wasn't getting floating IPs for our VMs 14:26:20 <dprince> #link https://review.openstack.org/#/c/251438/ 14:26:32 <derekh> its was a regession in nodepool that has been reverted, all is ok now again 14:27:19 <dprince> derekh: yep, thanks for pushing that revert up and fixing it 14:27:20 <derekh> I got nothing major else to report 14:27:45 <dprince> seems like CI is otherwise stable. 14:27:53 <derekh> yup, 14:27:58 <dprince> derekh: should we add new columns to our report for the new job types though? 14:28:03 <derekh> actually, I also finally sent a mail 14:28:17 <shardy> derekh: thanks for figuring that out 14:28:19 <derekh> about adding ci back to heat and ironic, discussion is onging on the list 14:28:55 <shardy> The consensus seems to be +1 at least for Heat atm 14:29:17 <derekh> dprince: yup, here is start https://review.openstack.org/#/c/235421/ 14:29:26 <slagle> it seems that the other projects are also in favor of eventually having the job being voting 14:29:40 <slagle> is it possible to do that now in tripleo? 14:29:49 <slagle> might be good to establish a pattern 14:30:00 <derekh> shardy: yup, I have to do a little research, I don't think so 14:30:34 * dprince thinks our wall time is still too long to be voting 14:30:37 <derekh> shardy: to be voting you got to be in the gate, I don't think we have the resources needed or the redundancy to do that 14:30:58 <derekh> shardy: and what dprince said (thought) 14:32:08 * shardy thinks that reply was meant for slagle? ;) 14:32:21 <derekh> shardy: yes your right, sorry slagle ^^ 14:32:31 <dprince> #topic Projects releases or stable backports 14:32:33 <slagle> oh, so to leave a verified-1, even before the patch is workflowed+1, it must be a gate job? 14:32:50 <dprince> shardy: I skipped this topic early 14:32:54 <dprince> shardy: any updates this week? 14:33:04 <derekh> slagle: I'm not fully sure, /me will research 14:33:30 <shardy> dprince: So, there's a queue of patches up for stable/liberty CI, and derekh helped me find the latest issue earlier 14:33:46 <shardy> I hope we can push all those in very soon and declare stable/liberty ready for wider use 14:33:58 <shardy> it's been held up by the nodepool outage, amongst other things 14:34:22 <dprince> shardy: cool. Hopefully smooth sailing from here on then 14:34:30 <shardy> heh, hopefully 14:34:54 <shardy> I think we need a current-tripleo pin promoted by a stable periodic job to stop it from breaking 14:35:03 <shardy> but firstly let's land what's already posted 14:35:42 <shardy> One other thing - it was pointed out that puppet-tripleo doesn't have a stable branch 14:35:48 <shardy> are folks OK with creating one? 14:36:03 <dprince> shardy: ping EmilienM on that I think 14:36:08 <shardy> dprince: will do 14:36:13 <derekh> shardy: re stable periodic job, we also need that for master, the periodic job fails waiting on https://review.openstack.org/#/c/244526/ 14:36:19 <dprince> shardy: he is about to create stable branches for puppet modules soon I think 14:36:25 <EmilienM> dprince: hey 14:36:32 <shardy> derekh: Ok, thanks, we can sync up on that after 14:36:36 <EmilienM> shardy: yes, go ahead 14:36:43 <shardy> EmilienM: Ok, thanks! 14:36:49 <EmilienM> I did not create branches in puppet-tripleo because to me, it depends on TripleO 14:36:56 <EmilienM> I did not want to break something 14:37:04 <EmilienM> I just manage the 22 other modules 14:37:08 <shardy> EmilienM: Ok, it probably should have been branched when I created the other branches, but we missed it in the spec 14:37:12 <shardy> thanks for the clarification 14:37:22 <EmilienM> dprince, shardy: FYI - we released stable/liberty 14:37:27 <shardy> One other CI related thing 14:37:38 <shardy> I was discussing with derekh about moving tripleo.sh back into tripleo-ci 14:38:03 <shardy> because every change we make must work on both master and stable, and it's a bit of a headache having to backport every fix 14:38:10 <shardy> when we only really need one version 14:38:31 <shardy> also, given that it's a developer script, it seems like documenting pulling the script from tripleo-ci may be reasonable? 14:38:45 <trown> that seems reasonable to me 14:38:51 <shardy> e.g we don't want it to be packaged up and distributed as part of tripleo-common anyway 14:39:15 <slagle> trown: so no one will ever want to tripleo.sh as part of rdo? 14:39:20 <derekh> +1 14:39:21 <dprince> shardy: I'm fine w/ it living in tripleo-ci. Once upon a time TOCI contained the initial devtest scripts anyways 14:39:23 <slagle> *use tripleo.sh 14:39:44 <derekh> slagle: they shouldn't, its a tool to help set up our dev environments 14:39:47 <trown> slagle: hmm... oh right it wont be packaged at all anymore 14:40:09 <derekh> rdo people should be following the docs 14:40:53 <trown> I was thinking of using it in the rdo 'quickstart', but I can actually workaround it not being packaged for that 14:41:34 <gfidente> I like the idea of not suggesting use of tripleo.sh to deployers; if deployers need it then we're probably doing something bad or too complicated for actual users 14:42:05 <shardy> gfidente: +1, it's primarily useful for developers wanting to replicate something close to what CI does 14:43:20 <dprince> #topic Specs 14:43:51 <dprince> thanks for the feedback on the composable roles spec shardy, jdob, jistr 14:44:16 <dprince> any other spec things to highlight this week? 14:44:18 <jdob> np, glad to see it moving 14:44:21 <tzumainn> heya - the API spec has been stuck with a bunch of +1s and a +2 for a few weeks now - any chance of getting a few additional eyes on it? 14:44:29 <shardy> dprince: np, FYI I was considering hacking out a ResourceChain based PoC when that is ready 14:44:33 <tzumainn> #link https://review.openstack.org/#/c/230432/ 14:44:43 <shardy> that doesn't necessarily need to gate what you are doing though 14:44:48 <haunted2> yeah 14:45:02 <jdob> tzumainn: i'll take a look 14:45:13 <jdob> i think i've been confusing that one with the other spec and ignoring it thinking I already read it 14:45:22 <haunted2> me too 14:45:32 <tzumainn> jdob, thanks! 14:45:42 <haunted2> yeah thanks jdob 14:46:34 <haunted2> how is everybody? 14:47:07 <dprince> any other specs to highlight this week? 14:48:37 <haunted2> I don't think so 14:48:55 <dprince> #topic Review Priorities 14:49:43 <trown> I thought we were moving this topic to open discussion? 14:49:53 <dprince> trown: we can do that 14:50:10 <dprince> trown: it was still on the agenda so I wanted to give one last shot 14:50:36 <dprince> #action dprince to remove review priorities from agenda 14:50:52 <trown> dprince: cool, since we have a bugs and a specs topic, it seems open discussion for any other reviews seems fine 14:51:09 <dprince> #topic open discussion 14:52:28 <slagle> well since no one brought anything else up... 14:52:34 <dprince> I've been looking at cutting the memory footprint in the undercloud 14:52:38 <dprince> https://review.openstack.org/#/c/250004/ 14:52:41 <shardy> One thing to mention - I heard reports that some folks had overcloud deletes which sometimes fail 14:52:45 <slagle> for the composable roles, do we want to go with what's posted, orw ait for the REsourceChain? 14:52:49 <slagle> i was just looking at the spec 14:52:53 <shardy> https://review.openstack.org/#/c/250498/ adds a simple CI test which tests that 14:52:57 <slagle> seems this is kind of up in the air 14:53:06 <slagle> and would be good to decide before landing the implementation 14:53:21 <dprince> shardy: we can disable Heats cloudwatch too right? 14:53:33 <shardy> dprince: yes, please do :) 14:53:50 <dprince> slagle: re. composable roles... I'm not sold on ResourceChain 14:54:05 <shardy> slagle: I'm not blocking on it, but I do think the manifest munging approach posted potentially makes things much harder to debug 14:54:06 <dprince> slagle: would like to sync with the spec reviewers on that idea 14:54:31 <shardy> seems dprince and I have a difference of opinion, so I'd like to hack out a PoC for evaluation as soon as jdob is done (no pressure jdob!) 14:54:46 <jdob> it should actually be working 14:54:48 <jdob> i have a patch posted 14:54:52 <jdob> i just havent written unit tests 14:54:57 <dprince> to me it is a matter of user interface. Do we want end users to be in control of where roles run, or let the role authors choose 14:55:01 <slagle> shardy: would using ResourceChains enable using the resource_registry to select the roles? 14:55:11 <shardy> however, if the consensus is +1 on the proposed approach, I'm happy to go with that 14:55:15 <jdob> but I think its in a state where you can try it and there's a 73% chance it won't cause your server to catch on fire 14:55:22 <dprince> I think I prefer the user to simply say: Enable glance-api on my controller nodes 14:55:33 <jdob> https://review.openstack.org/#/c/250010/ 14:55:34 <dprince> rather than say enable glance-api at step 3 14:55:43 <jdob> slagle: https://review.openstack.org/#/c/228615/ is the spec if you haven't seen it 14:55:46 <shardy> slagle: Yes, well you'd have a parameter which is defined in the environment 14:55:50 <shardy> not the resource_registry 14:55:57 <shardy> as in my example comments in the spc 14:55:58 <shardy> spec 14:56:05 <jdob> the spec is pretty finished if someone whose name rhymes with bsmarty would stop -1ing it 14:56:10 <shardy> jdob: great, I'll pull and test that later 14:56:24 <jdob> (i'm annoyed that "bsmarty" is the best I could come up with there, stupid 9am meetings) 14:56:25 <shardy> jdob: -1! ;) 14:56:37 <rhallisey> dprince, docker stuff with network isolation is working 14:56:47 <shardy> jdob: more seriously, it was only nits, the overall spec lgtm 14:56:51 <dprince> rhallisey: nice, thanks for the update 14:57:14 <rhallisey> dprince, I will be following up with a bunch of patches for the new template that will work with net-iso 14:57:19 <jdob> i know, thats why i'm giving you shit :) 14:58:03 <slagle> i'll have a look at the specs. the main thing i'd like to see is a way to define custom roles and it looks like the spec just lets you customize what services are on the still static roles (controller, compute, etc) 14:58:07 <shardy> dprince: we can chat, maybe there's a compromise which enables the simpler interface you mention without the manifest mangling I referred to 14:58:44 <dprince> shardy: ack, end user simplicity was what I was going for 14:58:57 <dprince> simple flexability 15:00:14 <dprince> thanks everyone 15:00:21 <dprince> #endmeeting