14:00:19 #startmeeting tripleo 14:00:20 Meeting started Tue Jul 25 14:00:19 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:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:23 The meeting name has been set to 'tripleo' 14:00:24 #topic agenda 14:00:31 * review past action items 14:00:33 * one off agenda items 14:00:35 * bugs 14:00:37 * Projects releases or stable backports 14:00:39 * CI 14:00:41 * Specs 14:00:43 * open discussion 14:00:45 Anyone can use the #link, #action and #info commands, not just the moderatorǃ 14:00:52 Hi everyone! who is around today? 14:00:55 hi2u 14:00:56 \o 14:01:00 o/ 14:01:04 o/ 14:01:05 o/ 14:01:12 o/ 14:01:15 o/ 14:01:30 o/ 14:01:39 * EmilienM won't make any bad joke today & also try to keep this meeting short to let people get back to work 14:01:46 EmilienM: ;) 14:02:00 o/ 14:02:04 #topic review past action items 14:02:12 EmilienM to prepare scenario007 in project-config: done & merged 14:02:20 numans to prepare scenario007 in THT / oooq: done and merged - it's gating AFIK 14:02:24 o/ 14:02:30 o/ 14:02:33 weshay to chair next CI squad meeting & summarize it 14:02:47 I don't recall the summary 14:02:59 o/ 14:03:02 o/ 14:03:22 0/ 14:03:48 weshay: can we get a summary of our last tripleo ci squad meeting (whenever you have time this week maybe) 14:03:58 o/ 14:03:58 yes 14:04:00 o/ 14:04:11 cool 14:04:12 #topic one off agenda items 14:04:16 #link https://etherpad.openstack.org/p/tripleo-meeting-items 14:04:23 abishop: you go first 14:04:33 thx, I'm flagging an issue in case it spurs discussion 14:04:39 cinder and nova want barbican to be the default encryption key manager, but until recently their code overrides the default to specify the legacy (fixed key) manager 14:04:46 tripleo seems to have been relying on this behavior (perhaps inadvertently) because it doesn't configure the cinder/nova key manager unless barbican is deployed 14:04:57 but this cinder/nova default behavior is changing 14:04:57 #link https://review.openstack.org/485322 and https://review.openstack.org/484501) 14:05:05 it's changing in pike? 14:05:07 so, in order for the legacy encryption keys to work (especially across upgrades), I think tripleo must actively configure cinder/nova to use the legacy key manager when barbican isn't used 14:05:15 yep 14:05:22 but we are end of pike 14:05:29 and they're changing it 14:05:37 I also have puppet-tripleo changes in mind that I think will address the problem 14:05:39 o/ 14:06:16 abishop: your proposal sounds good to me 14:06:30 I don't think there is an impact to enable the legacy key manager when barbican isn't used 14:06:32 ok, will post review ASAP 14:06:34 it does feel pretty late to change default behaviors 14:06:40 trown: the usual :D 14:06:45 indeed 14:07:01 that's it from me 14:07:16 abishop: maybe create a blueprint, target for queens, that switch to new key manager & we manage the upgrade 14:07:38 EmilienM: yeah, and a good topic for ptg 14:07:50 #action abishop to force legacy key manager before end of pike even if barbican is not deployed 14:07:55 another issue will probably be migration of legacy keys to barbican (if possible) 14:08:17 #action abishop to propose PTG topic about barbican key manager changes in tripleo/queens 14:08:20 abishop: indeed 14:08:38 I guess barbican doesn't provide a tool for operators to migrate keys? 14:09:07 (sounds like a nice feature to implement in barbican maybe) 14:09:11 EmilienM: I can't answer, pretty new to this topic 14:09:33 cinder core (eharney) flagged the issue to me 14:09:39 maybe we can involve jaosorior in this topic (not urgent I guess but still useful to talk about it before PTG) 14:10:48 #action jaosorior / abishop to kick-off some discussion about a tool to migrate barbican keys from a manager to another (maybe within barbican) 14:10:55 abishop: anything else? 14:11:02 nope, thx 14:11:05 abishop: thx 14:11:12 bogdando: hey 14:11:18 hey. So, logrotate and crond should be containerized as a dependency for containerized services logs rotation 14:11:26 #link https://bugs.launchpad.net/bugs/1700912 14:11:26 Launchpad bug 1700912 in tripleo "Logrotate configs must be adjusted for containerized services logs" [High,Triaged] - Assigned to Bogdan Dobrelya (bogdando) 14:11:29 #link https://bugs.launchpad.net/tripleo/+bug/1706354 14:11:29 Launchpad bug 1706354 in tripleo "Containerize Logrotate with cron" [High,Triaged] - Assigned to Bogdan Dobrelya (bogdando) 14:11:36 It seems there is no better option, like shipping config with tripleo-common (inflexible) and installing it to uc/overcloud nodes (defeats the containers purpose, tripleo-common goes for containers only). Can't be left for Queens as /var/log/containers must be rotated for the Pike somehow :) 14:11:47 so feedback is wellcome 14:12:06 indeed, real problem here 14:12:44 that's basically it 14:13:12 #action team involved in containerization to review https://bugs.launchpad.net/bugs/1700912 and https://bugs.launchpad.net/tripleo/+bug/1706354 14:13:12 Launchpad bug 1700912 in tripleo "Logrotate configs must be adjusted for containerized services logs" [High,Triaged] - Assigned to Bogdan Dobrelya (bogdando) 14:13:13 Launchpad bug 1706354 in tripleo "Containerize Logrotate with cron" [High,Triaged] - Assigned to Bogdan Dobrelya (bogdando) 14:13:29 bogdando: thanks 14:13:35 note, we track the Pike progress here https://etherpad.openstack.org/p/tripleo-containers-todo 14:13:39 #link https://etherpad.openstack.org/p/tripleo-containers-todo 14:13:51 good reminder 14:13:55 fultonj: o/ 14:13:59 hi 14:14:08 regarding ceph-ansible integration, we are waiting on 4 reviews 14:14:16 they are linked from the etherpad 14:14:25 thanks to jistr for helping out 14:14:34 also, last week we talked about the virtual block device 14:14:37 fultonj: quick question, are we going to make the scenario001-upgrade job passing between ocata/puppet-ceph and pike/ceph-ansible? 14:15:08 EmilienM: yes, but not by friday 14:15:44 EmilienM: this week we aim to land basic deploy in ci 14:15:59 or are just going to deploy ceph-ansible in scenario001-container, and that's all? 14:16:20 deploy ceph-ansible in scenario001-container this week 14:16:27 ok 14:16:41 regarding, the virtaul block device 14:16:45 wfm 14:16:58 wfm? 14:18:12 works for me 14:18:14 for the CI thing 14:18:16 ack, thanks 14:18:16 #action team to review https://etherpad.openstack.org/p/tripleo-ceph-ansible (4 patches needed for m3) 14:18:42 we want to make the disk bigger, 7G, but it is sparse, so it's not really that big 14:19:05 we talked about it some last week, leseb is here this week if there are questions about the move to the real block device 14:19:34 sure 14:19:54 sshnaidm: make sense? 14:20:25 we could have filter scenario001 and 004 only in https://review.openstack.org/#/c/484963/9/scripts/bootstrap-overcloud-full-minimal.sh but that's fine I guess 14:20:40 I think the flavors for multinode jobs have enough storage 14:20:51 ok, cool 14:21:07 we ran into an issue with ceph needing a bigger disk, so glad that will work 14:21:10 fultonj: also when scenario001 is done, please maybe do scenario004 as well (the RGW use case) 14:21:21 o/ 14:21:24 colonwq: ^ 14:21:41 EmilienM: sure, we will follow up on that when 001 is done. 14:21:46 cool cool 14:21:48 let's move on 14:21:50 if no other questions/comments, then feel free to ask me later. thank you all 14:21:56 anything else this week for one off agenda items? 14:22:22 #topic bugs 14:22:30 #link https://launchpad.net/tripleo/+milestone/pike-3 14:22:49 do we have any particular bug to discuss this week? 14:23:12 (beside the container/logrotate things ;-)) 14:24:04 tomorrow, we'll release TripleO Pike m3 - Critical / High bugs will move to RC1 but Medium / Low will move to queens-1 14:24:16 (the usual) 14:24:32 any feedback / question so far? 14:25:03 #topic projects releases or stable backports 14:25:25 #link https://review.openstack.org/#/c/486657/ 14:25:40 this is m3 release patch ^ which also contains final release for tripleoclient 14:25:52 dtantsur asked for 2 patches to be merged first: 14:26:03 - workflow: https://review.openstack.org/#/c/462577/ 14:26:06 - tripleoclient: https://review.openstack.org/#/c/471767/ 14:26:27 #action tripleoclient folks to review https://review.openstack.org/#/c/471767/ + dependency asap 14:27:05 anything else we need in tripleoclient before final release? 14:27:34 (reminder: it means we will have stable/pike for tripleoclient tomorrow) 14:27:48 moving on 14:27:51 #topic CI 14:28:16 I have a few topics / ideas, feel free to comment : 14:28:44 after rc1, we'll have stable/pike everywhere - I propose to switch upgrade jobs to voting on stable/pike branch (as we already do for stable/ocata) 14:29:22 we'll probably need some work to have upgrade jobs run by oooq, weshay: can we get some help on this effort if not already in the pipe? 14:30:20 another ci topic, we're adding scenario008 which will test OPNFV (with OpenDaylight) https://review.openstack.org/#/c/486731/ 14:30:39 and fultonj is about to switch scenario001 to use ceph-ansible instead of puppet-ceph 14:30:47 (that's all I have, useful to share) 14:31:44 I have patches up to move 3nodes job to oooq as well 14:31:52 https://review.openstack.org/#/q/topic:3nodes-oooq 14:32:10 #action ci folks to review https://review.openstack.org/#/q/topic:3nodes-oooq 14:32:14 trown: thanks 14:32:37 just a heads up: we're trying to figure out how to integrate DLRN API -- https://github.com/softwarefactory-project/DLRN/blob/master/doc/source/api.rst into the promotion process. for now we won't make changes to the upstream promotion process, but once we hammer out details on RDO promotion, we can try to implement it upstream as well. 14:32:49 Merged openstack/tripleo-quickstart-extras master: Fix compute-feature-enabled option https://review.openstack.org/486984 14:32:58 > anything else we need in tripleoclient before final release? 14:32:58 yes please https://review.openstack.org/#/c/480263/ ! (sorry I was slow) 14:32:58 adarazs: cool, thx 14:33:08 bogdando: ok, added to the list 14:33:36 bogdando: did recheck, hasn't run in CI for 1 month 14:33:40 if anyone has +2 on puppet-openstackci https://review.openstack.org/#/c/482210/ 14:33:49 that will add instructions for reading the logs 14:33:57 weshay: we don't. Ask #openstack-infra -ping pabelanger probably) 14:34:20 weshay: do we have some ongoing efforts to migrate upgrade jobs to use oooq right now? 14:34:42 weshay: I need to ping some people on #openstack-infra again for that... 14:34:49 I see I didn't get answer or merge for it... 14:35:04 EmilienM, I will answer that question off line 14:35:22 adarazs, weshay: also, it sounds like fungi commented on https://review.openstack.org/#/c/482210/ - maybe there is something else to do 14:35:26 weshay: ok 14:35:38 moving on 14:35:41 #topic specs 14:35:42 EmilienM: I answered that question. 14:35:47 my comment is the last. 14:36:04 adarazs: indeed, thanks 14:36:07 #link https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open 14:36:20 well, sort of. I am hoping I won't have to refactor this part of the infrastructure puppet modules :P 14:36:39 adarazs: let me know if you need help on puppet 14:36:58 do we need to discuss about any spec in particular this week? 14:37:20 at this point, all specs should target queens cycle at minimum 14:37:34 except for https://review.openstack.org/#/c/465633/ maybe 14:37:45 bogdando: right? ^ 14:37:48 indeed 14:38:13 I find it odd to merge a pike spec during end of pike 14:38:16 but well 14:38:23 it's the usual I guess :) 14:39:03 #topic container team to review healthcheck spec asap https://review.openstack.org/#/c/465633/ 14:39:09 damn 14:39:12 #undo 14:39:13 Removing item from minutes: #topic container team to review healthcheck spec asap https://review.openstack.org/#/c/465633/ 14:39:17 #action container team to review healthcheck spec asap https://review.openstack.org/#/c/465633/ 14:39:39 anything else about specs before we move on? 14:39:48 #topic open discussion 14:39:57 any question or comment is welcome now 14:40:37 all right 14:40:40 thanks everyone 14:40:43 #endmeeting