14:01:03 <dprince> #startmeeting tripleo
14:01:09 <tremble> o/
14:01:10 <openstack> Meeting started Tue Nov 24 14:01:03 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:10 <dtantsur> o/
14:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:13 <openstack> The meeting name has been set to 'tripleo'
14:01:53 <adarazs> hello o/
14:02:11 <derekh> hi all
14:02:22 <matbu> \o
14:02:24 <hrybacki> o/
14:02:40 <apetrich> o|
14:02:53 <shardy> o/
14:03:08 <akrivoka> hiya \o
14:03:23 <dprince> hello everyone
14:03:32 <dprince> #topic agenda
14:03:33 <dprince> * bugs
14:03:33 <dprince> * Projects releases or stable backports
14:03:33 <dprince> * CI
14:03:33 <dprince> * Specs
14:03:35 <dprince> * Review Priorities: https://etherpad.openstack.org/p/tripleo-review-priorities
14:03:38 <dprince> * one off agenda items
14:03:40 <dprince> * open discussion
14:04:01 <dprince> anything else to add to the agenda this week?
14:04:14 * dprince will try to make sure we get to open discussion sooner this week
14:04:21 <shardy> dprince: I added a one-off item to the wiki
14:04:29 <shardy> re stable branch approval process
14:04:57 <dprince> * Stable branch approval policy (shardy)
14:05:09 <dprince> shardy: ack, sorry missed it. (wiki is confusing sometimes)
14:05:17 <shardy> dprince: np :)
14:05:23 <dprince> okay, lets go
14:05:29 <dprince> #topic bugs
14:06:54 <dprince> looks like we had a breakage or two but things were fixed quickly last week
14:07:00 <dprince> anything to bring up of note?
14:07:42 <eggmaster> o/
14:07:59 <dtantsur> please don't use 'packagename.openstack.common' outside of
14:08:02 <dtantsur> packagename
14:08:06 <dtantsur> :)
14:08:20 <dprince> dtantsur: ack, we fixed that in tripleoclient this week
14:08:34 <dtantsur> yeah, just bringing visibility for people
14:09:06 <dprince> cool. lets move on... people can chime in later if needed on things
14:09:34 <dprince> #topic Stable branch approval policy
14:09:47 <dprince> shardy: you want to drive this one?
14:09:49 <shardy> #link https://wiki.openstack.org/wiki/StableBranch#Gerrit
14:10:28 <shardy> So, I wanted to suggest we (within common-sense) adopt the normal stable branch process, where for simple backports, one reviewer is enough, if the proposer is also a core on the the project
14:10:53 <shardy> e.g if it's just a simple clean backport
14:10:53 <dprince> shardy: makes sense to me, ++
14:10:59 <derekh> seems sane
14:11:09 <d0ugal> o/
14:11:27 <shardy> the CI still isn't quite there, but when it is, I'd like to make the backport process as low overhead as possible ;)
14:12:19 <slagle> sounds good to me
14:12:23 <bnemec> +1
14:13:16 <shardy> Ok then, that is all, thanks!
14:13:27 <slagle> assuming the masterpatch is already merged
14:13:41 <shardy> slagle: yup
14:13:47 <slagle> ok :)
14:13:59 <shardy> and anything with conflicts should probably have more than one reviewer ideally
14:14:18 <dprince> anything else this week related to stable branches, etc?
14:14:20 <shardy> e.g leave the Conflicts: line in the commit message
14:14:29 <dprince> #topic Projects releases or stable backports
14:14:43 <dprince> very similar to what shardy was just speaking about...
14:14:44 <shardy> dprince: no, other than sorry I still don't have the CI working, it's nearly there...
14:15:06 <slagle> i released os-cloud-config yesterday to address the blocking issue
14:15:48 <slagle> the issue being the ironicclient import
14:15:49 <dprince> slagle: this was the openstack.common exception issue?
14:15:52 <slagle> yea
14:15:56 <dprince> cool
14:16:24 <dprince> okay, I think we are good here then
14:16:27 <dprince> #topic CI
14:17:16 <dtantsur> CI question: do you folks plan on enabling tripleo-ci for inspector and IPA?
14:17:44 <dprince> dtantsur: you mean to actually run on those projects?
14:17:48 <dtantsur> yep
14:17:58 * derekh has nothing much on CI this week, spending time elsewhere lately
14:18:04 <dprince> dtantsur: we could I guess. probably not a bad idea
14:18:45 <derekh> dtantsur: My view would be we should if they agree to treat it as voting CI
14:19:16 <dtantsur> derekh, voting = as it is now? because it doesn't give V-1 now anywhere
14:19:58 <dtantsur> also do we have something on ironic as well?
14:20:04 <derekh> dtantsur: in tripleo we don't (unless there is a good reason) approve unless we got passing CI
14:20:08 <derekh> dtantsur: same thing
14:20:13 <derekh> with ironic
14:20:26 <dtantsur> could be a good thing to bring to the next meeting
14:20:39 <dtantsur> I remember tripleo-ci was pretty useful on ironic some time ago..
14:20:48 <derekh> if we add our job to ironic then they must not merge without a tripleo pass
14:20:57 * bnemec still wants tripleo-ci to actually vote
14:21:29 <dtantsur> I guess we could use standard first non-voting then voting procedure
14:21:38 <derekh> back when they had it (and fair enough it was unreliable), I got the sense people didn't actually look at the results much
14:21:52 <dtantsur> it was really unreliable ;)
14:22:06 <dtantsur> if we see it ususally passing, we're going to pay attention
14:22:21 <derekh> dtantsur: yes but most of the time it was unreliable BECAUSE people were merging breaking changes
14:22:37 <adarazs> I would like to have some opinion about the khaleesi based gate for tripleo projects that I'm working on.
14:22:41 <dtantsur> yeah, we're also to blame, I admit
14:23:05 <derekh> dtantsur: then we had to have a broken job for 3 days while we waited to get something reverted
14:23:06 <adarazs> 1) should it build packages on the fly with delorean or just copy the code in place? is there a preference?
14:23:06 <adarazs> 2) what kind of validation would you like to see? tempest? or just something more quick and simple?
14:23:20 <derekh> dtantsur:  anyways it wasn't just ironic, there are plenty of examples to go around
14:23:42 <dtantsur> derekh, fast-forwarding reverts is something we can do for ironic and IPA, and I can guarantee it for inspector ;)
14:23:45 <dprince> adarazs: would you mind sending an email to introduce this concept and ask these questions?
14:23:56 <adarazs> dprince: all right.
14:24:00 <derekh> dtantsur: so to answer your first question I'm all for adding it back, as long as people don't ignore it
14:24:00 * dtantsur have not heard about khaleesi based gate
14:24:14 <dtantsur> derekh, mind bringing it to the next ironic meeting?
14:24:24 <slagle> i think it's worth trying as long as the intent is for the job to eventually become voting
14:24:26 <adarazs> dtantsur: they don't exist (upstream) yet. but we rely on them for RDO.
14:24:36 <dprince> adarazs: cool. good questions just could potentially consume all of our meeting time.
14:24:42 <derekh> dtantsur: sure will do,
14:24:47 <dtantsur> thanks!
14:25:01 <shardy> adarazs: I think less duplication of effort between upstream/downstream CI is a great idea, a mail with details of your plan would be excellent
14:25:09 <shardy> e.g to openstack-dev
14:25:32 <dprince> shardy: yes, thanks for clarifying that
14:25:39 <adarazs> shardy, dprince: ack, I will explain myself in email better. :)
14:26:01 <dprince> okay, sounds like we might be getting back into some Ironic CI jobs...
14:26:27 * derekh will talk to the heat folks also
14:26:57 <dprince> cool.
14:27:01 <dprince> #topic Specs
14:27:44 <dprince> I would ask for feedback on the composable roles stuff again: https://review.openstack.org/#/c/245804/
14:28:30 <shardy> derekh: +1 for heat tripleo CI, we can bring it up at the heat meeting tho
14:28:49 <bnemec> Crud, I haven't reviewed any specs lately. :-(
14:28:52 <derekh> shardy: ack
14:28:54 <dprince> I'm keen to start knocking this stuff out soon... because we already have scaling issues
14:30:41 <dprince> any other specs stuff?
14:30:54 <dprince> I would really like to create a "split stack" spec too
14:31:02 <dprince> or perhaps co-author one w/ someone
14:31:41 <dprince> the idea of splitting the stack is appealing for several reasons: one of them being potentially huge for CI in that we could run overcloud provisioning jobs on normal infra hardware
14:31:41 <gfidente> dprince, "split stack" is about using external resources?
14:32:20 <dprince> i.e. running just a "heat overcloud-configuration" stack on normal cloud based servers... skipping the Ironic bit
14:32:21 <jistr> one stack for hw, 2nd stack for config?
14:32:26 <dprince> jistr: yes
14:32:39 <dprince> gfidente: using external resources is part of it, yes
14:33:28 <dprince> to me... the clean split for a potential faster running CI job, that could run on normal infra hardware is the most appealing part of this
14:33:35 <slagle> dprince: are the servers known to nova? or not known to nova at all?
14:33:57 <slagle> same question for heat
14:34:00 <dprince> slagle: we could try both, although probably not known
14:34:14 <dprince> slagle: heat would use a mocked server I think
14:34:24 <slagle> ok
14:34:35 <shardy> slagle: I think it has to be the dummy server approach atm, because the external_resource stuff hasn't yet landed in heat
14:34:37 <dprince> anyways, just wanted to highlight this idea which we spoke of at the summit.
14:34:40 <slagle> the "not known" use case is what i was going for with the deployed server template patch i put up
14:34:52 <shardy> slagle: I can see if we can get that moving again tho
14:35:04 <dprince> slagle: sure, that may be the first step if we get that working
14:35:18 <slagle> shardy: honestly, the case of the servers already being known to nova isn't as interesting to me personally
14:35:19 <shardy> I think asalkeld may have moved on to other things, so I can take a look at it if we need it
14:35:37 <slagle> i want the option of not having to "nova boot" anything
14:35:40 <shardy> slagle: ack, we can just pass the ID's and dummy them then
14:35:42 <slagle> that's the bit i like
14:35:53 <dprince> slagle: yes, that is what we all want I think
14:36:07 <slagle> dprince: definitely agree splitting the stack would make all of this easier
14:36:36 <shardy> slagle: I think all we need is a unique identifier per server, for the SoftwareDeployment we don't need the servers to be known to nova
14:36:47 <shardy> (as you've already proved IIRC?)
14:36:59 <slagle> shardy: yea, my patch actually worked
14:37:34 <shardy> slagle: Cool, that's the proof-of-concept then :)
14:38:09 <dprince> okay, perhaps lets move on for now. Maybe a few of us can continue to explore the split stack idea soon then
14:38:30 <dprince> #topic review priorites
14:38:37 <slagle> my ultimate goal here was/is to use Heat to configure the undercloud, w/o having to nova boot the undercloud
14:39:19 <dprince> slagle: sure, what I'm talking about is quite different with the overcloud, but the first step is the same I think
14:39:20 <gfidente> slagle, oh the chicken/egg problem which initially forced tripleo to the seed
14:39:42 <slagle> yea :), anyway, we can move on :)
14:39:45 <dprince> anyways, any reviews to highlight this week?
14:40:14 * dprince thinks we might should skip this section and just let people bring things up in open discussion again
14:41:14 * bnemec would love to get undercloud ssl merged
14:41:22 <bnemec> #link https://review.openstack.org/#/c/221885/
14:41:45 <bnemec> We've been using essentially this downstream for quite a while now.
14:42:21 <slagle> i'll have another look
14:42:36 * gfidente starred
14:42:42 <slagle> once we get it all merged (with the overcloud too), are we going to switch at least 1 ci job over to use ssl everywhere?
14:42:52 <bnemec> Yeah, that's the plan.
14:42:56 <slagle> cool
14:43:32 <bnemec> I think Juan and/or Mark were planning to do that once all the pieces are in place.
14:43:39 <gfidente> oh I wonder how are we doing with the basic nova/ping test in CI? marios?
14:43:48 <gfidente> is there a review for that?
14:44:06 <marios> gfidente: no i is somethign i have wanted to revisit but keep being pulled into other things
14:44:13 * bnemec points at https://github.com/openstack/instack-undercloud/blob/master/scripts/instack-test-overcloud again
14:44:20 <marios> gfidente: there is a review, but it was for the original plan to add to tripleo.sh
14:45:19 <marios> gfidente: like https://review.openstack.org/#/c/241167/ i started rewriting to a heat template. anyway, still to revisit as soon as possible
14:46:31 <dprince> okay, thanks for the updates. moving on
14:46:33 <jtomasek> o/
14:46:52 <dprince> #topic open discussion
14:47:08 <dprince> any other topics that need mentioning this week
14:47:29 <shardy> we didn't really reach consensus on the parameters/parameter_defaults thing on the ML yet, please respond if you have an opinion
14:47:43 <dprince> shardy: ack
14:47:53 <marios> gfidente: something like this http://paste.fedoraproject.org/287295/46736696/
14:48:18 <dprince> I posted an etherpad which organizes some patches to get us Mistral support:
14:48:21 <dprince> https://etherpad.openstack.org/p/tripleo-undercloud-workflow
14:48:56 <dprince> mostly puppet-mistral stuff... but it also gets us keystone v3 in the undercloud (which was required for mistral)
14:49:13 * dprince is interested in exporing mistral workflows for several things in TripleO
14:49:44 <bnemec> Yeah, I think we had talked about implementing some of the new API stuff in Mistral at some point.
14:50:50 <shardy> dprince: +1 on mistral, but I'd like to see it's usage made pluggable in tripleo-common if possible
14:51:31 <shardy> e.g folks keep talking about various tools in the workflow space, so it'd be nice to have a simple abstraction to enable supporting more than one
14:51:44 <dprince> shardy: that is one way to go about it I guess
14:52:43 <bnemec> Once we have an actual API we should be able to do whatever we want with the implementation behind it.
14:53:40 <dprince> shardy: I was actually wondering if simply using a mistral workflow (which already has an OpenSTack API) might supplant parts of our tripleo-common stuff altogether
14:54:12 <shardy> ack, I'm just worried about alienating operators who e.g prefer ansible or whatever, but mistral seems like a good move regardless and more aligned with the TripleO mission
14:54:51 <dprince> shardy: As for using tool-X I think we do need better integration with things like Ansible and the like
14:55:24 <dprince> shardy: but really.. I think that is perhaps just generating a hosts file with the relevant roles.
14:55:48 <dprince> shardy: one way to look at it perhaps
14:55:49 <shardy> dprince: yeah, maybe that use case ends up satisfied via the split stack thing
14:56:00 <shardy> anyway, something to think about
14:56:12 <dprince> shardy: yep, step at a time
14:58:20 <dprince> anything else this week?
14:59:37 <dprince> okay, thanks everyone
14:59:59 <dprince> #endmeeting