14:00:18 #startmeeting tripleo 14:00:18 Meeting started Tue Jul 18 14:00:18 2017 UTC and is due to finish in 60 minutes. The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:20 Ronelle Landy proposed openstack-infra/tripleo-ci master: WIP: Add settings for ovb in rdocloud https://review.openstack.org/480950 14:00:21 The meeting name has been set to 'tripleo' 14:00:27 #topic agenda 14:00:34 * review past action items 14:00:36 * one off agenda items 14:00:38 * bugs 14:00:40 * Projects releases or stable backports 14:00:42 * CI 14:00:44 * Specs 14:00:46 * open discussion 14:00:48 Anyone can use the #link, #action and #info commands, not just the moderatorǃ 14:00:50 hello, who is around today? 14:00:56 hi2u 14:00:57 hello 14:01:09 hi 14:01:11 o/ 14:01:12 hi 14:01:23 o/ 14:01:30 nice one on the meetbot EmilienM will it do all the logging as usual? 14:01:31 o/ 14:01:37 o/ 14:01:39 marios: yup 14:01:56 #topic review past action items 14:02:04 gfidente & EmilienM to figure out where if whether or not we package ceph-ansible in RDO: not sure about status 14:02:08 o/ 14:02:20 gfidente to add ceph-ansible to multinode-scenario001-container job: postponed (par of the agenda today) 14:02:27 hello 14:02:29 sshnaidm to add missing oooq jobs in oooq-extras which are already gating somewhere in tripleo: done! 14:02:44 gfidente: any update on ceph-ansible packaging? 14:03:46 hi 14:03:47 o/ 14:03:50 o/ 14:03:52 let's move around the next topic is with gfidente too 14:03:53 #topic one off agenda items 14:03:59 #link https://etherpad.openstack.org/p/tripleo-meeting-items 14:04:07 o/ 14:04:11 gfidente: you around to discuss about ceph-ansible? 14:04:49 ok, let's move forward 14:04:55 numans: please go ahead! 14:05:14 hi, nothing much to discuss 14:05:24 just requesting to review some of the OVN patches 14:05:47 o/ 14:05:48 numans: great - any progress on testing it? 14:06:23 EmilienM, for this review - https://review.openstack.org/#/c/483492/, I have used another patch to test it https://review.openstack.org/#/c/483494/ 14:06:25 numans: plus, both patches don't pass OVB, not sure our reviewers will +2 right away 14:06:34 o/ 14:06:48 EmilienM, I will have a look into that. 14:07:03 * gfidente o/, we can get to it later 14:07:07 numans: it would be great to make progress on the scenarios, to have permanent ovn testing coverage 14:07:13 gfidente: ok 14:07:29 EmilienM, right. I am just waiting to see if i can use scenario005 14:07:56 numans: i think scenario005 will keep composable HA architecture, so go ahead and create scenario007 I think 14:08:00 after which i will submit the patch in t-h-t to use it based on the discussion we had yesterday 14:08:11 EmilienM, ack. 14:08:19 numans: I don't think we should, see my last reply on openstack-dev (yesterday) 14:08:37 numans: scenario005 consumes 2x more than a classic multinode in term of infra resources 14:08:39 i missed it, i will have a look 14:08:42 I'm not sure we want that 14:08:44 ok good 14:08:56 numans: let's have scenario007 in place this week, finally 14:09:03 so we can have ovn coverage 14:09:06 sure. Will do that 14:09:15 numans: I can help to setup things, just ask me/ping me anytime 14:09:18 EmilienM, but not very sure on how CI would trigger it 14:09:24 numans: I'll take care of that 14:09:32 sure. I will first submit the t-h-t patch for that 14:09:34 #action EmilienM to prepare scenario007 in project-config 14:09:49 EmilienM, thanks 14:09:49 #action numans to prepare scenario007 in THT / oooq 14:09:59 gfidente: go ahead 14:10:09 EmilienM sorry about late response earlier 14:10:18 so 1) status of ceph-ansible in rdo: it won't get there 14:10:49 instead the agreement was that we should have gating of ceph-ansible changes using tripleo, this takes a while 14:11:07 until then, what we can do, is have a temporary submission in tripleo which enables use of the sig -testing repo 14:11:19 so that when ceph-ansible has interesting changes, we build a test rpm and test it in tripleo 14:11:26 and if it passes, we promote that to -release 14:11:30 Arx Cruz proposed openstack/tripleo-quickstart-extras master: Enable tempest on scenario001-multinode job https://review.openstack.org/482087 14:11:59 long term we probably just want to automate the above process 14:12:08 gfidente: wfm 14:12:18 gfidente: go ahead with multinode vs ovb 14:12:25 also, until then, we don't switch existing jobs but only try to convert a scenario 14:12:32 EmilienM ok thanks 14:12:47 this in theory is possible with a small change https://review.openstack.org/#/c/479288/ 14:12:57 but ceph-ansible doesn't permit use of local filesystem as backend for osds 14:13:02 it needs block devices 14:13:07 Arx Cruz proposed openstack/tripleo-quickstart-extras master: Enable tempest on scenario001-multinode job https://review.openstack.org/482087 14:13:17 so we probably can't run the ceph-ansible scenarios in multinode? 14:13:23 or is it possible to add disks there? 14:13:40 gfidente: can we point it a loopback device or something just for testing? 14:13:56 yes ^ 14:14:07 why can't we just add the feature to ceph-ansible? 14:14:12 EmilienM :D 14:14:14 puppet-ceph was able to do that 14:14:18 you're kidding me? lol 14:14:36 we switched to ceph-ansible because ceph guys wanted it 14:14:37 yeah makes me wonder what happens on upgrade from puppet managed ceph too 14:14:42 and now we have feature limitation to test it in CI 14:14:52 Arx Cruz proposed openstack/tripleo-quickstart-extras master: Set run_tempest default value to false https://review.openstack.org/482087 14:14:54 it actually has other additional limitations too 14:14:56 I assume most folks have dedicated disks, but are we sure absolutely everyone does? 14:14:58 not the right forum though I think 14:15:14 I'm not sure we want to use OVB to test this scenario 14:15:28 but shardy for upgrades, it does have a playbook which can convert non-containerized into containerized 14:15:34 ceph-ansible had the ability to use directories as a backend but then it was removed 14:15:35 shardy this was actually one of the motivatos 14:15:44 fultonj: why? 14:15:45 gfidente: I mean upgrade when there is no spare block device 14:15:59 by design in an effort to drop support for an unsupporte configuration 14:16:19 the code to do it was literally taken out 14:16:35 so what's the plan now? 14:16:38 fultonj: understood, I guess we'll have to look at CI specific workarounds then 14:16:49 fultonj or bring back the code into it? 14:16:52 I'm not sure we have CI resources to run OVB jobs for that 14:17:16 my vote is to make virtual block devices, quickstart has the means to do this with one flag 14:17:33 fultonj wait for multinode that isn't possible 14:17:36 fultonj: that doesn't help in CI because quickstart doesn't create the VMs for multinode jobs 14:17:44 quickstart is not customer experience 14:18:02 EmilienM do we have existing code I could look at which runs on the subnode 14:18:11 EmilienM so I can create the loopback device ? 14:18:38 gfidente: yes, we do - we can show this code after the meeting 14:18:46 quickstart aside, i hope a workaround is possible (sorry i don't know one) in ci to use the virtal disks as that's what any serious ceph deploy would use 14:18:51 EmilienM great thanks, I guess that'd be my next action 14:19:12 Arx Cruz proposed openstack-infra/tripleo-ci master: Add validate-tempest role in overcloud-validate tag https://review.openstack.org/484627 14:19:13 thanks 14:19:13 fultonj: ack, yeah we're just a little constrained in the CI environment that's all 14:19:31 understood, thank you guys 14:19:33 right, we try to keep OVB for the things we need baremetal, like ironic/nova, etc 14:19:37 thanks guys "D 14:19:50 Mehdi Abaakouk (sileht) proposed openstack/tripleo-heat-templates master: aodh: add gnocchi_external_project_owner config https://review.openstack.org/484816 14:19:57 gfidente, fultonj: let's discuss after the meeting on tech details 14:19:59 gfidente: puppet-cinder does something similar https://github.com/openstack/puppet-cinder/blob/master/manifests/setup_test_volume.pp 14:20:21 loopback+lvm, so i guess you only need loopback? 14:20:28 Arx Cruz proposed openstack/tripleo-quickstart master: Enable tempest on scenario001-multinode job https://review.openstack.org/484788 14:20:30 anyway yea we can discuss after, sorry 14:20:34 losetup ftw 14:20:41 :) 14:20:42 well, it works in devstack ;) 14:20:45 :) 14:20:50 no! it's not friday please 14:20:55 :D 14:20:57 friday is ceph-ansible 14:21:00 gfidente: anything else? 14:21:13 * EmilienM keeps his energy for Friday 14:21:19 EmilienM well if people interested in integration wants to look at the submissions 14:21:35 https://review.openstack.org/#/c/482500/ < that and below, it'd be nice :D 14:21:44 that's all thanks :D 14:22:06 gfidente: cool - if you need reviews, also you can send an email to the ML, detailing what you've done, and folks can look the patches 14:22:17 EmilienM ack 14:22:24 #topic bugs 14:22:27 EmilienM: i added some review requests. in particular /#/c/479886/ if folks agree we should do that and should we add for all the services? for /#/c/481635/ kind of falls under validations and is feedback a user (checking for the disable_upgrade_deployment flag) which i initially proposed on tripleo-common but i like the client version better. grateful for any comments and reviews thanks. 14:22:33 EmilienM: thanks :) 14:22:42 #undo 14:22:42 Removing item from minutes: #topic bugs 14:23:09 marios: you have a problem with URLS :D 14:23:21 :) nah i listed them in the etherpad 14:23:36 Giulio Fidente proposed openstack/tripleo-heat-templates master: Convert scenario001-multinode-containers job to ceph-ansible https://review.openstack.org/479288 14:23:40 ah, there is a third topic ok 14:23:44 EmilienM: https://etherpad.openstack.org/p/tripleo-meeting-items here i mean 14:23:53 yeah I missed the third (late) topic 14:24:00 EmilienM: ack my apologies 14:24:13 no worries 14:24:27 marios: so what's the problem? please bring some context 14:24:40 EmilienM: i added some review requests. in particular /#/c/479886/ if folks agree we should do that and should we add for all the services? for /#/c/481635/ kind of falls under validations and is feedback a user (checking for the disable_upgrade_deployment flag) which i initially proposed on tripleo-common but i like the client version better. grateful for any comments and reviews thanks. 14:25:07 EmilienM: not sure it is worth going into here. there are bugs attached to the reviews for more info 14:25:53 marios: so you don't want to discuss about it? 14:26:20 EmilienM: thats fine unless there are questions, otherwise as I said just review requests thanks 14:26:47 marios: next time, just bring a bit more context for those who're not familiar with this work 14:27:03 EmilienM: sure thing :D 14:27:33 EmilienM: I think the summary is should we remove the packages on the host for containerized services on upgrade 14:27:34 #action folks who understand marios can review his work about 479886 etc 14:27:42 adding a flag to allow it seems reasonable to me 14:27:49 EmilienM: :( wow man why? 14:27:53 although I wonder why the patch mentioned only has neutron and nova in it 14:28:06 shardy: ah, now I get it 14:28:20 shardy: shouldn't it be mandatory when we upgrade? 14:28:34 I'm asking if our operators have to put this flag manually when they upgrade or not 14:28:48 EmilienM: well, leaving the packages on the host could enable easier rollback, but we can argue over the default value later 14:28:51 ;) 14:28:57 ok 14:28:59 #undo 14:29:00 Removing item from minutes: #action folks who understand marios can review his work about 479886 etc 14:29:19 #æction team to review disable_upgrade_deployment flag feature in container work, see https://review.openstack.org/#/c/479886/ and other patches 14:29:33 marios: anything else? 14:30:13 ok moving on 14:30:15 #topic projects releases or stable backports 14:30:22 #link http://lists.openstack.org/pipermail/openstack-dev/2017-July/119788.html 14:30:34 a short mail about next releases for pike ^ 14:30:43 some details about feature freeze, etc, worth reading I think 14:30:50 other than that, no updates on release management 14:31:08 any question on topic? 14:31:25 #topic CI 14:31:42 I think I missed #bugs, we'll do after 14:32:01 adarazs: thanks for the weekly summary sent by email on CI work 14:32:10 no problem :) 14:32:25 is there anything to discuss now, which is related to CI? 14:32:37 this week I won't be on the CI Squad meeting, so please somebody else lead it/summarize it. 14:32:48 k.. np 14:32:48 ah, we need a chair 14:32:53 weshay: you ok? 14:32:56 sure 14:32:58 cool, thx 14:33:16 #action weshay to chair next CI squad meeting & summarize it 14:33:21 thanks weshay! 14:33:44 #topic bugs 14:33:51 I skipped this topic, sorry 14:34:01 do we have outstanding bugs to discuss this week? 14:34:31 next week, we'll move Low / Medium to Queens-1 milestone 14:34:50 and keep High / Critical for Pike RCs 14:35:07 please update your blueprints in Launchpad, it would really help :) 14:35:23 (when I do it it's terrible ;-)) 14:35:39 nothing else about bugs this week, let's move 14:35:42 #topic specs 14:35:47 #link https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open 14:35:55 anyone needs to discuss about specs? 14:36:31 #topic open discussion 14:36:46 any question or feedback is welcome 14:36:51 EmilienM: hi, i'd like to bring something up here. not sure what you intended when you wrote 17:27 <@EmilienM> #action folks who understand marios can review his work about 479886 etc 14:36:57 EmilienM: perhaps as a joke? 14:37:04 marios: yes it was a joke dude 14:37:13 I wanted to ask for feedback on https://review.openstack.org/#/c/483293/ - the idea is to have only one (ansible based) workflow for the service deploy steps 14:37:19 EmilienM: not sure, but i'd like to point out that this is not conducive to inviting folks that may be new to the project to add things into the meeting, or even speak up ata ll 14:37:30 EmilienM: if they can expect that the PTL will savage them or make some joke about them 14:37:36 because like I said, I didn't understand the context on the discussion, you brought up patches without explaining what is it 14:37:50 marios: sorry 14:37:53 Lukas Bezdicka proposed openstack/tripleo-heat-templates stable/ocata: Ensure yum cache is ready before update https://review.openstack.org/484827 14:37:53 EmilienM: i am not sure what you meant by that, but it genuinely hurt me and when i said that, youdidn't even acknowledge it, but removed from the agenda 14:38:11 EmilienM: so regardless of myself, someone seeing that from the PTL during the weekly meeting may not find it that funny 14:38:14 marios: I didn't mean to hurt or anything 14:38:46 marios: it wasn't funny 14:38:53 Giulio Fidente proposed openstack/tripleo-heat-templates master: [WIP] Add support for deploying RGW with ceph-ansible https://review.openstack.org/480804 14:39:00 marios: sorry for that :-( 14:39:06 EmilienM: ack thanks i felt it necessary to at least say that thanks for the apology accepted 14:39:38 I just want to keep tripleo-meeting-items a set of topics that we can discuss and we like when topics are understable by everyone so we can participate, that was all my intention 14:40:00 I hope we can make tripleo-meeting-items not just a list of patches to review 14:40:12 but also a discussion we can have together 14:40:25 so again, sorry I didn't want to hurt at all 14:40:38 EmilienM: ack thanks, lets move onto more important things i believe shardy had an item here 14:40:51 i wanted to bring a little technical discussion here, may be not the right place but 14:40:59 yeah just a request for validation of the approach, it needs a rebase but it did pass CI on the previous revision 14:41:10 shardy: so you want to deploy in one step, it's interesting 14:41:22 if folks are OK with it, I'll rebase and we can aim to completely remove the old puppet deploy steps architecture for pike 14:41:40 shardy: how do you deal with clustering, etc? 14:41:43 EmilienM: No we still have the steps, but they're not duplicated between the docker+puppet and pure puppet architecture 14:41:54 so we only have one codepath to maintain 14:41:57 matbu: it's the right place 14:42:08 which will handle baremetal steps and docker steps interleaved 14:42:31 shardy: ah ok 14:42:38 and workflows 14:43:06 ack, so in this review ( https://review.openstack.org/463728 ) i use the std.ssh action from mistral, in order to trigger an ssh remote command for upgrade. I need to tweak a little the ssh config for the mistral user. 14:43:07 sounds like a good thing, if we can let ansible / workflows manage their own steps 14:43:16 gfidente: ah yeah sorry forgot workflows ;) 14:43:25 shardy until we get to run them outside heat 14:43:27 which I am happy with 14:43:32 EmilienM: hi, can you please look again at https://review.openstack.org/#/c/452521/? 14:43:35 using scheduling hints i am getting : 14:43:39 [u'Only 0 nodes are exposed to Nova of 5 requests. Check that enough nodes are in "available" state with maintenance mode off.', u'Only 0 nodes are exposed to Nova of 5 requests. Check that enough nodes are in "available" state with maintenance mode off.'] 14:43:39 so i wanted thoughts from workflow guys & others about that ... 14:43:42 but for now heat does the job pretty well for me 14:43:46 any thoughts? ^^^ 14:44:05 matbu: sounds OK short term, but FWIW I was hoping we'd move more towards running ansible on the undercloud via mistral 14:44:25 which can then include the upgrade_tasks etc directly 14:44:44 itzikb_: done 14:44:51 matbu: e.g config download can include wrapper playbooks that replace the operator driven upgrade shell scripts 14:46:27 shardy: yep, maybe i should do it (i mean the playbook on the nodes, and just re-use the mistral ansible action instead ?) 14:47:03 matbu: yeah it might be a little cleaner, and it's similar to what I've been trying for minor updates 14:47:06 shardy: because tweaking the mistral user is a bit ugly 14:47:11 EmilienM: thanks! 14:47:16 matbu: I'll try to push some patches later and we can discuss tomorrow 14:47:34 about the different approaches, and what is possible for Pike 14:47:40 shardy: push patches about this topic or just minor update ? 14:48:07 matbu: I'll try to write one which shows how we might run upgrade_tasks from the undercloud vs via the scripts 14:48:19 then you can see if it fits with your ideas and we can discuss further? 14:48:33 shardy: ack sure 14:48:53 anything else for this week? 14:49:09 btw the ctlplane upgrade works well 14:49:11 rook had a question but perhaps we can handle that after the meeting 14:49:14 with the cli patch 14:49:15 oops yes 14:49:50 shardy regarding the step consolidation, steps are still orchestrated in heat there or am I misreading? 14:50:06 I'll close the meeting and we can continue discussions 14:50:10 #endmeeting