14:03:30 <dprince> #startmeeting tripleo
14:03:31 <openstack> Meeting started Tue Dec 15 14:03:30 2015 UTC and is due to finish in 60 minutes.  The chair is dprince. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:36 <openstack> The meeting name has been set to 'tripleo'
14:04:06 <dprince> #topic agenda
14:04:06 <dprince> * bugs
14:04:06 <dprince> * Projects releases or stable backports
14:04:06 <dprince> * CI
14:04:06 <dprince> * Specs
14:04:08 <dprince> * one off agenda items
14:04:11 <dprince> * open discussion
14:04:16 <akrivoka> hello!
14:04:31 <d0ugal> Hi!
14:04:43 * derekh is lurking while in another meeting
14:05:41 <dprince> I see there a few one off agenda items so lets leave time for those...
14:05:59 <jdob> o/
14:06:15 <dprince> #topic bugs
14:07:04 <dprince> we are currently dealing with several issues that block us from updating our DELOREAN_REPO_URL in ci
14:07:15 <dprince> I believe trown is tracking things here
14:07:18 <dprince> #link https://etherpad.openstack.org/p/delorean_master_current_issues
14:07:49 <dprince> trown, derekh: anything there that we need to talk about now?
14:08:18 <trown> dprince: I think the swift overcloud fix that merged has broken undercloud install
14:08:21 <derekh> dprince: nothing from me, havn't looked at it much this week
14:09:05 <dprince> trown: okay, weird. We shouldn't even have the ringbuilder module in the undercloud
14:09:33 <trown> dprince: if I manually apply that change to the swift puppet manifest, `openstack undercloud install` errors during puppet-stack-config
14:09:33 <dprince> trown: perhaps paste the error and link it into the etherpad so we can have a look...
14:09:48 <trown> dprince: will do after the meeting
14:10:07 <trown> dmitry is working on the IPA issue
14:10:51 <trown> ah... dprince I am not sure how we will have https://review.openstack.org/257550 pass CI
14:11:08 <trown> it relies on new openstackclient package that changed the behavior
14:11:58 <dprince> trown: perhaps we just coordinate it with bumping the DELOREAN_REPO_URL
14:12:19 <dprince> trown: like, have a WIP tripleo-ci job to demonstrate that it passes w/ the new URL, but we don't actually land the tripleo-ci fix.
14:12:24 <marios> o/ sorry late
14:12:25 <dprince> trown: I think that would be enough
14:12:35 <trown> dprince: ok makes sense
14:12:59 <trown> dprince: we will have to save that for last then, since it will not pass with new URL right now
14:13:35 <dprince> trown: sure.
14:14:12 <trown> ok I am good to move on... if anyone wants to help coordinate through that etherpad
14:14:36 <dprince> okay, I will follow up on that etherpad after this meeting
14:14:40 <adarazs> o/
14:14:55 <dprince> any other bugs stuff?
14:15:45 <dprince> #topic Projects releases or stable backports
14:18:39 <dprince> #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/082053.html
14:19:00 <dprince> steve gave a nice review of the status of the stable branch backports work there I think that should cover us this week
14:19:17 <dprince> other than that anything else?
14:20:07 <dprince> #topic CI
14:20:58 <dprince> CI is working again. We had an outage last Friday due to a puppet-mysql change
14:21:02 <dprince> #link https://bugs.launchpad.net/tripleo/+bug/1525314
14:21:02 <openstack> Launchpad bug 1525314 in tripleo "CI failing on undercloud connecting to MariaDB" [Critical,Triaged]
14:21:37 <dprince> That has been landed now, but the patch/fix looks like it didn't make it into the ticket there
14:23:59 <dprince> derekh: any other CI things this week?
14:25:54 <derekh> dprince: same problems we had last week are ongoing,
14:26:21 <derekh> dprince: should find time this week to figure them out (rh1 cloud instances erroring)
14:27:08 <dprince> derekh: okay, thanks
14:27:19 <dprince> #topic Specs
14:28:59 <dprince> tzumainn: hi, so on the TripleO API spec. do we mention anywhere about it being a prototype or anything. i.e. not necissarily a final form perhaps?
14:29:26 <tzumainn> dprince, let me double check
14:29:34 <dprince> tzumainn: specifically thinking about what might happen w/ Mistral, and or if we decide that we need more TripleO API calls or something
14:30:09 <dprince> tzumainn: just might be worth adding some verbage about this being sort of an exploratory effort, and while useful not necissarily a final state (yet)
14:30:17 <tzumainn> dprince, I do mention that the project as a whole may go in a different direction in the future, such as with Mistral - is that sufficient?
14:30:54 <dprince> tzumainn: maybe :). I'll ready it again and follow up on the review again.
14:31:03 <tzumainn> dprince, haha, okay, thanks!
14:31:21 <dprince> tzumainn: thanks for the adjustments you've already made last week
14:31:33 <tzumainn> no problem, I appreciate the reviews!
14:32:00 <slagle> what about CI coverage on the api?
14:32:13 <slagle> that might help tease out what direction we end up going
14:32:28 <slagle> by getting in CI it will naturally start showing up in people's development workflows
14:32:41 <d0ugal> That's a good idea.
14:32:50 <d0ugal> We would get it when the CLI uses the API, but that is some time away
14:33:11 <dprince> I would think we would want CI on any workflows we use (if possible)
14:33:17 <dprince> TripleO API, or not
14:33:39 <dprince> but ++ for CI on it as well
14:33:48 <tzumainn> yep, that makes sense, I think the spec mentions that as well
14:34:19 <slagle> right, but the GUI isn't under TripleO (yet?). and if CLI is some time away...
14:34:44 <slagle> my concern here is that means that api isn't really getting good coverage in a way that is consumable for tripleo devs
14:35:36 <dprince> slagle: right, the same problem as Tuskar basically
14:35:48 <slagle> exactly
14:37:12 <dprince> I think perhaps TripleO API will just have to rely on some extra functional tests until client side tools catch up
14:37:55 <d0ugal> I would be happy to help add CI support, it should be quite easy but I am unfamiliar
14:38:05 <d0ugal> (I am testing the API directly with curl anyway)
14:38:18 <d0ugal> unfamiliar with CI*
14:38:56 <dprince> okay, perhaps any other comments can go on the TripleO API spec review
14:39:13 <dprince> I'd like to leave time for the agenda items
14:39:39 <dprince> tzumainn: didn't we confirm people are okay not renaming 'tripleo-common' last week?
14:39:56 <tzumainn> dprince, yeah, I didn't re-add that topic... ?
14:40:09 <d0ugal> heh, I guess it was never removed.
14:40:35 <dprince> tzumainn: no worries, I thought I rememberd it
14:40:37 <dprince> okay
14:40:54 <dprince> #topic swift storage for tripleo-heat-templates
14:41:00 <dprince> d0ugal: this is you right
14:41:04 <d0ugal> dprince: Yup
14:41:07 <dprince> Is Swift the best storage for the t-h-t? Concerns about dealing with 100+ related files without transactions
14:41:28 <dprince> d0ugal: what if we use a tarball?
14:41:44 <d0ugal> This may work better as an email, but I wanted to raise the subject here
14:41:57 <d0ugal> dprince: That could well work, so we are just dealing with one file.
14:42:26 <dprince> d0ugal: right, but the API would have to expand it (or cache it) to be able to read it each time
14:42:26 <d0ugal> The general issue is that to make Swift work well for t-h-t we need to do batch operations
14:42:45 <jtomasek> doude: how would that work, what if we need to set metadata only for certain set of files in some of the steps?
14:43:02 <d0ugal> dprince: I guess we would still have an issue with multiple requests updating the tarball at the same time
14:43:35 <d0ugal> jtomasek: We wouldn't use swift's metadata, we would have to use our own? Which isn't ideal
14:43:56 <rbrady> the tarball doesn't solve the original problem and degrades the user experience
14:44:11 <d0ugal> This review is a good example: https://review.openstack.org/257481
14:44:24 <d0ugal> It essentially does a manual rollback, doing that concerns me
14:44:34 <jtomasek> how about plain old database instead of swift? is that an option?
14:44:47 <d0ugal> jtomasek: We did that for Tuskar, it wasn't popular for various reasons.
14:44:59 <jtomasek> yep
14:45:21 <d0ugal> I don't know if the Glance Artifact change happened, that was a candidate and they were promising some features to do with related files
14:45:29 <dprince> d0ugal: could be a backend, Mysql, Swift
14:45:30 <d0ugal> or related assets I think I should say
14:45:48 <slagle> i'm not sure what the exact issue is, but git was floated as an altenative to Swift. is that still relevant?
14:46:16 <d0ugal> slagle: In https://review.openstack.org/257481 we need to create a container and add the files for a plan. If we have an issue somewhere we have a half created plan.
14:46:18 <dprince> wouldn't glance potentially store its artifacts in swift as well. Like if we enabled the Glance swift backend
14:46:32 <d0ugal> dprince: Oh, maybe. I didn't know what.
14:46:49 <d0ugal> Multiple backends would be a reasonable option, it should be quite easy, but I would be concerned about supporting them all.
14:47:51 <d0ugal> Another example with the current code, if somebody uploads a new plan and somebody else deploys at the same time you could end up deploying half old and new
14:48:10 <d0ugal> because the changes are not atomic
14:48:31 <dprince> d0ugal: for deployment it sounds like you need a staging area that is part of the "Transaction"
14:48:53 <gfidente> guys, pardon the stupid question but, does this mean we'll end up installing a copy of the templates in /usr and deploy from another source?
14:49:08 <dprince> d0ugal: or, you lock it via a locking mechanism to prohibit uploads during deployment
14:49:26 <d0ugal> dprince: yup, I had wondered about locking
14:49:45 <jtomasek> gfidente: basicaly yes, beacause non-cli clients have no means to access files in the filesystem
14:49:53 <dprince> d0ugal: it is a long lock to hold!
14:49:53 <d0ugal> There are ways to make this work, but we will always be creating our own database on swift. is that a good idea?
14:50:23 <gfidente> jtomasek, do the non-cli clients *need* access to the files?
14:50:26 <jdob> this discussion sounds oddly familiar :)
14:51:23 <d0ugal> Since there don't seem to be any obvious answers, it might be best to take this to openstack-dev?
14:51:28 <gfidente> jtomasek, is it the client going to do the heat POST or the tripleo-common ?
14:51:53 <jtomasek> gfidente: good point it is a tripleo-common at the moment
14:51:57 <d0ugal> I've got a few scenarios where I think we will have issues :)
14:54:18 <d0ugal> dprince: I think that's probably all I've got for now :)
14:54:42 <dprince> d0ugal: thanks, let us know how it goes
14:54:43 <d0ugal> Swift is working fairly well as a POC for the API, but I am not sure how viable it is beyond that.
14:55:03 <dprince> #topic open discussion
14:55:34 <d0ugal> One general question, should we formally deprecate Tuskar?
14:55:57 <dprince> d0ugal: vs, just remove it?
14:56:03 <d0ugal> dprince: or do that
14:56:15 <d0ugal> vs leaving it and doing nothing which I think is the current state
14:56:18 <d0ugal> :)
14:56:39 <dprince> d0ugal: I'm fine removing it if it is no longer used
14:56:52 <d0ugal> I don't think it is. I'll ask on openstack-dev about that too
14:56:58 <dprince> cool
15:00:01 <dprince> I think that is it for this week
15:00:06 <dprince> thanks everyone
15:00:19 <d0ugal> Thanks!
15:00:21 <jdob> \o
15:00:24 <derekh> ty
15:00:29 <dprince> #endmeeting tripleo