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