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