#openstack-meeting-alt log

14:01:29 <dprince> #startmeeting tripleo
14:01:30 <openstack> Meeting started Tue Oct  6 14:01:29 2015 UTC and is due to finish in 60 minutes.  The chair is dprince. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:31 <slagle> gfidente wants his hello to be recorded
14:01:33 <trown> o/
14:01:34 <openstack> The meeting name has been set to 'tripleo'
14:01:39 <dprince> hello
14:01:40 <rhallisey> hi
14:01:44 <d0ugal> hi bot
14:01:45 <tzumainn> hiya
14:01:57 <shardy> o/
14:01:59 <rbrady> hey
14:02:00 <derekh> yo
14:02:01 <jdob> did tzumainn just admit to being a bot?
14:02:09 <gfidente> slagle, was super-happy of the new timeframe actually :)
14:02:15 <tzumainn> this is srs bzns jdob, stop messing around
14:02:23 <dprince> ++ for the new meeting time
14:02:37 <marios> jdob: motion to ban tzumainn from all openstack-* chans
14:02:43 <jdob> +2
14:02:47 <tzumainn> D:
14:02:50 <akrivoka> hello \o
14:03:12 <jistr> o/
14:03:42 <dprince> okay, so to shake things up I've gone and messed w/ the agenda (feedback welcome)
14:03:48 <dprince> #topic agenda
14:03:48 <dprince> * bugs
14:03:48 <dprince> * reviews (optional)
14:03:48 <dprince> * Projects needing releases (optional)
14:03:48 <dprince> * CI
14:03:50 <dprince> * Specs (optional)
14:03:53 <dprince> * one off agenda items
14:03:55 <dprince> * open discussion
14:04:28 <dprince> the idea was to skip (or optionally skip) some of the sections to give us more time on other things
14:05:05 <dprince> basically, releases aren't that useful to us ATM. We will still do them but as we use Delorean trunk for most things they aren't as important
14:05:27 <dprince> things like setup-clienttools, etc used to require us to do releases often...
14:06:09 <florianf> hello everyone...
14:06:21 <trown> releases are nice if we want to have "stable" packages ie non-delorean packages
14:06:57 <shardy> It'd be interesting to thing about what we might support wrt the release branch too
14:07:11 <dprince> trown: sure, but this isn't a stable release branch thing
14:07:32 <dprince> trown: we previously had a "releases" section in our agenda because we relied on trunk releases to use the latest things
14:07:45 <trown> ah ok
14:07:49 <dprince> shardy: as for stable branch testing I think that is a different thing
14:08:05 <trown> stable release branch could also have delorean packages fwiw
14:08:11 <dprince> and as for releasing things to pypi we still want/need to do that, perhaps just not as often
14:08:27 <shardy> dprince: Yup, was just mentioning we might take a more release centric approach there, +1 on removing the recurring item
14:08:29 <dprince> shardy: Delorean stable builds would cover us
14:08:45 <shardy> dprince: Ok, thanks
14:09:03 <dprince> okay so reviews, rather than talk about metrics (which are still important sometimes but we seem to be doing okay) I added a new review highlights section for things that seem of interest recently (came up on the mailing list ,etc)
14:09:34 * dprince promises not to only list *his* patches in this section
14:10:13 <dprince> anyways, best to get on with things, perhaps feedback on the agenda can follow in #tripleo
14:10:16 <marios> dprince: may be worth noting anyone can add to the agenda. egafford was just asking about the sahara patches in the chan earlier
14:10:28 <shardy> dprince: I've got a couple of pending ExtraConfig ones I'd like to see land:
14:10:31 <shardy> https://review.openstack.org/#/q/status:open+project:openstack/tripleo-heat-templates+branch:master+topic:node_extraconfig,n,z
14:10:37 <dprince> marios: correct, anyone can add items here
14:10:38 <shardy> #link https://review.openstack.org/#/q/status:open+project:openstack/tripleo-heat-templates+branch:master+topic:node_extraconfig,n,z
14:10:45 <dprince> #link https://wiki.openstack.org/wiki/Meetings/TripleO
14:11:08 <dprince> shardy: noted,
14:11:15 <shardy> dprince: I think having a "priority" reviews section, or maybe etherpad is a good idea
14:11:26 <derekh> shardy: +1
14:11:44 <shardy> we do the same for heat (etherpad) and it's worked well to help focus reviewers attention, particularly close to releases
14:11:49 <dprince> shardy: cool, perhaps an etherpad would work too
14:11:52 <marios> yeah +1 to having a agenda item for this. we remove/skip when it isn't useful
14:12:32 <dprince> okay so bugs
14:12:34 <dprince> #topic bugs
14:12:53 <dprince> any pending issues to bring up w/ bugs
14:13:05 <dprince> derekh: you've been squashing some DIB regressions...
14:13:25 <derekh> dprince: yup
14:13:27 <derekh> most of last weeks ci failures were caused by bugs in 2 find commands
14:13:32 <marios> dprince: so was that the review highlights section done with (sorry, i am confused. are we discussing those reviews ?)
14:13:35 <derekh> Fix merged for the first https://review.openstack.org/#/c/230202/
14:13:45 <derekh> patch for the second here, https://review.openstack.org/#/c/230448/ <-- have yet to look at the -xdev suggestion, probably wont have time for a day or 2 so if anybody else wants to fire ahead
14:13:46 <dprince> marios: it is later
14:13:56 <egafford> If there are extant issues on the Sahara pathes, that
14:14:07 <marios> dprince: k thx
14:14:08 <egafford> that'd be great to know. :_
14:14:24 <egafford> (Sorry; double-meetings at the moment. Typing is failing me.)
14:14:35 <dprince> derekh: okay, thanks, will try to look at those
14:14:37 <marios> egafford: we have an agenda item for discussion of those reviews in a bit (including the sahara patches)
14:15:02 <dprince> slagle, bnemec: any update on https://bugs.launchpad.net/tripleo/+bug/1492416
14:15:02 <openstack> Launchpad bug 1492416 in tripleo "Apache fails to start, .HorizonScssFilter: command not found" [Critical,Triaged] - Assigned to James Slagle (james-slagle)
14:15:12 <dprince> that would allow us to re-enable Horizon right?
14:16:58 <slagle> dprince: yes, as long as it's fixed in delorean as well
14:17:27 <slagle> i guess we could try re-enabling horizon
14:17:35 <slagle> for what purpose though?
14:17:35 <dprince> slagle: cool, would be nice to push this through soon (Horizon has been down for weeks I think)
14:17:54 <dprince> derekh, gfidente: do we have any bugs filed on what is causing the HA job failures?
14:17:55 <trown> we have delorean pinned pretty far back for non-tripleo packages
14:18:20 <trown> we can talk more about that in the CI agenda though
14:18:23 <derekh> trown: I updated the pin on saturday, we're about a week old
14:18:23 <dprince> trown: derekh just pushed this https://review.openstack.org/#/c/229789/
14:18:31 <trown> oh, nice one
14:18:56 <slagle> dprince: is horizon disabled in the overcloud too?
14:19:07 <slagle> i didnt know there was a way to do that
14:19:08 <shardy> slagle: I gave a TripleO demo today, and it would've been nice to show "look, deployed openstack" by loading horizon at the end ;)
14:19:28 <derekh> dprince: ya, that failed for some reason, havn't looked at why yet, back to conference after meeting so wont have a chance today
14:19:59 <dprince> slagle: there isn't, cherry pick this https://review.openstack.org/#/c/219697/
14:20:26 <dprince> slagle: I think I'm out of date on this
14:20:36 <slagle> dprince: that looks like it is disablign it
14:20:41 <slagle> i'm asking if it's already disabled
14:20:44 <slagle> i don't think it is
14:20:55 <shardy> slagle: Oh, I assumed it was disabled in the overcloud, I tried to access it and it didn't work
14:20:56 <dprince> slagle: okay, let (me) follow up on this later
14:21:23 <dprince> slagle: just wanted to ask about the status as I haven't been able to use Horizon for a bit
14:21:41 <dprince> using trunk packages, etc.
14:21:51 <dprince> any other bugs to mention?
14:22:27 <derekh> dprince: RE: HA failures
14:22:29 <derekh> HA job is now passing 1/2 the time, we need to look at why it fails the other 1/2, looks like an issue with signals from postdeployes getting to heat, I'm going to get some more info so shardy can take a look,
14:22:42 <derekh> the ceph job may also be experienceing the same problem, not sure
14:22:50 <derekh> it would be nice if people could try not to break it in the meantime
14:23:11 <derekh> I had to track down 3 seperate problems to get it back working
14:23:18 <dprince> derekh: ouch
14:23:54 * gfidente trying to get it up on centos still
14:24:05 <dprince> derekh: any bug link for that issue?
14:24:48 <derekh> dprince: not yet, gattering info at the moment, will create one
14:24:55 <dprince> derekh: great, thanks
14:24:57 <jistr> locally i sometimes get 400 response from Heat when reporting events from instances, heat saying "i don't recognize the resource"
14:25:04 <jistr> not sure if that's the same in CI though
14:25:19 <shardy> jistr: that's the same issue, can you note how you reproduce please?
14:25:27 <dprince> jistr: hmmm, interesting
14:25:36 <shardy> if you raise a bug, mark it as affecting heat and assign the heat part to me
14:25:46 <shardy> I'll be able to take a look tomorrow
14:25:47 <jistr> shardy: just an HA deployment, though it doesn't happen always
14:25:51 <dprince> jistr, derekh: are you guys using trunk Heat? or an older Delorean?
14:25:55 <jistr> shardy: ack
14:25:58 <jistr> will do
14:26:15 <jistr> dprince: i think an older delorean
14:26:32 <jistr> i'm using what the docs had about ~3 weeks ago i think
14:26:33 <derekh> dprince: anybody using tripleo.sh is using heat from Oct 1st
14:26:47 <dprince> jistr: might be worth trying a newer Heat too
14:27:01 <jistr> ack
14:27:06 <dprince> derekh: ack, that is probably recent enough
14:27:10 <dprince> okay, moving to CI
14:27:16 <dprince> #topic CI
14:27:25 <derekh> dprince: assuming they ran repo-setup after saturday
14:27:42 <dprince> derekh: cool. good to know
14:27:42 <derekh> I was going to talk about the HA job here but already have ....
14:27:52 <dprince> derekh: okay, any other updates
14:27:59 <trown> I am a bit confused by our repo strategy in the CI
14:28:01 <dprince> derekh: things seem like they are improving
14:28:17 <dprince> trown: the layered approach I call it
14:28:20 <trown> https://review.openstack.org/#/c/229789/5/toci_gate_test.sh moves to a mitaka repo for core
14:28:30 <derekh> nope, I *think* most of our intermitent ci falures latly are due to our own code
14:28:49 <trown> shouldnt we get tripleo working on liberty core first?
14:28:54 <derekh> dprince: yup, things have improved since pinning all the morrirw
14:28:58 <derekh> *mirrors
14:29:10 <marios> derekh: was that a heavy irish accent
14:29:31 <derekh> marios: yup, I'm from the whest of ireland
14:29:32 <dprince> trown: for upstream CI we general want to follow upstream
14:29:53 <dprince> trown: there is talk of "stable" branch testing too, and that is where liberty could plug in upstream
14:30:10 <marios> derekh: fwiw, have been following https://review.openstack.org/#/c/201398/ and the f21-puppetha job hadn't passed before today
14:30:13 <dprince> trown: but our trunk jobs should still follow the latest unreleased code I think
14:30:16 <shardy> trown: I think we have to agree the stable/release branch stuff first
14:30:27 * shardy was about to mention that in the specs topic ;)
14:30:31 <trown> my understanding of the stable branch spec was for a stable branch of tripleo
14:30:45 <dprince> shardy: we are skipping specs this week ;)
14:30:54 <shardy> trown: Yes, and it's those branches which will support liberty, the stable branches of all the services
14:31:07 <shardy> dprince: ha, thanks! ;)
14:31:08 <derekh> marios: thats probably correct I only got it passing 50% at the weekend
14:31:13 <dprince> okay any other CI biz
14:31:20 <trown> ok ... so tripleo no longer supports liberty (until that is set up)
14:31:28 <shardy> trown: so, master tripleo supporting master/mitaka is right IMO
14:31:43 <trown> ok makes sense
14:31:45 <derekh> yup, we only have ci for master of all of the things
14:31:51 <derekh> and need to set up a liberty job
14:31:59 <shardy> trown: exactly, which is why I really want to see the release branch model adopted
14:32:22 <trown> I am working on RDO CI for liberty so that will work in the interim
14:32:27 <dprince> yep, release branch testing would be nice
14:32:46 <shardy> trown: cool, that's good to know
14:32:55 <dprince> okay, lets move to review highlights
14:33:03 <trown> but it would be nice to have stable branches in tripleo to build delorean from
14:33:08 <dprince> #topic review_highlights
14:33:40 <dprince> * https://review.openstack.org/#/c/209505/ (Docker compute)
14:33:40 <dprince> * https://review.openstack.org/#/c/188137/ (Manila integration)
14:33:40 <dprince> * https://review.openstack.org/#/c/220863/ (Sahara integration)
14:33:40 <dprince> * https://review.openstack.org/#/c/219927/ (os-net-config linux bridge)
14:33:40 <marios> egafford: we are talking about the review highlights now fyi
14:33:43 <dprince> * https://review.openstack.org/#/c/218134/10 (os-net-config linux bonding)
14:33:52 <egafford> marios: Yes!
14:34:06 <shardy> trown: I'll revise https://review.openstack.org/#/c/221811/ to address dprince's wording concerns, then look at how we go ahead and create the branches
14:34:09 <marios> dprince: are you taking these in order? or speak now or forever hold your peace
14:34:18 <dprince> shardy: ++
14:34:53 <dprince> I know shardy has already spent some time on the Docker compute role. I would really like to see us push and land that before Tokyo
14:34:58 <dprince> https://review.openstack.org/#/c/209505/
14:35:03 <shardy> dprince: So, related to my ML thread, I'm really happy to see $new_stuff getting integrated, but is there an easy way to make it optional?
14:35:18 <dprince> There is an associated spec that outlines the approach too, so both of those.
14:35:31 <shardy> Like, it's great to see Sahara and Manila, but personally I don't have the resources to deploy much more in my test environment
14:35:38 * shardy requests moar RAM
14:35:41 <dprince> shardy: I think we have two choices: use a parameter or use the resource registry
14:35:51 <rhallisey> dprince, I was having issues with new delorean repos, but trown helped me get past it so I should see if that rabbitmq issue is still there
14:35:59 <rhallisey> I don't think it will be though
14:36:00 <dprince> shardy: your suggestion to use parameter_groups makes me happier about the parameter approach
14:36:08 <dprince> shardy: but that isn't really "composition"
14:36:28 <shardy> dprince: Yeah, for this I think I prefer parameter, at least until we move away from the monolithic controller
14:36:38 <marios> shardy: for manila at least, there is an env. file you have to use, otherwise nothing is enabled. actually this sets the resource registry to include the 'new_service_config'
14:36:40 <shardy> dprince: Yeah, but the controller isn't really composable yet
14:36:56 <shardy> if using the resource_registry enables a step towards that, we can do that
14:37:12 <shardy> I just want a simple way to keep my test deployment fairly small/minimal
14:37:16 <marios> shardy: does it have to be parameter? just having an environment file to enable extraconfig for example like manila @ https://review.openstack.org/#/c/188137/
14:37:17 <dprince> shardy: correct, if we were to move in that direction I think we'd do a few more things with the resource registry
14:37:44 <shardy> marios: honestly I don't mind that much, I just want *a* way to disable things
14:37:49 <egafford> I saw a recent change to move keystone endpoints into puppet; that would definitely be handy to ensure that services can be disabled safely (without leaving cruft around from puppet/heat external processes.)
14:37:49 <marios> right
14:38:54 <dprince> marios: a parameter doesn't hurt much but we might not like exactly how they scale, thus the parameter groups may make things happier to be able to control/group top level params
14:39:17 <thrash> egafford: can you point me at that change?
14:39:30 <dprince> shardy: perhaps we should default these to disabled?
14:39:40 <d0ugal> thrash: https://review.openstack.org/#/c/231395/
14:39:54 <jdob> related to param v. resource registry, at what point do we consider THT to be an API that has to support backward compatibility?
14:39:55 <d0ugal> thrash: https://review.openstack.org/#/c/230375/
14:39:58 <marios> dprince: ok. for the manila at least it is being enabled on the controller (so scales with i guess) but i get your point
14:40:07 <thrash> d0ugal: so that's just the removal of that code. OK.
14:40:12 <jdob> this might be too big of a question for this meeting, but if we throw a param in now, are we then going to support it for X amount of time?
14:40:13 <marios> dprince: oh you mean having many scale params
14:40:18 <shardy> dprince: possibly, I guess it depends on the CI time impact, but then the question becomes how we prove they stay working
14:40:38 <bnemec> jdob: I would argue that they already are, and we should be.
14:40:56 <jdob> i kinda agree, in which case this decision of param v. registry is a pretty big ass deal
14:41:02 <jdob> (not sure why I had to specify "ass" there)
14:41:05 <dprince> jdob: yeah, that is my reservation about parameters
14:41:35 <bnemec> I think we need deprecation functionality for params like oslo.config has for config opts.
14:41:48 <dprince> bnemec: ++
14:41:50 <jdob> we'll likely need to address that before composable roles/containers
14:41:53 <bnemec> Not that that helps us right now.
14:41:56 <dprince> bnemec: but that is a Heat feature
14:41:56 <shardy> jdob: I'va always assumed the top-level parameters (in overcloud-without-mergepy) are "public", and that we can't break/rename any of the "ExtraConfig" related interfaces
14:42:16 <shardy> but we need to properly define/document exactly what is stable really
14:42:27 <jdob> we do, since we have docs around setting param_defaults
14:42:32 <jdob> but this is too deep for this meeting
14:42:36 <jdob> glad everyone has it on their mind
14:42:39 <jdob> and we can address on the ML
14:42:52 <derekh> _parameter
14:42:52 <shardy> jdob: I would prefer it if we never suggested parameter_defaults except for *ExtraConfig stuff
14:43:04 <dprince> I would like to see someone model how we'd do this with the resource registry
14:43:06 <jdob> net isolation needs it
14:43:08 <shardy> jdob: that makes it clear, don't mess with "core" template nested parameters
14:43:19 <shardy> jdob: hmm, good point
14:43:36 <dprince> also, perhaps the core devs involved could help iterate on these patches too (if the patch developers are okay w/ that)
14:43:38 <shardy> oh well, perhaps another spec to work out the definition of the stable interfaces?
14:44:01 <shardy> I can propose one unless anyone else is keen, or just a docs patch
14:44:06 <shardy> then we can iterate from there
14:44:12 <marios> dprince: to be clear are we going to wait on that discussion (param vs resource reg.) before landing those?
14:44:40 <dprince> marios: we should I think. Moving the discussion along was why I added these reviews here
14:44:56 <jdob> you're talking about landing sahara/manila?
14:45:13 <marios> jdob: yeah, hope so
14:45:30 <egafford> thrash: https://review.openstack.org/#/c/231395/
14:45:32 <jdob> sorry, lemme rephrase: you're suggesting not landing those until we have that param v. resource discussion
14:45:34 <jdob> ?
14:45:36 <dprince> jdob: yes, we want to land those... not necissarily as-is but once we agree on the best approach to use (params vs. registry)
14:45:43 <thrash> egafford: got it. thanks.
14:45:43 <jdob> ok, gotcha
14:46:00 <marios> dprince: slight side issue, regardless of method
14:46:17 <marios> dprince: on manila patch (i sent to mailing list about this) @ https://review.openstack.org/#/c/188137/
14:46:33 <gfidente> personally, the good thing I found about _defaults is that we can add new params which are only used by a specific resource type
14:46:37 <marios> dprince: when not enabled, do we still expect the packages for that service to be installed?
14:46:50 <gfidente> and only add them in the _defaults part when needed
14:47:06 <shardy> marios: that's not ideal, but probably not a blocker IMO
14:47:09 <dprince> marios: a couple of options there
14:47:11 <marios> dprince: on that review, in the overcloud_controler_pacemaker.pp manila imports happen, outside the 'if manila' conditional,
14:47:24 <dprince> marios: there is an EnableInstallPackages option that you could use (we don't use this for CI)
14:47:25 <jdob> marios: specific to RH, everything I've heard makes it sound like we're cool with beefier images and stuff disabled on them
14:47:29 <jdob> for what its worth
14:47:40 <dprince> marios: but without that we would require it to be install if the Manila feature is enable
14:48:18 <dprince> marios: we could create an isolated element to install just manila (and sahara) or just add it to our "controller" role I guess as a default/always on feature
14:49:16 <marios> dprince: yes but the question was about the expectation that manila-* packages are installed or not
14:49:31 <dprince> marios: I'd be fine installing them I think
14:49:51 <marios> dprince: i.e. if i just deploy vanila, and not having manila on the image, but the heat templates assume this is installed
14:50:13 <dprince> marios: if they are there, it is easy to enable them on the fly
14:50:15 <marios> dprince: ok, so then we are saying that for any new service, we will always include the packages in the overcloud-full built by tripleo tooling
14:50:34 <marios> dprince: yes i am mainly looking for clarity here and grateful for this discussion.
14:50:37 <jdob> personally, I'm fine with that
14:50:42 <marios> jdob: shardy thanks
14:50:46 <dprince> marios: I think we have to do this for our CI, so yes
14:50:47 <jdob> if someone needs a cleaner/thinner image, they can build it
14:50:56 <dprince> marios: CI doesn't allow us to "install on demand"
14:51:05 <marios> jdob: except would fail here
14:51:08 <marios> jdob: that is my point
14:51:12 <shardy> beyond a certain point that does have performance implications tho (longer to deploy bigger image)
14:51:13 <marios> jdob: if you build image without manila
14:51:21 <marios> jdob: and usse those tht form that review it will fail
14:51:27 <marios> jdob: because it assumed manila packages installed
14:51:30 <jdob> er, sorry. i was assuming our THT handled that situation properly
14:51:31 <dprince> we may need to revisit this if images get too large at some point
14:51:55 <marios> jdob: no, see my comments on v30
14:51:56 <dprince> but all OS services have a somewhat similar common base so I think we should be okay for these 2 new patches
14:52:04 <shardy> dprince: +1
14:52:06 <marios> jdob: lets talk after if u like
14:52:26 <jdob> marios: we can, but I do see what you're saying, I'm just not correctly saying what i'm thinking
14:52:36 <marios> dprince: my point is with something like the n1kv patches at https://review.openstack.org/#/c/201398/
14:52:52 <marios> dprince: all the configu of the service is done inside an 'if enabled' conditional
14:53:26 <marios> dprince: but for manila review it isn't the case. but ok, enough discussion for now sorry, eating up the hour
14:53:34 <marios> thanks for the discussion.
14:53:44 <dprince> marios: that is an option, although if we can figure out better "composability" by actually trying to use the resource registry as a mechanism for this I'd like to see what is possible
14:54:46 <dprince> marios: we've got patterns, and we can repeat them for this... but I'd like to consider modeling this in a new fashion that might require a bit of restructuring
14:55:04 <dprince> marios: lets talk more on the list and in #tripleo...
14:55:10 <marios> sure thanks
14:55:21 <shardy> In future we might use ResourceChains as proposed by jdob for this https://review.openstack.org/#/c/228615/
14:55:45 <dprince> shardy: thanks
14:55:55 <shardy> inside the resource group you could chain together the services to be enabled/deployed via their respective resource_registry aliases
14:55:55 <dprince> last two patches to mention I wanted to mention were two os-net-config ones
14:56:00 <dprince> * https://review.openstack.org/#/c/219927/ (os-net-config linux bridge)
14:56:03 <dprince> * https://review.openstack.org/#/c/218134/10 (os-net-config linux bonding)
14:56:37 <dprince> I think jdob and I have already reviewed them... but it would be nice to push those forwards soon as generally nice new features there
14:56:56 <jdob> now that we have the follow ups that fix the python, I need to re-review and will likely add +1
14:57:17 <dprince> okay, sorry for the lack of time, but any other open agenda items that need mentioning?
14:57:22 <jdob> i dont remember any other issues with it, short of the fact that I'm not 100% confident i understand the specifics of what it's doing to add a +2
14:58:01 <dprince> jdob: totally fine, would be nice to actually try these first perhaps too since CI doesn't cover it
14:59:41 <dprince> okay, well thanks everyone for coming. Lots of good discussion and things going on
14:59:56 <d0ugal> dprince: Thanks!
15:00:10 <marios> o/ derekh slow clap once again for moving the meeting
15:00:19 <derekh> lol
15:00:23 <dprince> #endmeeting